(19)
(11)EP 3 155 791 B1

(12)FASCICULE DE BREVET EUROPEEN

(45)Mention de la délivrance du brevet:
29.07.2020  Bulletin  2020/31

(21)Numéro de dépôt: 15733791.6

(22)Date de dépôt:  03.06.2015
(51)Int. Cl.: 
H04L 29/08(2006.01)
H04L 29/06(2006.01)
(86)Numéro de dépôt:
PCT/FR2015/051468
(87)Numéro de publication internationale:
WO 2015/189499 (17.12.2015 Gazette  2015/50)

(54)

PROCÉDÉ D'ÉTABLISSEMENT D'UNE SESSION WEBRTC

VERFAHREN ZUR EINRICHTUNG EINER WEBRTC-SITZUNG

METHOD FOR SETTING UP A WEBRTC SESSION


(84)Etats contractants désignés:
AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

(30)Priorité: 10.06.2014 FR 1455262

(43)Date de publication de la demande:
19.04.2017  Bulletin  2017/16

(73)Titulaire: ORANGE
75015 Paris (FR)

(72)Inventeur:
  • CHATRAS, Bruno
    F-75012 Paris (FR)


(56)Documents cités: : 
CN-A- 103 581 397
  
  • "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 12)", 3GPP STANDARD; 3GPP TS 23.228, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. SA WG2, no. V12.3.0, 13 décembre 2013 (2013-12-13), pages 1-298, XP050728768,
  • jesse hollington: "The Complete Guide to FaceTime: Set-up, Use, and Troubleshooting Problems (2010)", ilounge.com , 30 décembre 2010 (2010-12-30), XP002735496, Extrait de l'Internet: URL:http://www.ilounge.com/index.php/artic les/comments/the-complete-guide-to-facetim e-set-up-use-and-troubleshooting-problems- 2010 [extrait le 2015-02-04]
  • Alan B Johnston ET AL: "WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web", , 1 June 2013 (2013-06-01), pages 1-254, XP055316491, ISBN: 978-0-9859788-5-3 Retrieved from the Internet: URL:http://www.docfoc.com/webrtc-apis-and- rtcweb-protocols-of-the-html5-real-time-we b-second-editionpdf [retrieved on 2016-11-04]
  • FETTE GOOGLE I ET AL: "The WebSocket Protocol; rfc6455.txt", THE WEBSOCKET PROTOCOL; RFC6455.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARD, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 11 December 2011 (2011-12-11), pages 1-71, XP015081377, [retrieved on 2011-12-11]
  • BAZ CASTILLO J MILLAN VILLEGAS VERSATICA V PASCUAL QUOBIS I: "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP); draft-ietf-sipcore-sip-websocket-10.txt", THE WEBSOCKET PROTOCOL AS A TRANSPORT FOR THE SESSION INITIATION PROTOCOL (SIP); DRAFT-IETF-SIPCORE-SIP-WEBSOCKET-10.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZE, 29 November 2013 (2013-11-29), pages 1-24, XP015092773, [retrieved on 2013-11-29]
  
Il est rappelé que: Dans un délai de neuf mois à compter de la date de publication de la mention de la délivrance de brevet européen, toute personne peut faire opposition au brevet européen délivré, auprès de l'Office européen des brevets. L'opposition doit être formée par écrit et motivée. Elle n'est réputée formée qu'après paiement de la taxe d'opposition. (Art. 99(1) Convention sur le brevet européen).


Description

1. Domaine de l'invention



[0001] La demande d'invention se situe dans le domaine des communications électroniques à l'aide de terminaux mobiles, et plus particulièrement dans le domaine des communications WebRTC (Web Real-Time Communication, ou communication web en temps réel).

2. Etat de la technique antérieure



[0002] La technologie WebRTC permet d'établir une session de communication voix et vidéo à partir d'un navigateur Web et par extension d'une application dont le comportement externe est équivalent à celui d'un navigateur. Aujourd'hui, pour lancer une communication utilisant la technologie WebRTC depuis un téléphone mobile (typiquement un Smartphone), l'utilisateur doit généralement lancer un navigateur compatible (ex : Chrome) puis cibler une URL (Uniform Resource Locator, ou adresse web) particulière, correspondant au service WebRTC qu'il souhaite utiliser. Le navigateur reçoit en retour une page HTML5 (HyperText Markup Language version 5, format de représentation de pages web) encapsulant du code JavaScript (langage de programmation de scripts principalement utilisé dans les pages web interactives) lui permettant de saisir le numéro qu'il souhaite appeler ou de le sélectionner dans un carnet d'adresse hébergé par le serveur ou dans un carnet d'adresse du mobile ou de la carte UICC (Universal Integrated Circuit Card, ou carte universelle à circuit intégré, aussi connue sous le nom de carte SIM, pour Subscriber Identification Module, ou module d'identification d'abonné), si le code encapsulé dans la page HTML5 le prévoit, et le terminal mobile le permet.

[0003] Cette manière de faire n'est pas optimale du point de vue ergonomique puisqu'elle nécessite une double saisie (saisie de l'URL, puis saisie du numéro de téléphone du destinataire). Elle impose également à l'utilisateur de connaître l'URL à utiliser, selon qu'il souhaite que ces appels soient traités par son opérateur mobile, par exemple via une passerelle vers l'IMS (IP Multimedia Subsystem, ou sous-système IP multimédia, système permettant aux opérateurs de télécommunications électroniques de fournir des services multimédias fixes et mobiles), ou par un fournisseur de service tiers.

[0004] Cette manière de faire n'est pas non plus optimale du point de vue de la qualité de service, car elle peut conduire l'utilisateur à passer par un service qui n'est pas celui de son opérateur mobile, de sorte qu'il ne puisse pas bénéficier des mêmes services que si l'appel était passé passé en utilisant le logiciel natif d'un terminal mobile, qu'il s'agisse d'un client IMS pour un terminal compatible VoLTE (Voice over LTE, ou voix sur LTE; LTE, Long Term Evolution, est le nom de l'évolution la plus récente des normes de téléphonie mobile aussi connue sous l'appellation 4G) ou d'un logiciel permettant de passer des appels en mode circuit.

[0005] Le protocole WebSocket, transporté par le protocole SIP, permet des communications bidirectionnelles en temps réel à l'aide d'applications Web, mais ne remédie pas aux inconvénients ci-dessus. On en trouve des descriptions dans "WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web", de Alan Johnston et al., 1er juin 2013, ISBN 978-0-9859788-5-3, ou dans le document RFC6455, 11 décembre 2011, IETF, Internet Society, ou dans le document "draft-ietf-sipcore-sip-websocket-10.txt", 29 novembre 2013, IETF, Internet Society.

[0006] Un des buts de l'invention est de remédier à ces inconvénients de l'état de la technique.

3. Exposé de l'invention



[0007] L'invention vient améliorer la situation à l'aide d'un procédé d'établissement d'une session entre un premier terminal mobile et un deuxième terminal, conforme à la revendication 1.

[0008] Afin d'établir une communication de type WebRTC, un premier terminal se connecte à un serveur WebRTC, reçoit un formulaire html ou du code JavaScript qu'il utilise pour demander une session avec un deuxième terminal. Le premier terminal utilise pour cela un navigateur Web échangeant des requêtes HTTP ou des messages SIP avec le serveur WebRTC, par exemple.

[0009] Le serveur traite la demande de session et émet vers le deuxième terminal une demande de session de la part du premier terminal.

[0010] La demande de session émise par le premier terminal comprend une liste de paramètres de session, par exemple une liste de codecs que le premier terminal est capable d'utiliser. Cette liste est transmise par le serveur au deuxième terminal.

[0011] Si le deuxième terminal accepte la demande de session émise par le serveur de la part du premier terminal, il répond selon un processus similaire mais dans l'autre sens, en indiquant un sous-ensemble de paramètres de session qu'il est capable de mettre en oeuvre, par exemple une sous-listes de codecs du premier terminal qu'il est capable d'utiliser.

[0012] La session est enfin établie directement entre le premier et le deuxième terminal, utilisant des paramètres de session communs aux deux terminaux, tels que par exemple un codec commun.

[0013] Cette procédure d'établissement de session n'est possible que si le premier terminal est capable d'obtenir l'identifiant du bon serveur WebRTC afin de s'y connecter.

[0014] Avantageusement, grâce au procédé d'établissement d'une session selon l'invention, la sélection du serveur WebRTC est effectué par un module d'abonné compris dans le premier terminal, par exemple une carte SIM. Ce module comprend, en plus des identifiants d'abonné et d'opérateur mobile, un identifiant du serveur WebRTC, qui peut être une adresse partielle ou complète du serveur, par exemple sous la forme d'une URL. L'utilisateur ou l'abonné n'a plus besoin de sélectionner lui-même un serveur WebRTC, ni à entrer lui-même l'URL de ce serveur dans un navigateur. La sélection du serveur WebRTC est effectuée par son opérateur mobile, en adéquation optimale avec les caractéristiques du réseau géré par celui-ci.

[0015] Selon un aspect de l'invention, le module d'abonné est une carte SIM. L'abonné peut ainsi changer de terminal mobile tout en continuant de bénéficier des avantages liés à l'invention, s'il retire la carte SIM de l'ancien terminal et l'insère dans le nouveau.

[0016] Selon un aspect de l'invention, la requête de session comprend l'identifiant du deuxième terminal.

[0017] Grâce à cet aspect, lorsque le premier terminal émet une requête http vers le serveur WebRTC, il peut inclure dans l'URL une adresse du deuxième terminal, par exemple le numéro de téléphone, concaténé à l'URL partiel ou complet du serveur WebRTC. Ainsi, la requête est unique et ne nécessite pas que l'abonné entre, dans un deuxième temps, le numéro du deuxième terminal pour un autre message à destination du serveur.

[0018] Selon un aspect de l'invention, le procédé d'établissement d'une session comprend une étape de sélection de l'identifiant du deuxième terminal à partir d'un carnet d'adresses.

[0019] Grâce à cet aspect, l'identifiant du deuxième terminal est sélectionné par l'utilisateur ou l'abonné dans un carnet d'adresse ordinaire, hébergé localement dans la mémoire de son terminal mobile ou de la carte SIM, ou dans une base de données distante interrogée par un procédé connu.

[0020] Selon un aspect de l'invention, l'étape de sélection de l'identifiant du deuxième terminal déclenche l'étape d'obtention de l'identifiant du serveur.

[0021] Grâce à cet aspect, c'est lorsque l'abonné sélectionne un contact dans son carnet d'adresse habituel, que la session est automatiquement établie à l'aide du serveur WebRTC dont l'adresse est comprise dans la carte SIM de son terminal. Ainsi, tout se passe pour l'abonné comme si l'appel porté par la session était un appel utilisant le réseau mobile classique de son opérateur, par exemple un appel VoLTE, et non un appel WebRTC.

[0022] L'abonné n'a donc pas à se préoccuper si l'appel doit passer par le réseau classique de son opérateur, un réseau VoLTE par exemple, ou par Internet via un serveur WebRTC, puisque le serveur WebRTC qui est choisi par son opérateur grâce à l'invention est celui qui lui permet d'obtenir la qualité de service qui s'approche le plus de celle d'un appel VoLTE.

[0023] Les différents aspects du procédé d'établissement d'une session qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les un avec les autres.

[0024] L'invention concerne aussi un dispositif d'établissement d'une session entre un premier terminal mobile et un deuxième terminal, conforme à la revendication 5.

[0025] Le dispositif d'établissement d'une session entre un premier terminal mobile et un deuxième terminal est compris dans un terminal mobile et est apte à mettre en oeuvre le procédé d'établissement d'une session qui vient d'être décrit, dans tous ses modes de réalisation.

[0026] Les modules d'émission, de génération, de réception et d'établissement peuvent faire partie d'un navigateur web, ou d'une application dédiée compatible WebRTC, installé(e) sur le terminal mobile. Le module d'obtention peut faire partie d'une application installée sur la carte SIM du terminal mobile.

[0027] L'invention concerne également un terminal mobile comprenant un dispositif d'établissement d'une session entre un premier terminal mobile et un deuxième terminal, conforme à celui qui vient d'être décrit.

[0028] L'invention concerne aussi un programme d'ordinateur comprenant des instructions pour la mise en œuvre des étapes du procédé d'établissement d'une session entre un premier terminal mobile et un deuxième terminal qui vient d'être décrit, lorsque ce programme est exécuté par un processeur.

[0029] L'invention concerne enfin un support d'enregistrement lisible par un équipement de gestion sur lequel est enregistré le programme qui vient d'être décrit, pouvant utiliser n'importe quel langage de programmation, et être sous la 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.

[0030] Avantageusement, le programme selon l'invention peut être soit installé sous une forme exécutable dans le terminal mobile selon l'invention, soit installé sous une forme téléchargeable sur un serveur d'applications distinct du terminal. Dans ce dernier cas le programme peut être téléchargé du serveur d'applications vers le terminal à l'initiative de l'utilisateur du terminal.

4. Présentation des figures



[0031] D'autre avantages et caractéristiques de l'invention apparaitront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier de l'invention, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
  • la figure 1 présente de façon schématique un exemple de mise en oeuvre des étapes d'un procédé d'établissement d'une session entre un premier terminal mobile et un deuxième terminal, selon l'invention,
  • la figure 2 présente un exemple de structure d'un dispositif d'établissement d'une session entre un premier terminal mobile et un deuxième terminal, selon un aspect de l'invention.

5. Description détaillée d'au moins un mode de réalisation de l'invention



[0032] Dans la suite de la description, on présente des exemples de plusieurs modes de réalisation de l'invention se basant sur la norme 3GPP LTE/EPC, mais l'invention s'applique également à d'autres normes 3GPP antérieures ou postérieures, telles que UMTS (Universal Mobile Telecommunications System, aussi connu sous l'appellation 3G) ou la 5G.

[0033] La figure 1 présente de façon schématique un exemple de mise en oeuvre des étapes d'un procédé d'établissement d'une session entre un premier terminal mobile T1 et un deuxième terminal T2, selon l'invention.

[0034] Dans cet exemple, l'utilisateur d'un terminal mobile T1 appelle l'utilisateur d'un autre terminal T2, pour une communication voix ou vidéo avec lui au travers des terminaux.

[0035] Le terminal T1 est un terminal mobile comprenant un module d'abonné, c'est à dire une carte SIM comprenant un identifiant d'un abonné à un opérateur de communications électroniques mobiles, ainsi qu'un identifiant de l'opérateur. Un tel module permet au terminal T1 d'établir une session "temps réel" pour transporter de la voix ou de la vidéo entre ce terminal et un autre terminal T2 en utilisant les ressources de cet opérateur, ou celles d'un autre opérateur ayant établi des accords d'itinérance avec lui. Cette session temps réel utilise un ou des codecs pour le passage de la voix/vidéo de la forme analogique à la forme numérique et vice-versa. Le terminal T1 est capable d'utiliser un ensemble de codecs qui n'est pas forcément le même que celui de T2. Un négociation doit donc avoir donc lieu entre les terminaux T1 et T2 pour déterminer le ou les codecs à utiliser.

[0036] Le terminal T1 est également apte à établir une session WebRTC, c'est à dire une session de communication par exemple basée sur un empilement des protocoles SRTP, UDP et IP,entre deux applications hébergées respectivement par les terminaux T1 et T2. Ces applications sont typiquement appelée des navigateurs Web. Les ressources de transport de l'opérateur de T1, utilisées pour une telle session, telles que celles de son réseau d'accès LTE et de son réseau coeur EPC sont déterminées par le choix du serveur WebRTC qui offre le service web permettant au terminal T1 d'établir une session de communication avec le terminal T2. L'opérateur a donc intérêt à garder un contrôle sur l'établissement de la session WebRTC.

[0037] Lors d'une étape E1, l'utilisateur du terminal T1 sélectionne un identifiant du terminal T2, c'est à dire généralement un numéro de téléphone, généralement à partir d'un carnet d'adresses qui peut être local ou distant. S'il est local il peut être hébergé dans la mémoire du terminal ou dans celle de la carte SIM. S'il est distant, le terminal T1 y accède par exemple depuis un navigateur Web ou une application dédiée, selon une procédure connue.

[0038] L'expression "sélectionner un identifiant" dans le sens de l'étape E1 comprend également le cas où l'utilisateur compose lui-même le numéro de téléphone du terminal T2 s'il est absent du carnet d'adresses.

[0039] Lors d'une étape E2, qui peut être automatiquement déclenchée par l'étape E1, le terminal T1 obtient l'identifiant d'un serveur WebRTC, celle du serveur S, à l'aide duquel la session avec le terminal T2 doit être étalie. De préférence, cet identifiant peut être obtenu à partir de la carte SIM du terminal T1.

[0040] Par exemple, "http://webrtc.orange.com" est une chaine de caractères représentant une adresse URL correspondant au serveur WebRTC d'un opérateur nommé Orange, le serveur S. Cette chaine peut être stockée dans la carte SIM des terminaux mobiles gérés par cet opérateur, afin d'être lue par le terminal lors de l'étape E2.

[0041] Cette chaine peut aussi être obtenue en ajoutant un préfixe prédéfini, par des normes ou par l'opérateur lors de la personalisation du mobile, au nom de domaine nominal (home network domain name) figurant dans la carte SIM.

[0042] Par exemple si le nom de domaine est "ims.orange.com" et le préfixe est "webrtc", l'URL sera "http://webrtc.ims.orange.com".

[0043] Cette chaine peut encore être obtenue en ajoutant un préfixe prédéfini au nom de domaine nominal formé à partir des codes de pays (MCC) et de réseau de l'opérateur (MNC), par exemple tel que spécifié dans la norme 3GPP TS 23.003.

[0044] Par exemple, pour l'opérateur Orange, l'URL peut être: "http://webrtc.ims.mnc015.mcc234.3gppnetwork.com".

[0045] Lors d'une étape E3, le terminal T1 construit une adresse comprenant à la fois l'identifiant du serveur S obtenu lors de l'étape E2 et l'identifiant du terminal T2 sélectionné lors de l'étape E1. Par exemple, si l'identifiant du terminal T2 est le numéro de téléphone de l'utilisateur associé au terminal T2, +33299124167, l'URL contruite peut être : "http://webrtc.ims.orange.com/tel/0033299124167".

[0046] Lors des étapes E4 et E5, le terminal T1 se connecte au serveur S.

[0047] Le terminal T1 émet lors de l'étape E4 une requête d'accès à un service WebRTC offert par le serveur S, dite requête de session au serveur S, sous forme d'une requête http utilisant l'URL construite lors de l'étape E3. On comprend que dans ce mode de réalisation de l'invention, la requête de session au serveur S comprend l'identifiant du terminal T2.

[0048] Le terminal T1 reçoit lors de l'étape E5 une réponse http de la part du serveur S, comprenant des instructions sous forme de code JavaScript, par exemple encapsulé dans une page HTML5. Ces instructions permettent au terminal T1 de générer un message à émettre selon un protocole décidé par le serveur WebRTC et de façon transparente pour le terminal, et en allant récupérer des informations dans le terminal comme par exemple les codecs disponibles, et/ou en allant récupérer certains flux audio/vidéo auprès du micro et/ou de la caméra pour pouvoir les émettre vers l'extérieur.

[0049] Lors d'une étape E6, le terminal T1 génère une demande de session au terminal T2 en fonction du contenu du code JavaScript reçu lors de l'étape E5. Par exemple, si le protocole utilisé par le fournisseur de service WebRTC est SIP, un message SIP sur Websocket "INVITE tel:0033299124167 SIP 2.0" peut être généré par le terminal T1, si le code JavaScript comprend l'identifiant de T2. Websocket est un protocole permettant d'obtenir un canal de communications simultanées bidirectionnelles audessus de la couche TCP (Transmission Control Protocol, ou protocole de contrôle de transmission). Ce message SIP comprend aussi l'offre SDP (Session Description Protocol, ou protocole de description de session) du terminal T1, c'est à dire un ensemble de codecs utilisables par le terminal T1, ainsi que ses ports et adresses pour les flux media (voix, vidéo, etc.).

[0050] Alternativement, si le fournisseur de service WebRTC n'utilise pas le protocole SIP, une requête http peut être générée lors de l'étape E6, comprenant l'identifiant du terminal T2 ainsi que les codecs, adresses et ports de T1.

[0051] Si le code JavaScript reçu lors de l'étape E5 ne comprend pas l'identifiant du terminal T2, il faut que cet identifiant soit récupéré d'une façon ou d'une autre par le terminal pour être inséré dans la requête http générée lors de l'étape E6. Dans ce cas la page HTML5 aura typiquement, en plus du code JavaScript, un formulaire pour saisir l'identifiant, par exemple un numéro de téléphone.

[0052] Alternativement, d'autres protocoles que SIP ou http peuvent être utilisés. Dans ces cas ce sont aussi les instructions du code JavaScript qui indiqueront au navigateur du terminal T1 comment générer la demande de session, et en combien de messages.

[0053] Lors d'une étape E7 la demande de session générée lors de l'étape E6 est émise par le terminal T1 à destination du serveur S.

[0054] Lors d'une étape F1, le serveur S reçoit cette demande.

[0055] Lors d'une étape F2, le serveur S transmet vers le terminal T2 une demande identique ou équivalente, comprenant les mêmes information que la demande émise par le terminal T1 lors de l'étape E7. Il peut exister entre le serveur S et le terminal T2 un ou plusieurs serveurs intermédiaires. Le ou les protocoles utilisés entre le serveur S et le terminal T2 peuvent également différer de celui ou ceux utilisés entre le serveur S et le terminal T1, s'ils permettent une négotiation de l'offre SDP entre les terminaux T1 et T2.

[0056] Lors d'une étape F3, le terminal T2 émet en réponse vers le serveur S une demande de session à T1, comprenant une réponse SDP, c'est à dire un sous ensemble des codecs proposés par le terminal T1, ou de leur équivalent. Ce sous-ensemble comprend les codecs proposés par le terminal T1 que le terminal T2 est capable d'utiliser.

[0057] Lors d'une étape F4, le serveur S transmet vers le terminal T1 une demande identique ou équivalente, comprenant les mêmes information que la demande émise par le terminal T2 lors de l'étape F3.

[0058] Lors d'une étape E8, le terminal T1 reçoit la demande de session du terminal T2. Cette demande peut prendre la forme d'un message SIP "180 Ringing" ou "200 Ok", comprenant la réponse SDP, c'est à dire le sous-ensemble des codecs proposés par le terminal T1 que le terminal T2 est capable d'utiliser, ainsi qu'une adresse et un port sur lequel le terminal T2 attend les flux média émis par la terminal T1.

[0059] Enfin, lors d'une étape E9, la session de communication entre les terminaux T1 et T2 est établie en utilisant un ou plusieurs des codecs compatibles avec le terminal T2.

[0060] Dans un mode de réalisation alternatif, l'étape E3 est remplacée par une étape G3 (non illustrée) de construction d'une adresse comprenant l'identifiant du serveur S et un ou des préfixes éventuels, mais pas l'identifiant du terminal T2. Ceci permet de couvrir le cas où l'utilisateur compose lui-même un numéro qui n'est pas dans son carnet d'adresses.

[0061] L'étape E4 est remplacée par une étape G4 (non illustrée) d'émission d'une requête de session au serveur S, mais où la requête de session au serveur S ne comprend pas l'identifiant du terminal T2.

[0062] L'étape E1 de sélection de l'identifiant du terminal T2 peut-être remplacée par une étape G1 (non illustrée) d'obtention de l'identifiant du terminal T2, par exemple par composition du numéro par l'utilisateur. L'étape E1, ou l'étape G1, peut dans ce mode survenir après l'étape E2 d'obtention de l'identifiant du serveur S.

[0063] L'étape E6 attend alors la complétion de l'étape E1, ou de l'étape G1, et c'est uniquement lors de l'étape E7 d'émission de la demande de session que l'identifiant du terminal T2 est émis.

[0064] En relation avec la figure 2, on présente maintenant un exemple de structure d'un dispositif d'établissement d'une session entre un premier terminal mobile et un deuxième terminal, selon un aspect de l'invention.

[0065] Le dispositif 100 met en œuvre le procédé d'établissement d'une session entre un premier terminal mobile et un deuxième terminal, dont différents modes de réalisation viennent d'être décrits.

[0066] Un tel dispositif 100 peut être mis en oeuvre dans un terminal mobile apte à établir une connexion IP avec un noeud d'un réseau d'accès, portée par une connexion radio-électrique.

[0067] Par exemple, le dispositif 100 comprend une unité de traitement 130, équipée par exemple d'un microprocesseur µP, et pilotée par un programme d'ordinateur 110, stocké dans une mémoire 120 et mettant en œuvre le procédé d'établissement d'une session entre un premier terminal mobile et un deuxième terminal selon l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 110 sont par exemple chargées dans une mémoire RAM, avant d'être exécutées par le processeur de l'unité de traitement 130.

[0068] Un tel dispositif 100 comprend :
  • un module de sélection 141, apte à sélectionner un identifiant d'un terminal distant dans un carnet d'adresses C,
  • un module d'obtention 142, apte à obtenir un identifiant d'un serveur WebRTC à partir d'un module d'abonné SIM, ou carte SIM,
  • un module de construction 143, apte à construire un identifiant tel que par exemple une adresse URL, en combinant l'identifiant du terminal distant sélectionné, l'identifiant du serveur WebRTC et éventuellement un autre identifiant tel qu'un préfixe prédéterminé,
  • un module d'émission 151, apte à émettre une requête de session à destination d'un serveur WebRTC, sous forme d'une requête http comprenant l'adresse URL construite,
  • un module de réception 152, apte à recevoir une instruction de la part du serveur WebRTC, par exemple une réponse http,
  • un module de génération 153, apte à générer une demande de session au terminal distant à partir de l'instruction reçue du serveur WebRTC, par exemple sous la forme d'un message SIP ou d'une requête http comprenant une offre SDP,
  • un module d'émission 154, apte à émettre la demande de session générée, à destination du serveur WebRTC,
  • un module de réception 155, apte à recevoir en provenance du serveur WebRTC une demande de session de la part du terminal distant sélectionné, par exemple sous la forme d'un message SIP ou d'une réponse http comprenant une réponse SDP,
  • un module d'établissement 156, apte à établir une session WebRTC avec le terminal distant sélectionné, par exemple à l'aide d'informations comprises dans la réponse SDP reçue.


[0069] Les modules 141, 142 et 143 peuvent être compris dans une première application APP1 tournant sur la carte SIM du terminal mobile mettant en oeuvre le dispositif 100. Le carnet d'adresses C peut être stocké dans la carte SIM, dans une mémoire du terminal mobile en dehors de la carte SIM ou dans un équipement séparé endehors du terminal mobile, accessible à l'aide d'une application dédiée. L'application APP1 peut également tourner sur le terminal mobile en dehors de la carte SIM. Cette application APP1 peut être préinstallée par le fabricant du mobile ou l'opérateur, ou installée par l'abonné par téléchargement depuis un site Internet tel que par exemple un AppStore.

[0070] Les modules 151 à 156 peuvent être compris dans une deuxième application APP2 jouant le rôle de client WebRTC. Cette application APP2 peut être un navigateur compatible WebRTC tournant sur le terminal mobile, tel que Chrome, Firefox, Opera, Internet Explorer, Safari, etc. ou une application dédiée, compatible WebRTC, pouvant s'exécuter en dehors du navigateur et installée sur le terminal mobile. Cette application APP2 peut être préinstallée par le fabricant du mobile ou l'opérateur, ou installée par l'abonné par téléchargement depuis un site Internet tel que par exemple un AppStore.

[0071] Les modules décrits en relation avec la figure 2 peuvent être des modules matériels ou logiciels.

[0072] Grâce au dispositif d'établissement d'une session entre un premier terminal mobile et un deuxième terminal selon l'invention, plusieurs ergonomies sont possibles pour établir un appel en mode WebRTC, en particulier,
  • soit le lancement de l'application APP1 depuis le carnet d'adresse C, en y sélectionnant un identifiant, ou contact, et en appuyant sur une icône ou une touche du terminal mobile pour lancer l'application APP2 et ainsi établir la session, c'est à dire l'appel,
  • soit le lancement de l'application APP1 depuis l'écran d'accueil du terminal mobile, en appuyant sur une touche ou une icône pour ouvrir le carnet d'adresse C, y sélectionner un contact, lancer l'applciation APP2 et ainsi établir la session, c'est à dire l'appel.


[0073] L'association de l'application APP1 à une icône ou à une touche du terminal mobile est effectuée lors de l'initialisation de l'application APP1, par exemple lors de la mise en route du terminal avec la carte SIM insérée, selon un procédé qui dépend du terminal et du système d'exploitation utilisé.

[0074] Les exemples de réalisation de l'invention qui viennent d'être présentés ne sont que quelques uns des modes de réalisation envisageables. Ils montrent que l'invention permet à un abonné à un service de télécommunication mobile de bénéficier du service WebRTC le mieux adapté au réseau de son opérateur, de façon transparente pour lui, simplement en sélectionnant ou en saississant le numéro de téléphone de son correspondant sur son terminal mobile.


Revendications

1. Procédé d'établissement d'une session entre un premier terminal mobile et un deuxième terminal, comprenant les étapes suivantes mises en œuvre par le premier terminal :

• une étape d'obtention (E2) d'un identifiant d'un serveur WebRTC au moins à partir d'un module d'abonné à un opérateur de communications électroniques mobiles, compris dans le premier terminal, le module d'abonné comprenant une adresse partielle ou complète du serveur WebRTC, un identifiant d'un abonné et un identifiant de l'opérateur,

• une étape (E3) de construction d'une adresse comprenant l'identifiant du serveur WebRTC et un identifiant du deuxième terminal,

• une étape d'émission (E4) d'une requête d'accès à un service WebRTC, à destination du serveur WebRTC, la requête d'accès utilisant l'adresse construite,

• une étape de réception (E5) d'au moins une instruction de la part du serveur WebRTC,

• une étape de génération (E6), en fonction de l'au moins une instruction reçue, d'une demande de session comprenant un premier ensemble, relatif au premier terminal, d'au moins un paramètre caractéristique de la session demandée,

• une étape d'émission (E7), à destination du serveur WebRTC, de la demande de session générée,

• une étape de réception (E8), en provenance du serveur WebRTC, d'un message comprenant un deuxième ensemble d'au moins un paramètre caractéristique de la session demandée, le deuxième ensemble étant relatif au deuxième terminal et ayant une intersection non nulle avec le premier ensemble,

• une étape d'établissement (E9) de la session entre le premier terminal mobile et le deuxième terminal, au moins à l'aide du deuxième ensemble de paramètres.


 
2. Procédé d'établissement d'une session selon la revendication 1, caractérisé en ce que le module d'abonné est une carte SIM.
 
3. Procédé d'établissement d'une session selon l'une des revendications précédentes, caractérisé en ce qu'il comprend une étape de sélection (E1) de l'identifiant du deuxième terminal à partir d'un carnet d'adresses.
 
4. Procédé d'établissement d'une session selon la revendication 3, caractérisé en ce que l'étape de sélection (E1) de l'identifiant du deuxième terminal déclenche l'étape d'obtention (E2) de l'identifiant du serveur WebRTC.
 
5. Dispositif d'établissement d'une session entre un premier terminal mobile et un deuxième terminal, comprenant les modules suivants :

• un module d'obtention (142) d'un identifiant d'un serveur WebRTC, au moins à partir d'un module d'abonné à un opérateur de communications électroniques mobiles, compris dans le premier terminal, le module d'abonné comprenant une adresse partielle ou complète du serveur WebRTC, un identifiant d'un abonné et un identifiant de l'opérateur,

• un module de construction (143) d'une adresse comprenant l'identifiant du serveur WebRTC et un identifiant du deuxième terminal

• un module d'émission (151) d'une requête d'accès à un service WebRTC à destination d'un serveur WebRTC, la requête d'accès utilisant l'adresse construite,

• un module de réception (152) d'au moins une instruction de la part du serveur WebRTC,

• un module de génération (153) en fonction de l'au moins une instruction reçue, d'une demande de session comprenant un premier ensemble, relatif au premier terminal, d'au moins un paramètre caractéristique de la session demandée,

• un module d'émission (154), à destination du serveur, de la demande générée,

• un module de réception (155), en provenance du serveur WebRTC, d'un message comprenant un deuxième ensemble d'au moins un paramètre caractéristique de la session demandée, le deuxième ensemble étant relatif au deuxième terminal et ayant une intersection non nulle avec le premier ensemble,

• un module d'établissement (156) de la session entre le premier terminal mobile et le deuxième terminal, au moins à l'aide du deuxième ensemble de • paramètres.


 
6. Terminal mobile comprenant un dispositif d'établissement d'une session entre un premier terminal mobile et un deuxième terminal, conforme à la revendication 5.
 
7. Programme d'ordinateur, caractérisé en ce qu'il comprend des instructions pour la mise en œuvre des étapes du procédé d'établissement d'une session entre un premier terminal mobile et un deuxième terminal selon la revendication 1, lorsque ce programme est exécuté par un processeur.
 
8. Support d'enregistrement lisible par un terminal mobile sur lequel est enregistré le programme selon la revendication 7.
 


Ansprüche

1. Verfahren zum Einrichten einer Sitzung zwischen einem ersten mobilen Endgerät und einem zweiten Endgerät, umfassend die folgenden vom ersten Endgerät ausgeführten Schritte:

• einen Schritt des Erhaltens (E2) einer Kennung eines WebRTC-Servers mindestens anhand eines Teilnehmermoduls eines Mobilfunknetzbetreibers, das in dem ersten Endgerät enthalten ist, wobei das Teilnehmermodul eine partielle oder vollständige Adresse des WebRTC-Servers, eine Kennung eines Teilnehmers und eine Kennung des Netzbetreibers umfasst,

• einen Schritt (E3) des Aufbauens einer Adresse, welche die Kennung des WebRTC-Servers und eine Kennung des zweiten Endgeräts umfasst,

• einen Schritt des Sendens (E4) einer Anforderung des Zugriffs auf einen WebRTC-Dienst an den WebRTC-Server, wobei die Zugriffsanforderung die aufgebaute Adresse verwendet,

• einen Schritt des Empfangens (E5) mindestens einer Anweisung seitens des WebRTC-Servers,

• einen Schritt des Generierens (E6), in Abhängigkeit von der mindestens einen empfangenen Anweisung, einer Sitzungsanfrage, die eine erste Menge, bezüglich des ersten Endgeräts, mit mindestens einem für die angefragte Sitzung kennzeichnenden Parameter umfasst,

• einen Schritt des Sendens (E7) der generierten Sitzungsanfrage an den WebRTC-Server,

• einen Schritt des Empfangens (E8) einer Nachricht vom WebRTC-Server, die eine zweite Menge mit mindestens einem für die angefragte Sitzung kennzeichnenden Parameter umfasst, wobei sich die zweite Menge auf das zweite Endgerät bezieht und eine Schnittmenge ungleich null mit der ersten Menge hat,

• einen Schritt des Einrichtens (E9) der Sitzung zwischen dem ersten mobilen Endgerät und dem zweiten Endgerät zumindest mithilfe der zweiten Parametermenge.


 
2. Verfahren zum Einrichten einer Sitzung nach Anspruch 1, dadurch gekennzeichnet, dass das Teilnehmermodul eine SIM-Karte ist.
 
3. Verfahren zum Einrichten einer Sitzung nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass es einen Schritt des Auswählens (E1) der Kennung des zweiten Endgeräts anhand eines Adressbuchs umfasst.
 
4. Verfahren zum Einrichten einer Sitzung nach Anspruch 3, dadurch gekennzeichnet, dass der Schritt des Auswählens (E1) der Kennung des zweiten Endgeräts den Schritt des Erhaltens (E2) der Kennung des WebRTC-Servers auslöst.
 
5. Vorrichtung zum Einrichten einer Sitzung zwischen einem ersten mobilen Endgerät und einem zweiten Endgerät, umfassend die folgenden Module:

• ein Modul zum Erhalten (142) einer Kennung eines WebRTC-Servers mindestens anhand eines Teilnehmermoduls eines Mobilfunknetzbetreibers, das in dem ersten Endgerät enthalten ist, wobei das Teilnehmermodul eine partielle oder vollständige Adresse des WebRTC-Servers, eine Kennung eines Teilnehmers und eine Kennung des Netzbetreibers umfasst,

• ein Modul zum Aufbauen (143) einer Adresse, welche die Kennung des WebRTC-Servers und eine Kennung des zweiten Endgeräts umfasst,

• ein Modul zum Senden (151) einer Anforderung des Zugriffs auf einen WebRTC-Dienst an einen WebRTC-Server, wobei die Zugriffsanforderung die aufgebaute Adresse verwendet,

• ein Modul zum Empfangen (152) mindestens einer Anweisung seitens des WebRTC-Servers,

• ein Modul zum Generieren (153), in Abhängigkeit von der mindestens einen empfangenen Anweisung, einer Sitzungsanfrage, die eine erste Menge, bezüglich des ersten Endgeräts, mit mindestens einem für die angefragte Sitzung kennzeichnenden Parameter umfasst,

• ein Modul zum Senden (154) der generierten Sitzungsanfrage an den Server,

• ein Modul zum Empfangen (155) einer Nachricht vom WebRTC-Server, die eine zweite Menge mit mindestens einem für die angefragte Sitzung kennzeichnenden Parameter umfasst, wobei sich die zweite Menge auf das zweite Endgerät bezieht und eine Schnittmenge ungleich null mit der ersten Menge hat,

• ein Modul zum Einrichten (156) der Sitzung zwischen dem ersten mobilen Endgerät und dem zweiten Endgerät zumindest mithilfe der zweiten Parametermenge.


 
6. Mobiles Gerät, das eine Vorrichtung zum Einrichten einer Sitzung zwischen einem ersten mobilen Endgerät und einem zweiten Endgerät nach Anspruch 5 umfasst.
 
7. Computerprogramm, dadurch gekennzeichnet, dass es Befehle umfasst, die bei der Ausführung dieses Programms durch einen Prozessor die Schritte des Verfahrens zum Einrichten einer Sitzung zwischen einem ersten mobilen Endgerät und einem zweiten Endgerät nach Anspruch 1 ausführen.
 
8. Speichermedium, das von einem mobilen Endgerät gelesen werden kann und auf dem das Programm nach Anspruch 7 gespeichert ist.
 


Claims

1. Method for establishing a session between a first mobile terminal and a second terminal, comprising the following steps implemented by the first terminal:

• a step for obtaining (E2) an identifier of a WebRTC server, at least from a subscriber module for a mobile electronic communications operator, included in the first terminal, the subscriber module containing a partial or complete address of the WebRTC server, an identifier of a subscriber and an identifier of the operator,

• a step (E3) of constructing an address comprising the identifier of the WebRTC server and an identifier of the second terminal,

• a step (E4) of sending a request to access a WebRTC service to the WebRTC server, the access request using the constructed address,

• a step for receiving (E5) at least one instruction from the WebRTC server,

• a step for generating (E6), according to the at least one received instruction, a session request containing a first set, relating to the first terminal, of at least one characteristic parameter of the requested session,

• a step for transmitting (E7) the generated session request to the WebRTC server,

• a step for receiving (E8), from the WebRTC server, a message containing a second set of at least one characteristic parameter of the requested session, the second set relating to the second terminal and having a non-zero intersection with the first set,

• a step for establishing (E9) the session between the first mobile terminal and the second terminal, at least using the second set of parameters.


 
2. Method for establishing a session according to Claim 1, characterized in that the subscriber module is a SIM card.
 
3. Method for establishing a session according to either of the preceding claims, characterized in that it comprises a step for selecting (E1) the identifier of the second terminal from an address book.
 
4. Method for establishing a session according to Claim 3, characterized in that the step for selecting (E1) the identifier of the second terminal triggers the step for obtaining (E2) the identifier of the WebRTC server.
 
5. Device for establishing a session between a first mobile terminal and a second terminal, comprising the following modules:

• a module for obtaining (142) an identifier of a WebRTC server, at least from a subscriber module for a mobile electronic communications operator, included in the first terminal, the subscriber module containing a partial or complete address of the WebRTC server, an identifier of a subscriber and an identifier of the operator,

• a module (143) for constructing an address comprising the identifier of the WebRTC server and an identifier of the second terminal,

• a module (151) for sending a request to access a WebRTC service to a WebRTC server, the access request using the constructed address,

• a module for receiving (152) at least one instruction from the WebRTC server,

• a module for generating (153), according to the at least one received instruction, a session request containing a first set, relating to the first terminal, of at least one characteristic parameter of the requested session,

• a module for transmitting (154) the generated request to the server,

• a module for receiving (155), from the WebRTC server, a message containing a second set of at least one characteristic parameter of the requested session, the second set relating to the second terminal and having a non-zero intersection with the first set,

• a module for establishing (156) the session between the first mobile terminal and the second terminal, at least using the second set of parameters.


 
6. Mobile terminal comprising a device for establishing a session between a first mobile terminal and a second terminal, in accordance with Claim 5.
 
7. Computer program, characterized in that it comprises instructions for implementing the steps of the method for establishing a session between a first mobile terminal and a second terminal according to Claim 1, when this program is executed by a processor.
 
8. Recording medium that can be read by a mobile terminal, on which is recorded the program according to Claim 7.
 




Dessins











Références citées

RÉFÉRENCES CITÉES DANS LA DESCRIPTION



Cette liste de références citées par le demandeur vise uniquement à aider le lecteur et ne fait pas partie du document de brevet européen. Même si le plus grand soin a été accordé à sa conception, des erreurs ou des omissions ne peuvent être exclues et l'OEB décline toute responsabilité à cet égard.

Littérature non-brevet citée dans la description