WO2016083751A1 - Procede de communication entre un terminal equipe d'un client webrtc et un terminal accessible via un cœur de reseau ims - Google Patents

Procede de communication entre un terminal equipe d'un client webrtc et un terminal accessible via un cœur de reseau ims Download PDF

Info

Publication number
WO2016083751A1
WO2016083751A1 PCT/FR2015/053232 FR2015053232W WO2016083751A1 WO 2016083751 A1 WO2016083751 A1 WO 2016083751A1 FR 2015053232 W FR2015053232 W FR 2015053232W WO 2016083751 A1 WO2016083751 A1 WO 2016083751A1
Authority
WO
WIPO (PCT)
Prior art keywords
ims
identifier
request
webrtc
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2015/053232
Other languages
English (en)
Inventor
Benoît LE SAGE
Xavier De Snoeck
Miguel Labranche
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of WO2016083751A1 publication Critical patent/WO2016083751A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1063—Application servers providing network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion

Definitions

  • the invention is in the field of IMS (IP Multimedia Subsystem) type telecommunications 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 heart of IMS network.
  • IP Internet Protocol
  • IMS IP Multimedia Subsystem
  • VoIP Voice Over IP
  • SIP Session Initiation Protocol
  • IMS IP Multimedia Subsystem
  • WebRTC technology allows web browsers compatible with the aforementioned specifications to be able to communicate in real time (audio, video, etc.) directly between them, without the need to download additional applications such as as pluglns or executable programs in the browser or in the terminal of the user.
  • 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.
  • 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.
  • 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).
  • WebRTC compatible WebRTC compatible
  • WebRTC clients can access the services provided by an IMS core network in order to communicate or be reachable via the IMS network.
  • the 3GPP organization is currently proposing such a solution allowing access for a client
  • Figure 1 illustrates the IPS WebRTC architecture provided by 3GPP.
  • the WWSF entity ⁇ WebRTC Web Server Functiori corresponds to the web server contacted by the user's web browser after clicking on a link or entering a web address (URL -
  • the eP-CSCF corresponds to the IMS-enhanced P-CSCF ⁇ Proxy-Call Session Control Function) ⁇ enhanced ⁇ to provide WebRTC access, ie say by implementing a WebRTC-SIP signaling conversion gateway functionality.
  • 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.
  • 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) authentication data. for WebRTC access to the heart IMS network.
  • registering a WebRTC client associated with an IMS subscriber on the IMS core requires the gateway to behave like a terminal point ⁇ SIP endpoint and to be seen as such in the IMS heart.
  • provisioning provisioning of the IMS subscriber profile in an IMS core home subscriber server (HSS), with SIP credentials specific to WebRTC access to 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.
  • provisioning provisioning of the IMS subscriber profile in an IMS core home subscriber server (HSS), with SIP credentials specific to WebRTC access to 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).
  • SIP DIGEST WebRTC client authentication
  • 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.
  • 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.
  • the communication method comprises steps of:
  • 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 makes the entity of conversion (or gateway) transparent vis-à-vis the core network IMS. 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 a HSS (Home Subscriber Servei) of the IMS core, with SIP authentication data making WebRTC access to the IMS network possible.
  • HSS Home Subscriber Servei
  • the conversion entity is freed from the dynamic management of the SIP registration, de-registration and re-registration procedures, as well as from the authentication procedure of a WebRTC client considered on the IMS heart at the same time. through a P-CSCF entity, as is the case with the aforementioned "3GPP solution”.
  • AS application server
  • IMS application server
  • the aforementioned communication method comprises steps of:
  • 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, notably via a mapping of a WebRTC identifier. with an IMS reachability identifier for the calling or called user, as the case may be.
  • 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.
  • 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.
  • the first protocol is the protocol
  • SIP Session Initiation Protocol
  • the invention relates correlatively to an application server (AS) configured to provide communication services on an IMS core network.
  • AS application server
  • such an application server comprises:
  • first reception means 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, transmitted 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.
  • the application server furthermore comprises:
  • 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.
  • 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.
  • such an application server includes the WebRTC-IMS conversion entity.
  • 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.
  • 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 embedded in an application server implements a communication method such as briefly exposed upper.
  • 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.
  • a recording medium may be constituted by any entity or device capable of storing such a code.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a means removable recording device such as a USB key or a magnetic recording medium, such as a hard disk.
  • a computer program can be downloaded in particular on an Internet type network.
  • 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 a network core
  • IMS 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.
  • 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 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.
  • 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.
  • the IMS core network ie a subscriber to a communication service on an external network at the heart of the IMS network - for example a subscriber to a PSTN switched network or a subscriber to a fixed or wireless local area network.
  • the subscriber has a subscriber identifier of the external network considered (for example a telephone number) reachable via the core network IMS via interconnection equipment of this network external to the IMS network core (eg MGCF entities, P-CSCF, etc.) ⁇
  • FIG. 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.
  • 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.
  • a web application APP- whose code uses languages such as HTML, JavaScript and CSS ⁇ Cascading Style Sheets
  • the web server WS provides more precisely to the aforementioned web address a home page of a communication environment allowing users Ul, 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.
  • BRW2 have each downloaded a web page (WP1 and WP2) containing the application APP of the communication service according to the invention, so they can establish a communication time real peer-to-peer, especially voice or video type, as illustrated by the double dotted arrow Cl.
  • the network environment comprises an IMS 2 core network to which servers or equipment providing functions defined in accordance with the 3GPP specification TS 23.228 are connected in a conventional manner, such as:
  • I-CSCF Interrogating Serving - Call Session Control Function
  • S-CSCF Serving-CS ⁇
  • P-CSCF Proxy-CSCF
  • MGCF Media Gateway Control Function
  • IMS a public switched telephone network PSTN, 431 ⁇ Public Switched Telephone NetworR) to which are connected fixed terminals T3 and mobile T4.
  • PSTN public switched telephone network
  • 431 Public Switched Telephone NetworR
  • the environment of Figure 2 further comprises:
  • an application server 31 connected to the core of the IMS network and providing communication services and in particular IP telephony services via the IMS core network;
  • first protocol is chosen as the WebSocket protocol associated with the JSON data format ⁇ JavaScript Object Notation) and the IMS compatible signaling protocol (“second protocol ”) is the Session Initiation Protocol (SIP).
  • SIP Session Initiation Protocol
  • 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).
  • the server AS conventionally uses a communication interface with the core network IMS, designated by the acronym ISC for "multimedia IP Subsystem Service Control Interfaced", and described in the document 3GPP TS 23.228 section 4.2.4.
  • the AS 31 server further 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).
  • 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 identifier;
  • 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 IMS reachability identifier of the caller-obtained; by the first request processing module-, in order to establish through the conversion entity, a media communication 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 is 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;
  • first protocol SIP protocol
  • 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.
  • 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.
  • 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.
  • the database of subscriber profiles is filled during a prior 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.
  • 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. intermediary of the subscriber profiles database.
  • 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 / Transmission Control Protocol) predefined.
  • a first mode called trust mode / 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 server.
  • WS web in connection with the gateway GW, any request from the latter then being 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.
  • 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.
  • 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.
  • GW WebRTC gateway
  • FIG. 3 illustrates the hardware architecture of an application server AS according to the invention.
  • 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 non-volatile memory 3D (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 integrate by example a network card, known in itself 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 (Tl) equipped with a WebRTC client (BRW1 browser) and a called terminal (T3-T6) accessible via the IMS 4 core network.
  • the method is implemented by the application server 31, providing communication services (audio, video, data. ..) on the IMS 4 network core via its ICS interface.
  • the terminal T1 transmits to the gateway WebRTC-IMS 33 (protocol conversion entity) a communication request to the terminal T3.
  • This request sent according to a WebRTC compliant PI signaling protocol is converted by the gateway 33 into an RQT1 request according to an IMS-compatible P2 protocol.
  • 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 Ul (caller) and a reachability identifier IMS (URI-U3) associated with the user U3 (called) of the terminal T3.
  • URI-U1_2 WebRTC identifier
  • IMS reachability identifier
  • step S43 the server AS 31 processes the request to obtain an IMS reachability identifier (URI-U1_1) of the caller U1 from its WebRTC identifier (URI-U1_2).
  • the server AS consults a database of subscriber profiles, with the input data identifier WebRTC (URI-U1_2) of the subscriber Ul, and obtains its IMS reachability identifier (URI) -U1_1) as well as the data relating to the services to which the subscriber Ul has subscribed.
  • a second communication request (RQT2) according to the protocol P2 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 heart of network IMS, to the terminal T3 of 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 (T1, T2) equipped with a WebRTC client (browsers BRW1, BRW2).
  • the method is implemented by the application server 31, providing communication services (audio, video, data ...) on the core network IMS 4 via its ICS interface.
  • step S51 the application server AS receives a first communication request (RQT1) according to the protocol P2 (IMS compatible signaling protocol, for example SIP).
  • P2 IMS compatible signaling protocol, for example SIP
  • This request RQT1 was sent via the heart of the IMS network by the terminal T3 of the user U3 (calling party) identified by his IMS reachability identifier (URI-U3), to the user U1 also identified by his identifier of IMS reachability (URI-U1_1).
  • IMS IMS compatible signaling protocol, for example SIP
  • 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 Ul corresponds to a subscriber having a WebRTC identifier.
  • the server AS consults the database of subscriber profiles mentioned above, with the input data IMS reachability identifier (URI-U1_1) of the user called Ul.
  • the user Ul has a WebRTC identifier (URI-Ul_2) which is therefore obtained from the profile database.
  • 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 Ul, then the request is transmitted to the gateway GW 33.
  • URI-U3 IMS reachability identifier
  • URI -U1_2 WebRTC identifier
  • the gateway GW 33 then translates the request RQT2 into a request according to the protocol PI (WebRTC compatible) and transmits it via the Internet INT, to the browser BRW1 of the terminal (Tl) of the called user (UI).
  • protocol PI WebRTC compatible
  • 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 Ul.
  • the user Ul has two identities: an IMS reachability identifier (URI-U1_1), in this example a known SIP identity of the IMS and public, c ie "routable" from interconnection networks such as a PSTN network (431) or a corporate private network connected by a gateway (BOX 411) to 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 Ul (caller) connects beforehand (connection not shown in FIG.
  • the identifier selected for the user U3 is, for example, his telephone number on the PSTN telephony network (431), which is transmitted to the WebRTC gateway (GW 33) by the terminal T1, in a request message M601.
  • the message M601 is a message in JSON format using the WebSocket communication protocol over the HTTP protocol ⁇ HyperText Transfer Protocd). This message is of the following form:
  • URI-U1_2 designates the web identifier associated with the calling web user ⁇ l ⁇ caller), for example an email address (userUl@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:
  • URI-U1_1 is of the general form:
  • URI-U1_1 "sip:" userUWdomain "
  • IMS identifier 'UserUl' means an IMS identifier.
  • the IMS identifier 'UserUl' 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 el64).
  • PSTN public public IMS ID
  • the IMS identifier 'UserUl' may also be a private IMS identity, that is to say only known 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.
  • the application server AS creates a second request, M607, according to the SIP protocol, on 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 Ul.
  • this second request is a request in which the server acts according to the "originating" mode as defined in particular in section 5.7.3 of the specification 3GPP TS 24.229 V12.6.0 (2014-09) - Technical Specification Group Core Network and Terminais; IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 12).
  • IP Session Initiation Protocol
  • SDP Session Description Protocol
  • the second request M607 is of the following form:
  • the request M607 is then transmitted to the ICSCF entity of the IMS core network.
  • the ICSCF entity then transmits a corresponding M609 request to the terminal T3 of the user U3 (called) via BGCF (Breakout Gateway Control Function) and MGCF entities of the IMS core network.
  • the request M609 is of the following form:
  • the terminal T3 sends a ringback message to the entity MGCF which converts it into a message M611 SIP response type '180 RINGING 'indicating the successful reception of the request for communication (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 message received the IMS reachability identifier (URI-U1_1) of the user U1 by the corresponding web identifier (URI-U1_2) and transmits a modified message M615 to the gateway GW.
  • 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 T1 (browser BRW1).
  • the response message M617 is of the following form:
  • the messages M619-M625 are similarly SIP messages '200 OK' which are propagated from the called terminal T3 to the calling terminal T1 to indicate that the communication request has succeeded, the last message, M625, being of the form next :
  • the communication request from the terminal T1 to the terminal T3 ends with the sending of an acknowledgment message (ACK), indicating that the communication request has been terminated, propagated in the form of successive messages (M629-M633) by the different devices (GW, AS, CSCF, MGCF) located between the terminal T1 and the terminal T3, from an initial message M627 issued by the terminal T1, of the form: ⁇ request "complete call” ⁇ .
  • ACK acknowledgment message
  • 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 via, in particular, the gateway GW and the IMS equipment involved. in the routing of the media stream (media proxy ...) ⁇
  • the media flow between the T3 terminal and the GW gateway is established according to the Real-time Transport Protocol (RTP), while the media flow established between the gateway GW and the terminal Tl is established according to the protocol SRTP (Secure RTP).
  • RTP Real-time Transport Protocol
  • the user Ul has two identities: an IMS reachability identifier (URI-U1_1), in this example a known SIP identity of the IMS and public, that is, "routable" from interconnection networks such as a PSTN network (431) or a corporate private network connected by a gateway (BOX 411) to 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 Ul has been previously activated with the application server AS, which makes it possible to automatically route calls from the core network IMS to his web browser (BRW1).
  • URI-U1_1 IMS reachability identifier
  • 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 Ul, 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).
  • IMS reachability identifier IMS reachability identifier: URI- U1_1
  • the call is expressed at the level of the MGCF equipment by an M701 SIP INVITE request message of the following form:
  • the request message M701 is received by the I / S-CSCF entity of the IMS core network, which in turn sends a terminating mode M703 SIP INVITE message to the application server AS.
  • the message M703 is of the following form:
  • 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 request message by its IMS reachability identifier 'URI-U1_1' also has the WebRTC identifier 'URI-U1_2'; and transmits to the gateway GW, an M707 SIP INVITE request message, wherein the WebRTC identifier of the called party Ul replaces its IMS reachability identifier.
  • the message M 707 is of the following form:
  • 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 (over the HTTP protocol) to destination of the caller terminal Tl of the called party Ul.
  • the message M709 is of the following form:
  • the Tl terminal web browser then issues an M711 response JSON message of the following form is sent to the GW gateway:
  • the message M711 is received by the gateway GW which converts it into a SIP message
  • the message M713 is received by the application server AS which in turn sends to the I / S-CSCF entity an M715 SIP message ⁇ 80 RINGING 'in which the webRTC identifier (URI-U1_2) of the called party Ul is replaced by the corresponding IMS reachability identifier (URI-U1_1).
  • the message M715 and of the following form:
  • the SIP message M715 is received by the I / S-CSCF entity which in turn sends a SIP RINGING message, M717, to the T3 terminal of the caller U3 via the MGCF entity.
  • an M719 response JSON message of the following form is then sent to the gateway GW:
  • the message M719 is received by the gateway GW which converts it into a SIP message
  • the message M721 is received by the server AS which in turn sends to the I / S-CSCF entity a message, M723, SIP 200 OK in which the identifier webRTC (URI-U1_2) called Ul is replaced by the corresponding IMS reachability identifier (URI-U1_1).
  • the message M723 and of the following form:
  • the SIP message M723 is received by the I / S-CSCF entity which in turn transmits a SIP message 200 OK, M725, to the terminal T3 of the caller U3 via the entity MGCF.
  • 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.
  • ACK acknowledgment message
  • the message M733 is of the following form: ⁇ request "complete call” ⁇
  • the media communication (voice and / or video for example) can then be established (S735, S737) between the terminal T3 and the terminal T1 via the GW gateway and the IMS equipment involved in the routing of the media stream (media proxy). .)
  • the media flow between the T3 terminal and the GW gateway is established according to the Real-time Transport Protocol (RTP), while the media flow established between the GW gateway and the Tl terminal is established according to the protocol.
  • RTP Real-time Transport Protocol
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Procédé de communication entre un terminal équipé d'un client Web RTC et un terminal accessible via un cœur de réseau IMS, ce procédé étant mis en œuvre par un serveur d'application configuré pour fournir des services de communication sur le cœur de réseau IMS. Le procédé comporte des étapes de : – réception (S41) en provenance d'une entité de conversion bidirectionnelle de messages selon un premier protocole de signalisation compatible Web RTC en messages selon un second protocole de signalisation compatible IMS, d'une première requête (RQT1) de communication selon le second protocole, obtenue par conversion protocolaire à partir d'une requête initiale émise par un terminal d'un appelant (U1) identifié par un identifiant Web RTC (URI-U1_2), et destinée à un appelé (U3) identifié par un identifiant de joignabilité IMS (URI- U3); – traitement (S43) de la première requête afin d'obtenir un identifiant de joignabilité IMS (URI-U1_1) à partir de l'identifiant Web RTC (URI-U1_2) de l'appelant; – transmission (S45) sur le cœur de réseau IMS, à destination de l'appelé (U3), d'une seconde requête (RQT2) de communication selon le second protocole contenant l'identifiant de joignabilité IMS (URI-U1_1) de l'appelant, en vue d'établir une communication média (S47) au travers de l'entité de conversion, entre le terminal de l'appelant et un terminal de l'appelé.

Description

Procédé de communication entre un terminal équipé d'un client WebRTC et un terminal accessible via un cœur de réseau IMS DOMAINE TECHNIQUE
L'invention se situe dans le domaine des réseaux de télécommunications de type IMS {IP Multimedia Subsystem) tel que défini par le 3GPP { Third Génération Partnership Project). L'invention concerne en particulier un procédé de communication entre un terminal équipé d'un client WebRTC et un terminal accessible via un cœur de réseau IMS, ce procédé étant mis en œuvre par un serveur d'application configuré pour fournir des services de communication sur le cœur de réseau IMS.
ETAT DE LA TECHNIQUE
L'un des objectifs de l'IMS est de permettre à un utilisateur d'accéder à différents services quel que soit son type de connectivité IP {Internet Protocol).
L'IMS est une architecture standardisée pour les opérateurs de téléphonie, qui permet de fournir des services multimédias fixes et mobiles. Cette architecture utilise en particulier la technologie VoIP ( Voice Over IP) ainsi que le mécanisme de signalisation SIP {Session Initiation Protocol) qui permet à des services voix, texte et multimédia de traverser tous les réseaux connectés à un cœur de réseau IMS. L'IMS standardisé auprès du 3GPP est décrit notamment dans le document 3GPP TS 23.228, intitulé " Technical Spécification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage (Release 13), V13.0.0, septembre 2014.
Par ailleurs, ces dernières années, une nouvelle technologie de communication temps réel entre navigateurs web, désignée par WebRTC { Web Real-Time Communication), a été développée conjointement par l'IETF {Internet Engineering Task Force) et le W3C { World Wide Web Consortium) et fait l'objet de deux spécifications : une spécification de protocoles, élaborée à l'IETF (RTCWEB), et une spécification d'APIs JavaScript™, élaborée au W3C. Ces spécifications sont décrites respectivement dans les documents suivants :
- WebRTC 1.0: Real-time Communication Between Browsers - W3C Working Draft 10 September 2013, accessible à l'adresse web suivante:
http://www.w3.org/TR/webrtc/
- Overview: Real Time Protocols for Browser-based Applications - draft-ietf-rtcweb- overview-11 - August 18, 2014, accessible à l'adresse web suivante :
https://tools.ietf.org/html/draft-ietf-rtcweb-overview-ll
La technologie WebRTC permet à des navigateurs web compatibles avec les spécifications précitées de pouvoir communiquer en temps réel (données audio, vidéo, etc.) directement entre eux, sans nécessiter le téléchargement d'applications supplémentaires telles que des pluglns ou des programmes exécutables dans le navigateur ou dans le terminal de l'utilisateur.
De manière générale, lorsqu'un premier utilisateur souhaite établir une communication audio ou vidéo, depuis son navigateur web compatible WebRTC, avec un second utilisateur sur le réseau Internet, il commence par se connecter via son navigateur à un serveur web fournissant le service de communication WebRTC. Après une opération d'authentification éventuelle, le navigateur charge, via une page web, l'application web (application JavaScript) conforme aux spécifications RTCWEB et adaptée à interagir avec les APIs conformes aux spécifications WebRTC qui sont incorporées nativement dans le navigateur. Ensuite, le premier utilisateur choisit, via la page web de connexion au serveur web, un identifiant du second utilisateur, puis entre une commande— par exemple par un clic sur un bouton d'action affiché dans la page web ouverte dans le navigateur— pour déclencher l'appel audio ou vidéo vers le second utilisateur. Par conséquent, un dispositif informatique équipé simplement d'un navigateur web (compatible WebRTC) - désigné par client ou agent WebRTC - et disposant d'un accès à l'Internet devient un terminal de communication interpersonnelle au même titre qu'un téléphone mobile ou un téléphone fixe (VoIP, par exemple).
Dans ce contexte, il est souhaitable que les clients WebRTC puissent accéder au services fournis par un cœur de réseau IMS afin de pouvoir communiquer ou être joignables via le réseau IMS.
L'organisme 3GPP propose actuellement une telle solution permettant l'accès d'un client
WebRTC à un cœur de réseau IMS ; celle-ci est décrite dans l'annexe U de la spécification technique 3GPP TS 23.228 mentionnée plus haut.
La Figure 1 illustre l'architecture WebRTC IMS proposée par le 3GPP. Sur la figure 1, l'entité WWSF { WebRTC Web Server Functiori) correspond au serveur web contacté par le navigateur web de l'utilisateur après avoir cliqué sur un lien ou entré une adresse web (URL -
Uniform Resource Locatof) dans le navigateur — il s'agit là du mode de fonctionnement classique WebRTC.
L'entité eP-CSCF, quant à elle, correspond à l'entité P-CSCF {Proxy-Call Session Control Functiori) du réseau IMS, "enrichie" {enhanced) pour fournir l'accès WebRTC, c'est-à-dire en mettant en œuvre une fonctionnalité de passerelle de conversion de signalisation WebRTC-SIP.
Pour rappel l'entité P-CSCF fonctionne comme un serveur proxy pour un équipement utilisateur. Tout le trafic de signalisation SIP provenant de ou à destination de l'équipement utilisateur doit traverser l'entité P-CSCF, laquelle valide et transmet des requêtes reçues de l'équipement utilisateur, puis traite et transmet les réponses à l'équipement utilisateur.
La mise en œuvre d'une passerelle de conversion WebRTC/SIP dans le réseau IMS, au sein de l'entité P-CSCF ou connectée directement à celle-ci, nécessite une allocation et un traitement spécifiques de données d'authentification {credentials) pour l'accès WebRTC au cœur de réseau IMS. En effet, l'enregistrement d'un client WebRTC associé à un abonné IMS sur le cœur IMS requiert que la passerelle se comporte comme un point terminal {endpoint SIP et qu'elle soit vue comme telle dans le cœur IMS.
Cela implique, d'une part, une configuration {provisioning) supplémentaire du profil de l'abonné IMS dans un serveur HSS {Home Subscriber Server du cœur IMS, avec des données d'authentification SIP {credentials) spécifiques à l'accès WebRTC au cœur IMS pour cet abonné ; et d'autre part, une gestion dynamique par la passerelle des procédures d'enregistrement, de dés-enregistrement et de réenregistrement SIP, ainsi que de la procédure d'authentification (SIP DIGEST) du client WebRTC (avec ces données d'authentification propres) sur le cœur IMS au travers de l'entité P-CSCF. Par ailleurs, dans le cas de services de communication rendus à un abonné par l'intermédiaire d'un serveur d'application connecté au cœur de réseau IMS, une déclaration d'une nouvelle identité de l'utilisateur correspondant à un client webRTC serait également nécessaire.
Ainsi, la solution d'accès WebRTC à un cœur de réseau IMS, telle que proposée par le 3GPP, nécessitant une modification de l'architecture IMS et de multiples configurations d'entités du réseau, semble complexe et contraignante techniquement, et relativement coûteuse à mettre en œuvre.
EXPOSE DE L'INVENTION
La présente invention propose une solution technique d'accès d'un client WebRTC à un cœur de réseau IMS, ne présentant pas les inconvénients exposés ci-dessus liés à l'approche proposée par le 3GPP. A cet effet, l'invention concerne un procédé de communication entre un terminal équipé d'un client WebRTC et un terminal accessible via un cœur de réseau IMS, ce procédé étant mis en œuvre par un serveur d'application configuré pour fournir des services de communication sur le cœur de réseau IMS.
Conformément à l'invention, le procédé de communication comporte des étapes de :
- réception, en provenance d'une entité de conversion bidirectionnelle de messages selon un premier protocole de signalisation compatible WebRTC en messages selon un second protocole de signalisation compatible IMS, d'une première requête de communication selon le second protocole, émise par un terminal d'un appelant identifié par un identifiant WebRTC, et destinée à un appelé identifié par un identifiant de joignabilité IMS ;
- traitement de la première requête afin d'obtenir un identifiant de joignabilité IMS à partir de l'identifiant WebRTC de l'appelant ;
- transmission sur le cœur de réseau IMS, à destination de l'appelé, d'une seconde requête de communication selon le second protocole contenant l'identifiant de joignabilité IMS de l'appelant, en vue d'établir une communication média au travers de l'entité de conversion, entre le terminal de l'appelant et un terminal de l'appelé. Un tel procédé de communication selon l'invention permet avantageusement d'établir une connexion directe entre l'entité de conversion WebRTC-IMS et le serveur d'application fournissant les services de communication sur le cœur de réseau IMS, ce qui rend l'entité de conversion (ou passerelle) transparente vis-à-vis du cœur de réseau IMS. Il n'est donc pas nécessaire, comme c'est le cas avec la solution proposée par le 3GPP, de configurer spécifiquement, pour chaque utilisateur WebRTC susceptible d'accéder au cœur de réseau IMS, un profil d'abonné IMS spécifique dans un serveur tel qu'un HSS {Home Subscriber Servei) du cœur IMS, avec des données d'authentification SIP rendant possible l'accès WebRTC au réseau IMS.
Par ailleurs, avantageusement, l'entité de conversion est libérée de la gestion dynamique des procédures d'enregistrement, de dés-enregistrement et de réenregistrement SIP, ainsi que de la procédure d'authentification d'un client WebRTC considéré sur le cœur IMS au travers d'une entité P-CSCF, comme c'est le cas avec la « solution 3GPP » précitée.
Ainsi, selon la présente invention, c'est le serveur d'application (AS) qui est la véritable interface entre le « monde web » et le « monde IMS », sans configuration contraignante de l'architecture IMS ni passage obligatoire par des équipements d'entrée (P-CSCF par exemple) du cœur de réseau IMS.
Selon une mise en œuvre particulière de l'invention, le procédé de communication susmentionné comporte des étapes de :
- réception d'une première requête de communication selon le second protocole émise via le cœur de réseau IMS par un terminal d'un appelant identifié par un identifiant de joignabilité IMS, à destination d'un appelé identifié par un identifiant de joignabilité IMS ;
- traitement de la première requête afin de déterminer si l'identifiant de joignabilité IMS de l'appelé correspond ou non à un abonné disposant d'un identifiant WebRTC, et si c'est le cas,
- transmission à destination de l'entité de conversion d'une seconde requête de communication contenant l'identifiant WebRTC déterminé, en vue de l'établissement, au travers de l'entité de conversion, d'une communication média entre le terminal de l'appelant et un terminal correspondant à l'identifiant WebRTC de l'appelé.
Ainsi, que l'on considère une requête de communication émise par un terminal d'un appelant identifié par un identifiant WebRTC (par exemple une adresse email) ou par un terminal d'un appelant identifié par un identifiant de joignabilité IMS (par exemple une adresse SIP), le serveur d'application permet d'établir une communication entre un terminal d'un environnement réseau web avec un terminal d'un environnement réseau IMS, par l'intermédiaire notamment d'une mise en correspondance d'un identifiant WebRTC avec un identifiant de joignabilité IMS pour l'utilisateur appelant ou appelé, selon le cas. Selon une caractéristique particulière de réalisation, le traitement de la première requête comprend la consultation d'une base de données de profils d'abonnés contenant pour chaque abonné au moins un service mis en œuvre par le serveur d'application, au moins un identifiant de joignabilité IMS, et le cas échéant au moins un identifiant WebRTC correspondant.
Ainsi, l'utilisation d'une telle base de données de profils d'abonnés permet notamment de définir des mécanismes de souscription d'utilisateurs à des services de communications particuliers incluant la possibilité de joindre des utilisateurs IMS et/ou d'être joignable par des utilisateurs IMS par l'intermédiaire d'un simple navigateur web compatible WebRTC.
Selon une autre caractéristique de réalisation, le procédé de communication selon l'invention comprend une étape d'authentification d'un appelant identifié par un identifiant WebRTC contenu dans une première requête de communication provenant de l'entité de conversion.
Une telle étape permet notamment de sécuriser l'accès, via un navigateur web, à un cœur de réseau IMS à partir de l'Internet.
Selon un mode de réalisation particulier, le premier protocole est le protocole
WebSocket et le second protocole est le protocole SIP {Session Initiation Protocol).
Selon un deuxième aspect, l'invention concerne corrélativement un serveur d'application (AS) configuré pour fournir des services de communication sur un cœur de réseau IMS. Selon l'invention, un tel serveur d'application comporte :
- des premiers moyens de réception en provenance d'une entité de conversion bidirectionnelle de messages selon un premier protocole de signalisation compatible WebRTC, en messages selon un second protocole de signalisation compatible IMS, d'une première requête de communication selon le second protocole, émise par un terminal d'un appelant identifié par un identifiant WebRTC, à destination d'un appelé identifié par un identifiant de joignabilité IMS ;
- des premiers moyens de traitement de requête, configurés pour obtenir un identifiant de joignabilité IMS de l'appelant à partir de l'identifiant WebRTC de l'appelant ;
- des premiers moyens de transmission sur le cœur de réseau IMS, à destination de l'appelé, d'une seconde requête de communication selon le second protocole, contenant l'identifiant de joignabilité IMS de l'appelant, en vue de l'établissement, au travers de l'entité de conversion, d'une communication média entre le terminal de l'appelant et un terminal de l'appelé.
Selon une mise en œuvre particulière de l'invention, le server d'application comprend en outre :
- des seconds moyens de réception d'une première requête de communication selon le second protocole émise via le cœur de réseau IMS par un terminal d'un appelant identifié par un identifiant de joignabilité IMS, à destination d'un appelé identifié par un identifiant de joignabilité IMS ;
- des seconds moyens de traitement de requête, configurés pour déterminer si l'identifiant de joignabilité IMS de l'appelé correspond ou non à un abonné disposant d'un identifiant WebRTC ;
- des seconds moyens de transmission à destination de l'entité de conversion, d'une seconde requête de communication contenant un identifiant WebRTC déterminé par les seconds moyens de traitement de requête, suite à la réception de la première requête, en vue de l'établissement d'une communication média entre le terminal de l'appelant et un terminal correspondant à l'identifiant WebRTC de l'appelé, au travers de l'entité de conversion.
Selon une mode de réalisation particulier, les premier et seconds moyens de traitement de requête sont configurés pour consulter une base de données de profils d'abonnés contenant pour chaque abonné au moins un service mis en œuvre par le serveur d'application, au moins un identifiant de joignabilité IMS, et le cas échéant au moins un identifiant WebRTC correspondant.
Selon un mode de réalisation particulier, un tel serveur d'application selon l'invention inclut l'entité de conversion WebRTC-IMS.
Selon une autre caractéristique de l'invention, le serveur d'application comprend en outre des moyens d'authentification d'un appelant identifié par un identifiant WebRTC contenu dans une première requête de communication provenant de l'entité de conversion.
Dans le mode de réalisation choisi et décrit, le procédé de communication selon l'invention est mis en œuvre sous forme essentiellement logicielle. Par conséquent, la présente invention concerne, selon un troisième aspect, un ou plusieurs programmes d'ordinateur comprenant des instructions de programme dont l'exécution par un processeur incorporé dans un serveur d'application met en œuvre un procédé de communication tel que brièvement exposé plus haut.
En pratique, un tel programme d'ordinateur est constitué par des modules ou blocs fonctionnels réalisant tout ou partie des étapes susmentionnées du procédé selon l'invention. Chacun des modules ou blocs fonctionnels peut utiliser n'importe quel langage de programmation, et comprendre un ou plusieurs sous-programmes sous forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi par conséquent un support d'enregistrement d'informations lisible par un ordinateur, et comportant le code du ou des programmes selon l'invention. Un tel support d'enregistrement peut être constitué par n'importe quelle entité ou dispositif capable de stocker un tel code. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement amovible tel qu'une clé USB ou un moyen d'enregistrement magnétique, tel qu'un disque dur. D'autre part, un tel programme d'ordinateur peut être en particulier téléchargé sur un réseau de type Internet.
Les avantages procurés par un serveur d'application et un programme d'ordinateur, selon l'invention, sont identiques à ceux, exposés plus haut, en relation avec un procédé de communication selon l'invention, et ne seront par conséquent pas rappelés ici.
BREVE DESCRIPTION DES FIGURES
D'autres caractéristiques et avantages de la présente invention ressortiront de la description détaillée qui suit, laquelle fait référence aux dessins annexés dans lesquels :
- la figure 1 déjà décrite illustre une architecture WebRTC-IMS conforme à une spécification publiée du 3GPP ;
- la figure 2 illustre un environnement réseau dans lequel la présente invention est mise en œuvre, selon un mode de réalisation ;
- la figure 3 illustre l'architecture matérielle d'un serveur d'application selon l'invention ;
- la figure 4 est un organigramme illustrant les principales étapes d'un procédé de communication selon l'invention entre un terminal appelant équipé d'un client WebRTC et un terminal appelé accessible via un cœur de réseau IMS ;
- la figure 5 est un organigramme illustrant les principales étapes d'un procédé de communication selon l'invention entre un terminal appelant accessible via un cœur de réseau
IMS et un terminal appelé équipé d'un client WebRTC ;
- la figure 6 représente, sous forme de diagramme d'échange de messages, un exemple de mise en œuvre d'un procédé de communication selon l'invention entre un terminal appelant équipé d'un client WebRTC et un terminal appelé accessible via un cœur de réseau IMS ; et
- la figure 7 représente, sous forme de diagramme d'échange de messages, un exemple de mise en œuvre d'un procédé de communication selon l'invention entre un terminal appelant accessible via un cœur de réseau IMS et un terminal appelé équipé d'un client WebRTC.
DESCRIPTION DÉTAILLÉE
Dans le cadre de la présente description l'expression "identifiant de joignabilité IMS" d'un abonné à un service de communication désigne un identifiant permettant de communiquer avec cet abonné au travers d'un cœur de réseau IMS, soit directement - dans cas, l'identifiant est un identifiant IMS tel qu'un identifiant SIP -, ou indirectement, c'est-à-dire via un réseau externe au cœur de réseau IMS mais connecté par un équipement d'interconnexion avec le cœur de réseau IMS. En d'autres termes, un appelé ou un appelant accessible par un identifiant de joignabilité IMS sur un cœur de réseau IMS, est soit un abonné IMS c'est-à-dire un abonné à un service de communication fourni par un serveur d'application sur le cœur de réseau IMS, soit un abonné à un service de communication sur un réseau externe au cœur de réseau IMS— par exemple un abonné à un réseau commuté RTC ou un abonné à un réseau local d'entreprise fixe ou sans fil. Dans ce dernier cas, l'abonné dispose d'un identifiant d'abonné au réseau externe considéré (par exemple un numéro de téléphone) joignable via le cœur de réseau IMS par l'intermédiaire d'équipements d'interconnexion de ce réseau externe au cœur de réseau IMS (par exemple des entités MGCF, P-CSCF, ...)■
La figure 2 illustre un environnement réseau dans lequel la présente invention est mise en œuvre, selon un mode de réalisation. L'environnement réseau représenté comprend un premier navigateur web BRW1 d'un premier terminal Tl d'utilisateur, un second navigateur BRW2 d'un second terminal d'utilisateur T2. Les terminaux d'utilisateurs précités peuvent être dans un état connecté ou non connecté à un réseau de communication INT de type Internet, c'est-à-dire un réseau basé sur les technologies de communication mises en œuvre dans le réseau Internet, en particulier le réseau INT peut être aussi un réseau d'entreprise communément appelé intranet.
Les navigateurs BRW1 et BRW2 sont des navigateurs compatibles WebRTC/RTCWEB, désignés par "clients WebRTC", et à ce titre disposent respectivement d'un ensemble 12, 22 d'interfaces API conformes aux spécifications WebRTC, et d'un module fonctionnel RTC 11, 21 conforme aux spécifications RTCWEB.
Les ensembles APIs 12 et 22 sont aptes respectivement à interagir avec une application web APP— dont le code utilise des langages tels que HTML, JavaScript et CSS {Cascading Style Sheets)— incorporée dans des pages web WP1 et WP2 téléchargées respectivement par les navigateurs BRW1 et BRW2 à une adresse web pointant sur des ressources hébergées par un serveur web WS sur le réseau INT.
Le serveur web WS fournit plus précisément à l'adresse web précitée une page d'accueil d'un environnement de communication permettant à des utilisateurs Ul, U2 des terminaux Tl et T2 de pouvoir communiquer entre eux selon le mode WebRTC ou bien de communiquer avec des terminaux distants accessibles via un cœur de réseau IMS.
L'application APP fournit conformément aux spécifications WebRTC/RTCWEB, des fonctionnalités de communication RTC liées à l'environnement de communication fourni par le serveur WS, ainsi que la signalisation permettant d'établir une telle communication entre navigateurs.
Ainsi, comme représenté dans l'exemple de la figure 2, si les deux navigateurs BRW1 et
BRW2 ont téléchargé chacun une page web (WP1 et WP2) contenant l'application APP du service de communication selon l'invention, alors ils peuvent établir une communication temps réel de pair à pair, notamment de type voix ou vidéo, comme illustré par la double flèche en pointillé Cl.
Toujours à la figure 2, l'environnement réseau comprend un cœur de réseau IMS 2 auquel sont connectés de manière classique des serveurs ou équipements fournissant des fonctionnalités définies conformément à la spécification 3GPP TS 23.228, tels que :
- un ensemble 41 d'équipements fournissant les fonctions I-CSCF {Interrogating Serving - Call Session Control Function), S-CSCF (Serving-CSŒ), P-CSCF (Proxy-CSCF) ; à ce dernier est connectée une passerelle (BOX 431) vers un réseau local privé d'entreprise, par exemple, auquel sont raccordés des terminaux de communication T5, T6 ;
- un équipement MGCF (Media Gateway Control Function) 45 reliant au cœur de réseau
IMS, un réseau téléphonique commuté public PSTN, 431 {Public Switched Téléphone NetworR) auquel sont connectés des terminaux fixes T3 et mobiles T4.
L'environnement de la figure 2 comprend par ailleurs :
- un serveur d'application 31 connecté au cœur de réseau IMS et fournissant des services de communication et notamment des services de téléphonie sur IP via le cœur de réseau IMS ;
- une entité de conversion (GW, 33) bidirectionnelle de messages selon un protocole de signalisation compatible WebRTC en messages selon un protocole de signalisation compatible IMS.
En pratique, dans l'exemple de réalisation décrit, le protocole de signalisation compatible WebRTC ("premier protocole") est choisi comme étant le protocole WebSocket associé au format de données JSON {JavaScript Object Notation) et le protocole de signalisation compatible IMS ("second protocole") est le protocole SIP {Session Initiation Protocol).
L'entité de conversion 33, encore désignée par passerelle WebRTC-IMS, est connectée d'une part au réseau Internet 1, et d'autre part, conformément à l'invention, au serveur d'application AS (31). L'interconnexion entre l'entité de conversion GW et le serveur AS peut être réalisée par l'intermédiaire d'un réseau NW tel qu'un réseau IP d'un opérateur de réseau ou bien par une connexion directe, par exemple lorsque l'entité de conversion (33) est incluse dans le serveur d'application AS (31) pour former ainsi serveur d'application 3 incluant une telle entité de conversion.
Le serveur d'application (AS) 31 est destiné à fournir des services de communication sur le cœur de réseau IMS (4). A cette fin, le serveur AS utilise de manière classique une interface de communication avec le cœur de réseau IMS, désignée par le sigle ISC pour " IP multimédia Subsystem Service Control Interfacé', et décrite dans le document 3GPP TS 23.228 section 4.2.4.
Conformément à l'invention, le serveur AS 31 comporte en outre une seconde interface de communication, cette fois-ci avec l'entité de conversion 33. Cette seconde interface comprend notamment, d'un point de vue fonctionnel, un module de réception de premières requêtes de communication selon un protocole de communication prédéterminé ("premier protocole"), en provenance de l'entité de conversion, chacune de ces premières requêtes étant émise par un terminal d'appelant identifié par un identifiant WebRTC, à destination d'un appelé identifié par un identifiant de joignabilité IMS. Le premier protocole de communication peut être un protocole tel que SIP lorsque l'entité de conversion, distincte du serveur d'application (31), est connectée à ce dernier via un réseau IP (NW), ou bien un protocole propriétaire lorsque l'entité de conversion (33) est incluse dans le serveur d'application AS (31).
De plus, le serveur d'application (AS) 31 comprend :
- un premier module de traitement de requêtes, configuré pour obtenir, après réception d'une première requête telle que définie ci-dessus, un identifiant de joignabilité IMS de l'appelant à partir de son l'identifiant WebRTC ;
- un premier module de transmission de requêtes, configuré pour transmettre en conséquence, sur le cœur de réseau IMS à destination de l'appelé, une seconde requête de communication selon le protocole SIP contenant l'identifiant de joignabilité IMS de l'appelant— obtenu par le premier module de traitement de requête—, dans le but d'établir au travers de l'entité de conversion, une communication média entre le terminal de l'appelant et un terminal de l'appelé.
Le serveur d'application (AS) comprend par ailleurs :
- un second module de réception de premières requêtes de communication selon le protocole SIP ("premier protocole"), en provenance de la première interface de communication, chacune desquelles étant émise via le cœur de réseau IMS par un terminal d'un appelant identifié par un identifiant de joignabilité IMS, à destination d'un appelé identifié par un identifiant de joignabilité IMS ;
- un second module de traitement de requêtes, configuré pour déterminer suite à la réception d'une première requête telle que définie ci-dessus, si l'identifiant de joignabilité IMS de l'appelé correspond ou non à un abonné disposant d'un identifiant WebRTC ;
- un second module de transmission de requêtes, configuré pour transmettre si l'abonné précité dispose d'un identifiant WebRTC, à destination de l'entité de conversion, une seconde requête de communication contenant l'identifiant WebRTC déterminé, afin d'établir suite au traitement de cette seconde requête par l'entité de conversion, une communication média entre le terminal de l'appelant et un terminal correspondant à l'identifiant WebRTC de l'appelé, au travers de l'entité de conversion.
Selon le mode de réalisation choisi, le serveur d'application AS comporte en outre un module d'authentification d'un appelant identifié par un identifiant WebRTC contenu dans une première requête de communication provenant de l'entité de conversion. Selon le mode de réalisation décrit, les modules de traitement de requêtes susmentionnés sont configurés pour consulter une base de données de profils d'abonnés contenant pour chaque abonné au moins un service mis en œuvre par le serveur d'application, au moins un identifiant de joignabilité IMS, et le cas échéant au moins un identifiant WebRTC correspondant. Cette base de données (non représentée sur la figure 2) peut être incorporée dans une mémoire du serveur d'application ou accessible par ce dernier via le cœur de réseau IMS ou un autre réseau.
Selon un mode de réalisation choisi, la base de profils d'abonnés est renseignée au cours d'une opération préalable de configuration {provisioning) du serveur d'application AS.
Le serveur d'application (31) gère ainsi la connectivité SIP des clients web via la passerelle GW (WebRTC-IMS), selon un mode dynamique ou statique, selon le mode de réalisation choisi. En mode dynamique, le serveur d'application assure la fonction de serveur d'enregistrement SIP {registrar server) auprès de l'interface SIP de la passerelle GW, et cette dernière enregistre les clients web auprès du serveur d'application AS par l'intermédiaire de la base de profils d'abonnés. En mode statique, le serveur d'application dispose de l'adresse IP (via DNS, route IP statique, par exemple) de la passerelle GW et inversement, et peuvent échanger des requêtes SIP (par exemple INVITE) sur des ports UDP/TCP {User Datagram Protocol/Transmission Control Protocol) prédéfinis.
D'un point de vue de l'authentification d'un abonné correspondant à un client web, auprès du cœur de réseau IMS, plusieurs modes de réalisation sont possibles. Selon un premier mode, appelé mode de confiance {trustée/ mode), l'authentification d'un client web est effectuée au préalable sur le web par l'intermédiaire d'une interface avec le serveur d'application AS ou bien auprès du serveur web WS en relation avec la passerelle GW, toute requête provenant de cette dernière étant alors automatiquement autorisée par le serveur d'application. Ce premier mode de réalisation peut s'appliquer aussi bien en cas de connectivité statique qu'en cas de connectivité IP dynamique entre la passerelle GW et le serveur d'application AS. Selon un second mode de réalisation, l'authentification d'un client web vis-à-vis du cœur de réseau IMS peut se faire lors de l'enregistrement SIP de la passerelle GW sur le serveur d'application avec des données d'authentification {credentials) spécifiques déclarées dans le profil de l'utilisateur stocké dans la base de données de profils associée au serveur d'application. Ce second mode de réalisation est applicable seulement si la connectivité IP entre la passerelle WebRTC (GW) et le serveur d'application est dynamique. Dans les deux cas, aucun enregistrement d'un utilisateur d'un client web n'est fait directement sur le cœur de réseau IMS.
La figure 3 illustre l'architecture matérielle d'un serveur d'application AS selon l'invention. Dans le mode de réalisation décrit ici, le serveur d'application dispose de l'architecture matérielle d'un ordinateur ; il comporte notamment un processeur 3A, une mémoire morte (ROM) 3B, une mémoire vive (RAM) 3C, une mémoire non volatile 3D (disque dur par exemple) et des moyens de communication 3E avec, notamment, les entités du cœur de réseau IMS, en particulier l'ensemble de fonctions CSCF 41, et avec l'entité de conversion protocolaire GW 33. Ces moyens de communication 3E intègrent par exemple une carte réseau, connue en soi et non détaillée ici.
La mémoire morte 3B du serveur d'application (AS) constitue un support d'enregistrement lisible par le processeur 3A et sur lequel est enregistré le code d'un programme d'ordinateur dont l'exécution provoque la mise en œuvre d'un procédé de communication selon l'invention. Ce programme d'ordinateur définit de façon correspondante des modules fonctionnels du serveur AS tels que définis plus haut.
La figure 4 est un organigramme illustrant les principales étapes d'un procédé de communication selon l'invention, selon un premier exemple, mis en œuvre dans l'environnement réseau de la figure 2, entre un terminal appelant (Tl) équipé d'un client WebRTC (navigateur BRW1) et un terminal appelé (T3-T6) accessible via le cœur de réseau IMS 4. Le procédé est mis en œuvre par le serveur d'application 31, fournissant des services de communication (audio, vidéo, data ...) sur le cœur de réseau IMS 4 via son interface ICS.
Initialement, le terminal Tl transmet à destination de la passerelle WebRTC-IMS 33 (entité de conversion protocolaire) une requête de communication à destination du terminal T3. Cette requête émise selon un protocole de signalisation PI compatible WebRTC est convertie par la passerelle 33 en requête RQT1 selon un protocole P2 compatible IMS.
A l'étape S41, le serveur AS reçoit en provenance de la passerelle 33 la requête de communication RQT1 selon le protocole P2, qui contient un identifiant WebRTC (URI-U1_2) associé à l'utilisateur Ul (appelant) et un identifiant de joignabilité IMS (URI-U3) associé à l'utilisateur U3 (appelé) du terminal T3.
A l'étape S43, le serveur AS 31 traite la requête afin d'obtenir un identifiant de joignabilité IMS (URI-U1_1) de l'appelant Ul à partir de son identifiant WebRTC (URI-U1_2). A cette fin, le serveur AS consulte une base de données de profils d'abonnés, avec en donnée d'entrée l'identifiant WebRTC (URI-U1_2) de l'abonné Ul, et obtient en sortie son identifiant de joignabilité IMS (URI-U1_1) ainsi que les données relatives aux services auxquels l'abonné Ul a souscrit.
Ensuite, à l'étape S45, une seconde requête de communication (RQT2) selon le protocole P2, est créée, contenant l'identifiant de joignabilité IMS (URI-U1_1) de l'appelant Ul ainsi que l'identifiant de joignabilité IMS (URI-U3) de l'appelé U3, puis la requête est transmise sur le cœur de réseau IMS, à destination du terminal T3 de U3.
Si l'utilisateur U2 décroche son terminal T3 alors, à l'étape S47, une communication média (voix, vidéo, ...) est établie au travers de la passerelle GW 33, entre le terminal Tl de l'utilisateur Ul et le terminal T3 de l'utilisateur U3. La figure 5 est un organigramme illustrant les principales étapes d'un procédé de communication selon l'invention, selon un second exemple, mis en œuvre dans l'environnement réseau de la figure 2, entre un terminal appelant (T3-T6) accessible via le cœur de réseau IMS 4, et un terminal appelé (Tl, T2) équipé d'un client WebRTC (navigateurs BRW1, BRW2). Le procédé est mis en œuvre par le serveur d'application 31, fournissant des services de communication (audio, vidéo, data ...) sur le cœur de réseau IMS 4 via son interface ICS.
A l'étape S51, le serveur d'application AS reçoit une première requête de communication (RQTl) selon le protocole P2 (protocole de signalisation compatible IMS, SIP par exemple). Cette requête RQTl a été émise via le cœur de réseau IMS par le terminal T3 de l'utilisateur U3 (appelant) identifié par son identifiant de joignabilité IMS (URI-U3), à destination de l'utilisateur Ul identifié également par son identifiant de joignabilité IMS (URI-U1_1).
A l'étape S53, le serveur AS 31 traite la requête RQTl afin de déterminer si l'identifiant de joignabilité IMS (URI-U1_1) de l'appelé Ul correspond ou non à un abonné disposant d'un identifiant WebRTC. A cette fin, le serveur AS consulte la base de données de profils d'abonnés susmentionnée, avec en donnée d'entrée l'identifiant de joignabilité IMS (URI-U1_1) de l'utilisateur appelé Ul. Dans cet exemple, l'utilisateur Ul dispose d'un identifiant WebRTC (URI- Ul_2) qui est donc obtenu à partir de la base de données de profils.
En conséquence, à l'étape S55, une seconde requête de communication (RQT2) selon le protocole P2, est créée, contenant l'identifiant de joignabilité IMS (URI-U3) de l'appelant U3 ainsi que l'identifiant WebRTC (URI-U1_2) obtenu pour l'appelé Ul, puis la requête est transmise à la passerelle GW 33.
La passerelle GW 33 traduit alors la requête RQT2 en une requête selon le protocole PI (compatible WebRTC) et la transmet via le réseau Internet INT, au navigateur BRW1 du terminal (Tl) de l'utilisateur appelé (Ul).
Si l'utilisateur Ul décroche son terminal (Tl) alors, à l'étape S57, une communication média (voix, vidéo, ...) est établie au travers de la passerelle GW 33, entre le terminal T3 de l'utilisateur U3 et le terminal Tl de l'utilisateur Ul.
En relation avec la figure 6, on va à présent détailler le processus de communication selon l'invention entre un terminal appelant équipé d'un client WebRTC et un terminal appelé accessible via un cœur de réseau IMS. Ce processus a déjà été exposé brièvement en liaison avec la figure 4.
Dans cet exemple de mise en œuvre de l'invention, on suppose que l'utilisateur Ul dispose de deux identités : un identifiant de joignabilité IMS (URI-U1_1), dans cet exemple une identité SIP connue de l'IMS et publique, c'est-à-dire "routable" depuis des réseaux d'interconnexion tels qu'un réseau PSTN (431) ou un réseau privé d'entreprise connecté par une passerelle (BOX 411) à l'IMS ; et un identifiant web connu par le serveur d'application AS (base de données de profils) et par des équipements connectés au web (serveurs web, etc.). L'utilisateur Ul (appelant) se connecte au préalable (connexion non illustrée sur la figure 6) via son terminal Tl (équipé du navigateur Web BRW1) au serveur web WS, afin de télécharger une page web d'accès à un environnement de communication, et sélectionne via une interface graphique affichée sur l'écran de son terminal, un identifiant associé à l'utilisateur U3 (appelé) afin d'établir une communication média à partir de son navigateur.
L'identifiant sélectionné pour l'utilisateur U3 est par exemple son numéro de téléphone sur le réseau de téléphonie PSTN (431), qui est transmis à la passerelle WebRTC (GW 33) par le terminal Tl, dans un message de requête M601.
Dans l'exemple de réalisation décrit, le message M601 est un message au format JSON utilisant le protocole de communication WebSocket au-dessus du protocole HTTP {HyperText Transfer Protocd). Ce message est de la forme suivante :
{request "offer" caller : URI-Ul_2f callee : IDJJ3}
où URI-U1_2 désigne l'identifiant web associé à l'utilisateur web appelant \ l{caller), par exemple une adresse email (userUl@orange.fr) ; et ID_U3 désigne l'identifiant réseau associé à l'utilisateur U3 appelé {callee) dans le réseau PSTN, par exemple un numéro de téléphone : +33123456789.
Le message de requête M601 est reçu par la passerelle GW qui le convertit en message de requête M603 conforme au protocole SIP, qui est ensuite transmis au serveur d'application AS. Le message SIP M603 est de la forme suivante :
INVITE [SDP_U1]
R-URI : URI-U3
From : URI-U1_2
To : URI-U3
Contact <SIP URI GW>
Où URI-U3 désigne l'identifiant de joignabilité IMS de l'utilisateur U3 obtenu à partir de l'identifiant réseau ID_U3 de l'utilisateur U3. Par exemple, si ID_U3 = '+33123456789', alors URI-U3 = "sip : +33123456789@sip.osp.com ; user= phone" ; de manière générale, URI-U3 est de la forme générale ID_U3@domain, où domain désigne un domaine SIP.
Lorsque le message de requête M603 est reçu par le serveur d'application AS, celui-ci applique un traitement S605 qui correspond à l'étape S43 décrite en liaison avec la figure 4, consistant à obtenir à partir de l'identifiant web URI-U1_2 de l'utilisateur Ul (appelant) un identifiant de joignabilité IMS correspondant URI-U1_1. En pratique, URI-U1_1 est de la forme générale :
URI-U1_1 = "sip : "userUWdomain"
Où 'UserUl' désigne un identifiant IMS. L'identifiant IMS 'UserUl' peut être une identité publique, c'est-à-dire routable dans le réseau IMS à partir de réseaux externes (PSTN ...), tel qu'un numéro téléphonique long (par exemple, URI ou SIP URI avec un préfixe utilisateur contenant un numéro au format global el64). Un exemple d'identifiant IMS public est donné ci-dessous :
sip : +33145294795@orange.com ; user = phone
L'identifiant IMS 'UserUl' peut être également une identité IMS privée, c'est-à-dire connue seulement de l'IMS pour l'acheminement d'appels vers un autre abonné IMS ; un tel identifiant IMS privé peut être par exemple un numéro court ou une extension SIP URI dont le préfixe utilisateur n'est pas nécessairement un numéro, etc.
Ensuite, le serveur d'application AS crée une seconde requête, M607, selon le protocole SIP, à l'initiative du serveur AS pour transmettre dans le cœur de réseau l'appel vers l'utilisateur U3 au nom de l'utilisateur Ul.
En pratique, cette seconde requête est une requête dans lequel le serveur agit selon le mode "originating" tel que défini notamment à la section 5.7.3 de la spécification 3GPP TS 24.229 V12.6.0 (2014-09) - Technical Spécification Group Core Network and Terminais; IP multimédia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 12).
La seconde requête M607 est de la forme suivante :
INVITE [SDP_U1]
R-URI : URI-U3
From : URI-U1_1
PAI : URI-U1_1
To : URI-U3
Route : URI-ICSCF; orig; no services
La requête M607 est alors transmise à l'entité ICSCF du cœur de réseau IMS. L'entité ICSCF transmet alors une requête M609 correspondante, à destination du terminal T3 de l'utilisateur U3 (appelé), via des entités BGCF {Breakout Gateway Control Function) et MGCF du cœur de réseau IMS. La requête M609 est de la forme suivante :
INVITE [SDP_U1]
R-URI : URI-U3
From : URI-U1_1
PAI : URI-U1_1
To : URI-U3
Route : URI-MGCF
Suite à la réception de la requête M609, le terminal T3 émet un message de retour de sonnerie à l'entité MGCF qui le convertit en un message M611 de réponse SIP de type '180 RINGING' indiquant la bonne réception de la demande de communication (M609) par le destinataire T3. L'entité ICSCF reçoit le message M611 et transmet à son tour un message M613 au serveur d'application AS. Ce dernier change dans le message reçu l'identifiant de joignabilité IMS (URI-U1_1) de l'utilisateur Ul en l'identifiant web correspondant (URI-U1_2) et transmet un message modifié M615 à la passerelle GW. Cette dernière convertit alors le message de type '180 RINGING' reçu (M615) en un message de réponse (M617) selon le protocole compatible web correspondant, c'est-à-dire un message au format JSON selon le protocole WebSocket, et le transmet au terminal Tl (navigateur BRW1).
Le message de réponse M617 est de la forme suivante :
{request "initial answer to call"}
Les messages M619-M625 sont de manière similaire des messages de type SIP '200 OK' qui sont propagés du terminal appelé T3 vers le terminal appelant Tl pour indiquer que la requête de communication a réussi, le dernier message, M625, étant de la forme suivante :
{request "final answer to call"}
La demande de communication du terminal Tl vers le terminal T3 se termine par l'envoi d'un message d'acquittement (ACK), indiquant que la demande de communication est terminée, propagé sous forme de messages successifs (M629-M633) par les différents équipements (GW, AS, CSCF, MGCF) situés entre le terminal Tl et le terminal T3, à partir d'un message M627 initial émis par le terminal Tl, de la forme : {request "call complète"}.
Le terminal appelé T3 ayant répondu favorablement à la demande de communication, une communication média (voix et/ou vidéo par exemple) est établie (S635, S637) entre le terminal Tl et le terminal T3 via notamment la passerelle GW et les équipements IMS impliqués dans le routage du flux média (proxy média ...)■ En pratique, le flux média entre le terminal T3 et la passerelle GW est établi selon le protocole RTP {Real-time Transport Protocol), tandis que le flux média établi entre la passerelle GW et le terminal Tl est établi selon le protocole SRTP (Secure RTP).
En relation avec la figure 7, on va à présent détailler un processus de communication selon l'invention entre un terminal appelant accessible via un cœur de réseau IMS et un terminal appelé équipé d'un client WebRTC. Ce processus a déjà été exposé brièvement en liaison avec la figure 5.
Dans cet exemple de mise en œuvre de l'invention, on suppose encore que l'utilisateur Ul dispose de deux identités : un identifiant de joignabilité IMS (URI-U1_1), dans cet exemple une identité SIP connue de l'IMS et publique, c'est-à-dire "routable" depuis des réseaux d'interconnexion tels qu'un réseau PSTN (431) ou un réseau privé d'entreprise connecté par une passerelle (BOX 411) à l'IMS ; et un identifiant web connu par le serveur d'application AS (base de données de profils) et par des équipements connectés au web (serveurs web, etc.). On suppose que le profil d'abonné de l'utilisateur Ul a été activé au préalable auprès du serveur d'application AS, ce qui permet d'acheminer automatiquement des appels issus du cœur de réseau IMS vers son navigateur web (BRW1).
A la figure 7, l'utilisateur U3 (appelant) émet via son terminal téléphonique T3, identifié par l'identifiant URI-U3 sur le réseau PSTN 431, un appel à destination d'un identifiant publique (identifiant de joignabilité IMS : URI-U1_1) de l'utilisateur Ul, connu du cœur de réseau IMS et du serveur d'application AS, par exemple un numéro de téléphone direct (utilisant la technique SDA - Sélection Directe à l'Arrivée). L'appel se traduit au niveau de l'équipement MGCF par un message de requête M701 SIP INVITE de la forme suivante :
INVITE [SDP_U3]
R-URI : URI-U1_1
From : URI-U3
To : URI-U1_1
Le message de requête M701 est reçu par l'entité I/S-CSCF du cœur de réseau IMS, qui émet à son tour un message M703 SIP INVITE en mode terminating à destination du serveur d'application AS. Le message M703 est de la forme suivante :
INVITE [SDP_U3]
R-URI : URI-U1_1
From : URI-U3
To : URI-U1_1
Route : URI-AS;lr;
Mode=terminating
Le message M703 est reçu par l'interface ISC du serveur d'application AS qui effectue un traitement S705 au cours duquel il consulte la base de données de profils d'abonnés et détermine que l'appelé Ul identifié dans le message de requête par son identifiant de joignabilité IMS 'URI-U1_1' possède également l'identifiant WebRTC 'URI-U1_2' ; et émet à destination de la passerelle GW, un message M707 de requête SIP INVITE, dans lequel l'identifiant WebRTC de l'appelé Ul remplace son identifiant de joignabilité IMS. Le message M 707 est de la forme suivante :
INVITE [SDP_U3]
R-URI : URI-U1_2
From : URI-U3
To : URI-U1_2
Contact : URI-AS La passerelle GW reçoit le message SIP M707 et effectue une conversion de signalisation SIP vers WebRTC, et émet sur le web (Internet) un message M709 de requête au format JSON utilisant le protocole de communication WebSocket (au-dessus du protocole HTTP) à destination du navigateur du terminal Tl de l'appelé Ul. Le message M709 est de la forme suivante :
{request "offer" caller : URI-U3, callee : URI-U1_2}
Le navigateur web du terminal Tl émet alors un message JSON de réponse M711 de la forme suivante est envoyé à la passerelle GW :
{request "initial answer to call"}
Le message M711 est reçu par la passerelle GW qui le convertit en un message SIP
M713 de type RINGING de la forme :
180 RINGING
From : URI-U3
To : URI-U1_2
Le message M713 est reçu par le serveur d'application AS qui émet à son tour à destination de l'entité I/S-CSCF un message M715 SIP Ί80 RINGING' dans lequel l'identifiant webRTC (URI-U1_2) de l'appelé Ul est remplacé par l'identifiant de joignabilité IMS correspondant (URI-U1_1). Le message M715 et de la forme suivante :
180 RINGING
From : URI-U3
To : URI-U1_1
Le message SIP M715 est reçu par l'entité I/S-CSCF qui émet à son tour un message SIP RINGING, M717, à destination du terminal T3 de l'appelant U3 via l'entité MGCF.
Si l'appelé Ul accepte la demande de communication via le navigateur web de son terminal, un message JSON de réponse M719 de la forme suivante est alors envoyé à la passerelle GW :
{request "final answer to call"}
Le message M719 est reçu par la passerelle GW qui le convertit en un message SIP,
M 721, de type '200 OK' suivant :
200 OK SDP [ SDP_ Ul ]
From : URI-U3
To : URI-U1_2
Le message M721 est reçu par le serveur AS qui émet à son tour à destination de l'entité I/S-CSCF un message, M723, SIP 200 OK dans lequel l'identifiant webRTC (URI-U1_2) de l'appelé Ul est remplacé par l'identifiant de joignabilité IMS correspondant (URI-U1_1). Le message M723 et de la forme suivante :
200 OK SDP [SDP_U1]
From : URI-U3
To : URI-U1_1
Le message SIP M723 est reçu par l'entité I/S-CSCF qui émet à son tour un message SIP 200 OK, M725, à destination du terminal T3 de l'appelant U3 via l'entité MGCF.
Le terminal T3 émet alors un message d'acquittement (ACK) M727 qui est propagé sous forme de messages successifs (M729-M731) par les différents équipements (MGCF, I/S-CSCF, AS) jusqu'à la passerelle GW qui convertit le dernier message ACK (M731) en message WebRTC M733, émis à destination du terminal T3.
Le message M733 est de la forme suivante : {request "call complète"}
La communication média (voix et/ou vidéo par exemple) peut alors être établie (S735, S737) entre le terminal T3 et le terminal Tl via notamment la passerelle GW et les équipements IMS impliqués dans le routage du flux média (proxy média ...)■ En pratique, le flux média entre le terminal T3 et la passerelle GW est établi selon le protocole RTP {Real-time Transport Protocol), tandis que le flux média établi entre la passerelle GW et le terminal Tl est établi selon le protocole SRTP (Secure RTP).
Le procédé de communication selon l'invention permet ainsi, notamment, de fournir à un terminal équipé d'un client de type WebRTC, connecté à un premier réseau, de type Internet, un accès à un service de communication fourni par l'intermédiaire d'un serveur d'application sur un second réseau, de type IMS, par l'intermédiaire d'une passerelle de traduction de signalisation WebRTC en signalisation IMS.

Claims

REVENDICATIONS
1. Procédé de communication entre un terminal (Tl, T2)) équipé d'un client WebRTC et un terminal (T3-T6) accessible via un cœur de réseau IMS (4), ledit procédé étant mis en œuvre par un serveur d'application (31) configuré pour fournir des services de communication sur le cœur de réseau IMS, ledit procédé étant caractérisé en ce qu'il comporte des étapes de :
- réception (S41) en provenance d'une entité (33) de conversion bidirectionnelle de messages selon un premier protocole de signalisation compatible WebRTC en messages selon un second protocole de signalisation compatible IMS, d'une première requête (RQT1) de communication selon le second protocole, ladite première requête étant obtenue par conversion en ladite première requête d'une requête initiale selon le premier protocole émise par un terminal (Tl) équipé d'un client WebRTC, d'un appelant (Ul) identifié par un identifiant WebRTC (URI-U1_2) inclus dans ladite première requête, et ladite première requête étant destinée à un appelé (U3) identifié par un identifiant de joignabilité IMS (URI-U3) ;
- traitement (S43) de la première requête afin d'obtenir un identifiant de joignabilité IMS (URI-U1_1) à partir de l'identifiant WebRTC (URI-U1_2) de l'appelant ;
- transmission (S45) sur le cœur de réseau IMS (4), à destination de l'appelé (U3), d'une seconde requête (RQT2) de communication selon le second protocole contenant l'identifiant de joignabilité IMS (URI-U1_1) de l'appelant, en vue d'établir une communication média (S47) au travers de l'entité de conversion (GW), entre le terminal (Tl) de l'appelant et un terminal (T3) de l'appelé.
2. Procédé selon la revendication 1, comportant des étapes de :
- réception (S51) d'une troisième requête de communication selon le second protocole émise via le cœur de réseau IMS par un terminal (T3) d'un appelant identifié par un identifiant de joignabilité IMS (URI-U3), à destination d'un appelé identifié par un identifiant de joignabilité IMS (URI-U1_1) contenu dans ladite troisième requête;
- traitement (S53) de la troisième requête afin de déterminer si l'identifiant de joignabilité IMS (URI-U1_1) de l'appelé correspond ou non à un abonné disposant d'un identifiant WebRTC, et si c'est le cas,
- transmission (S55) à destination de l'entité de conversion d'une quatrième requête de communication contenant l'identifiant WebRTC déterminé (URI-U1_2), en vue de l'établissement, au travers de l'entité de conversion, d'une communication média (S57) entre le terminal (T3) de l'appelant et un terminal (Tl) correspondant à l'identifiant WebRTC de l'appelé.
3. Procédé selon la revendication 1 ou 2, dans lequel le traitement de la première et de la troisième requête comprend la consultation d'une base de données de profils d'abonnés contenant pour chaque abonné au moins un service mis en œuvre par le serveur d'application, au moins un identifiant de joignabilité IMS, et le cas échéant au moins un identifiant WebRTC correspondant.
4. Procédé selon l'une des revendications précédentes, comprenant une étape d'authentification d'un appelant identifié par un identifiant WebRTC contenu dans ladite première requête de communication provenant de l'entité de conversion.
5. Procédé selon l'une des revendications précédentes, dans lequel le premier protocole est le protocole WebSocket et le second protocole est le protocole SIP (Session Initiation Protocol).
6. Serveur d'application (AS) configuré pour fournir des services de communication sur un cœur de réseau IMS, caractérisé en ce qu'il comporte :
- des premiers moyens de réception en provenance d'une entité de conversion bidirectionnelle de messages selon un premier protocole de signalisation compatible WebRTC, en messages selon un second protocole de signalisation compatible IMS, d'une première requête de communication selon le second protocole, ladite première requête étant obtenue par conversion en ladite première requête d'une requête initiale selon le premier protocole émise par un terminal d'un appelant identifié par un identifiant WebRTC inclus dans ladite première requête, à destination d'un appelé identifié par un identifiant de joignabilité IMS contenu dans ladite troisième requête;
- des premiers moyens de traitement de requête, configurés pour obtenir un identifiant de joignabilité IMS de l'appelant à partir de l'identifiant WebRTC de l'appelant ;
- des premiers moyens de transmission sur le cœur de réseau IMS, à destination de l'appelé, d'une seconde requête de communication selon le second protocole, contenant l'identifiant de joignabilité IMS de l'appelant, en vue de l'établissement, au travers de l'entité de conversion, d'une communication média entre le terminal de l'appelant et un terminal de l'appelé.
7. Serveur selon la revendication 6, comprenant en outre :
- des seconds moyens de réception d'une troisième requête de communication selon le second protocole émise via le cœur de réseau IMS par un terminal d'un appelant identifié par un identifiant de joignabilité IMS, à destination d'un appelé identifié par un identifiant de joignabilité IMS ;
- des seconds moyens de traitement de requête, configurés pour déterminer si l'identifiant de joignabilité IMS de l'appelé correspond ou non à un abonné disposant d'un identifiant WebRTC ;
- des seconds moyens de transmission à destination de l'entité de conversion, d'une quatrième requête de communication contenant un identifiant WebRTC déterminé par les seconds moyens de traitement de requête, suite à la réception de la troisième requête, en vue de l'établissement d'une communication média entre le terminal de l'appelant et un terminal correspondant à l'identifiant WebRTC de l'appelé, au travers de l'entité de conversion.
8. Serveur selon l'une des revendications 6 ou 7, dans lequel les premiers et seconds moyens de traitement de requête sont configurés pour consulter une base de données de profils d'abonnés contenant pour chaque abonné au moins un service mis en œuvre par le serveur d'application, au moins un identifiant de joignabilité IMS, et le cas échéant au moins un identifiant WebRTC correspondant.
9. Serveur selon l'une quelconque des revendications 6 à 8, incluant ladite entité de conversion.
10. Serveur selon l'une quelconque des revendications 6 à 9, comprenant en outre des moyens d'authentification d'un appelant identifié par un identifiant WebRTC contenu dans ladite première requête de communication provenant de l'entité de conversion.
11. Programme d'ordinateur comprenant des instructions de programme dont l'exécution par un processeur incorporé dans un serveur d'application met en œuvre un procédé de communication selon l'une quelconque des revendications 1 à 5.
PCT/FR2015/053232 2014-11-27 2015-11-26 Procede de communication entre un terminal equipe d'un client webrtc et un terminal accessible via un cœur de reseau ims Ceased WO2016083751A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1461591 2014-11-27
FR1461591A FR3029379A1 (fr) 2014-11-27 2014-11-27 Procede de communication entre un terminal equipe d' un client webrtc et un terminal accessible via un coeur de reseau ims

Publications (1)

Publication Number Publication Date
WO2016083751A1 true WO2016083751A1 (fr) 2016-06-02

Family

ID=52692779

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2015/053232 Ceased WO2016083751A1 (fr) 2014-11-27 2015-11-26 Procede de communication entre un terminal equipe d'un client webrtc et un terminal accessible via un cœur de reseau ims

Country Status (2)

Country Link
FR (1) FR3029379A1 (fr)
WO (1) WO2016083751A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10819852B2 (en) 2018-09-21 2020-10-27 Motorola Solutions, Inc. Device, system and method for communicating between devices using two protocols
CN111935440A (zh) * 2020-08-13 2020-11-13 安康鸿天科技股份有限公司 一种基于ims系统实时视频通信的全场景协同装置与方法
US11095691B2 (en) 2019-06-26 2021-08-17 Oracle International Corporation Methods, systems, and computer readable media for establishing a communication session between a public switched telephone network (PSTN) endpoint and a web real time communications (WebRTC) endpoint
US11561997B2 (en) 2019-03-13 2023-01-24 Oracle International Corporation Methods, systems, and computer readable media for data translation using a representational state transfer (REST) application programming interface (API)
CN115913557A (zh) * 2021-08-04 2023-04-04 中国移动通信有限公司研究院 多媒体信息的传输方法、终端及通信平台

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8695077B1 (en) * 2013-03-14 2014-04-08 Sansay, Inc. Establishing and controlling communication sessions between SIP devices and website application servers
US20140222930A1 (en) * 2013-02-04 2014-08-07 Oracle International Corporation Browser/html friendly protocol for real-time communication signaling

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140222930A1 (en) * 2013-02-04 2014-08-07 Oracle International Corporation Browser/html friendly protocol for real-time communication signaling
US8695077B1 (en) * 2013-03-14 2014-04-08 Sansay, Inc. Establishing and controlling communication sessions between SIP devices and website application servers

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Web Real Time Communication (WebRTC) access to IP Multimedia Subsystem (IMS); Stage 2 (Release 12)", 17 December 2013 (2013-12-17), XP050906652, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Specs/2014-12/Rel-12/23_series/> [retrieved on 20131217] *
"c nical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS)", 3GPP TS 23.228, September 2014 (2014-09-01)
"IP multimedia Subsystem Service Control Interface", 3GPP TS 23.228
"Technical Specification Group Core Network and Terminals; IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)", 3GPP TS 24.229 V12.6.0, September 2014 (2014-09-01)
OVERVIEW: REAL TIME PROTOCOLS FOR BROWSER-BASED APPLICATIONS, 18 August 2014 (2014-08-18)
WEBRTC 1.0: REAL-TIME COMMUNICATION BETWEEN BROWSERS, 10 September 2013 (2013-09-10)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10819852B2 (en) 2018-09-21 2020-10-27 Motorola Solutions, Inc. Device, system and method for communicating between devices using two protocols
US11561997B2 (en) 2019-03-13 2023-01-24 Oracle International Corporation Methods, systems, and computer readable media for data translation using a representational state transfer (REST) application programming interface (API)
US11095691B2 (en) 2019-06-26 2021-08-17 Oracle International Corporation Methods, systems, and computer readable media for establishing a communication session between a public switched telephone network (PSTN) endpoint and a web real time communications (WebRTC) endpoint
CN111935440A (zh) * 2020-08-13 2020-11-13 安康鸿天科技股份有限公司 一种基于ims系统实时视频通信的全场景协同装置与方法
CN111935440B (zh) * 2020-08-13 2022-07-19 安康鸿天科技股份有限公司 一种基于ims系统实时视频通信的全场景协同装置与方法
CN115913557A (zh) * 2021-08-04 2023-04-04 中国移动通信有限公司研究院 多媒体信息的传输方法、终端及通信平台

Also Published As

Publication number Publication date
FR3029379A1 (fr) 2016-06-03

Similar Documents

Publication Publication Date Title
EP3155791B1 (fr) Procédé d&#39;établissement d&#39;une session webrtc
EP3417591B1 (fr) Procédé et serveur de sélection d&#39;un serveur d&#39;entrée d&#39;un réseau de communication ims
WO2010109125A1 (fr) Procede et dispositif de traitement d&#39;une information indicatrice d&#39;un souhait d&#39;implication dans au moins une session applicative d&#39;un utilisateur
WO2016083751A1 (fr) Procede de communication entre un terminal equipe d&#39;un client webrtc et un terminal accessible via un cœur de reseau ims
WO2007042661A1 (fr) Procédé et serveur d&#39;invocation des serveurs d&#39;application dans un réseau sip
WO2014184504A1 (fr) Procédé de communication en temps réel entre navigateurs web
EP3646554B1 (fr) Procédé de traitement d&#39;une requête et serveur d&#39;un coeur de réseau ip multimédia
WO2014083289A1 (fr) Routage d&#39;une requete de service visant un abonne ims
EP2856732A1 (fr) Procédé et entité de traitement d&#39;un message
EP2266279B1 (fr) Partage de contenu multi supports a partir d&#39;une communication audio-video
EP3235217B1 (fr) Procédé d&#39;échanges de données entre deux navigateurs internet, équipement de routage, terminal, programme d&#39;ordinateur et support d&#39;informations corespondants
EP3560168A1 (fr) Classification et aiguillage de messages de contrôle d&#39;une infrastructure de communications
FR3030958A1 (fr) Procede et dispositif de communication entre un terminal sip et un serveur web
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
EP3014848B1 (fr) Procédé de gestion de terminaux fixes et mobiles dans un environnement comprenant un réseau mobile incluant un réseau ims et un réseau d&#39;entreprise
EP1995930B1 (fr) Procédé de transcodage de sessions de type SIP
EP2073493A1 (fr) Procédé de communication multimédia, serveur et produit programme d&#39;ordinateur correspondants
WO2017220883A1 (fr) Procédé de détermination d&#39;un ensemble de formats de codage pour établir une communication
WO2013121158A1 (fr) Procédé d&#39;enregistrement d&#39;un serveur d&#39;application et serveur d&#39;application
WO2010112738A1 (fr) Procede d&#39;envoi d&#39;un message de notification, serveur de sessions d&#39;acces et systeme de communications
WO2012076796A1 (fr) Gestion de service dans un reseau
WO2006082307A2 (fr) Procede et systeme d’enregistrement d’utilisateurs, serveur hss et serveur application d’un reseau ims
FR2892254A1 (fr) Procede de telecommunication pour un reseau du type ims, serveur et terminal implementant un tel procede
EP2651093A1 (fr) Procédé d&#39;appairage d&#39;un élément de sécurité à un terminal de télécommunications et système correspondant

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15808750

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15808750

Country of ref document: EP

Kind code of ref document: A1