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_2 _f 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.