FR3030958A1 - Procede et dispositif de communication entre un terminal sip et un serveur web - Google Patents

Procede et dispositif de communication entre un terminal sip et un serveur web Download PDF

Info

Publication number
FR3030958A1
FR3030958A1 FR1462966A FR1462966A FR3030958A1 FR 3030958 A1 FR3030958 A1 FR 3030958A1 FR 1462966 A FR1462966 A FR 1462966A FR 1462966 A FR1462966 A FR 1462966A FR 3030958 A1 FR3030958 A1 FR 3030958A1
Authority
FR
France
Prior art keywords
sip
communication
request
web server
response
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR1462966A
Other languages
English (en)
Inventor
Sage Benoit Le
Snoeck Xavier De
Miguel Labranche
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1462966A priority Critical patent/FR3030958A1/fr
Publication of FR3030958A1 publication Critical patent/FR3030958A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention vise un procédé de communication entre un terminal SIP (5) et un serveur Web (3), le procédé étant mis en œuvre par un dispositif de communication (8) placé en coupure de flux entre le terminal SIP (5) et le serveur Web (3), le procédé comprenant : - une étape (E10) de réception d'une requête SIP (R1) d'enregistrement émise par le terminal SIP (5) et contenant un identifiant (SIP URI-U3) de l'utilisateur du terminal SIP (5) ; - une étape (E20) de génération, à partir de la requête SIP (R1) d'enregistrement, d'une requête (R2) d'établissement d'une session de communication entre le dispositif (8) et le serveur Web (3), la requête (R2) d'établissement comprenant un identifiant d'un protocole de communication utilisé pour tous les messages échangés via la session de communication ; - une étape (E30) de transmission au serveur Web (3) de la requête (R2) d'établissement ; et - sur réception en provenance du serveur Web (3) d'un message de confirmation (R6) de l'établissement de la session de communication, une étape (E110) d'association entre le terminal SIP (5) et la session de communication et une étape (E120) d'émission d'une réponse SIP (R7) de succès à destination du terminal SIP (5).

Description

Arrière-plan de l'invention L'invention se rapporte au domaine général des télécommunications. Elle concerne plus précisément la gestion d'une communication à partir d'un terminal SIP lorsque les flux de données audio et/ou vidéo associés sont transportés par l'intermédiaire d'un coeur de réseau Web. Un terminal SIP permet, en utilisant le protocole de signalisation SIP (« Session Initiation Protocol ») normalisé par le consortium IETF (« Internet Engineering Task Force »), d'établir et de gérer une communication au travers d'un coeur de réseau (en anglais « backbone ») respectant la norme IMS (« IP Multimedia Subsystem »).
Avec la finalisation par les consortiums IETF et W3C (« World Wide Web ») de la norme WebRTC (« WebRTC 1.0 : Real-time Communication Between Browser », W3C Editor's Draft) sont apparus des systèmes de communication qui n'utilisent plus la norme IMS décrite dans le document 3GPP TS 23.228 (« IP Multimedia Subsystem ») mais reposent sur une architecture réseau de type Internet.
La Figure 1 présente un tel système de communication 20. Ce système de communication 20 est constitué d'au moins un serveur Web 3 et d'une pluralité de terminaux informatiques 1, 2 sur lesquels sont installés des navigateurs. Les terminaux informatiques 1, 2 peuvent communiquer avec le serveur Web 3 par l'intermédiaire d'un réseau de communication 4 dont l'architecture du coeur de réseau est de type Web.
Conformément aux normes WebRTC, les navigateurs installés sur les terminaux informatiques 1 et 2 établissent entre eux une communication 11 en échangeant, par l'intermédiaire du serveur Web 3, des messages de signalisation SigWebRTC compatibles avec la norme WebRTC. Une fois la communication 11 établie et conformément aux normes WebRTC, les flux de données audio et/ou vidéo transitent entre les navigateurs des terminaux 1 et 2 sans passer par le serveur Web 3. Il est naturel de déployer des terminaux personnels et/ou mobiles (téléphones intelligents ou « smartphones », tablettes, etc.) comportant un navigateur pour établir des communications sur ce type d'architecture réseau. Néanmoins, l'ergonomie de ces navigateurs ne permet pas un confort d'utilisation de la même qualité que celui procuré par les terminaux SIP. Il existe donc un besoin d'une solution simple et efficace permettant d'utiliser un terminal SIP pour établir une communication sur une architecture réseau dont le coeur de réseau est un coeur de réseau Web.35 Objet et résumé de l'invention La présente invention vise en conséquence un procédé de communication entre un terminal SIP et un serveur Web, le procédé étant destiné à être mis en oeuvre par un dispositif de communication placé en coupure de flux entre le terminal SIP et le serveur Web, le procédé comprenant : une étape de réception d'une requête d'enregistrement SIP émise par le terminal SIP, la requête d'enregistrement contenant un identifiant du terminal SIP; une étape de génération, à partir de la requête d'enregistrement SIP, d'une requête d'établissement d'une session de communication entre le dispositif et le serveur Web, la requête d'établissement comprenant un identifiant d'un protocole de communication utilisé pour tous les messages échangés entre le dispositif et le serveur dans le cadre de la session de communication ; une étape de transmission au serveur Web de la requête d'établissement ; et sur réception en provenance du serveur Web d'un message de confirmation de l'établissement de la session de communication, une étape d'association entre le terminal SIP et la session de communication et une étape d'émission d'une réponse SIP de succès à destination du terminal SIP. Corrélativement, l'invention vise selon un autre aspect un dispositif de communication destiné à être placé en coupure de flux entre un terminal SIP et un serveur Web et comprenant : un module de réception d'une requête SIP d'enregistrement émise par le terminal SIP, la requête d'enregistrement contenant un identifiant de l'utilisateur du terminal SIP; un module de génération, à partir de la requête SIP d'enregistrement, d'une requête d'établissement d'une session de communication entre le dispositif et le serveur Web, la requête d'établissement comprenant un identifiant d'un protocole de communication utilisé pour tous les messages échangés entre le dispositif et le serveur dans le cadre de la session de communication ; un module de communication avec le serveur Web apte à transmettre la requête d'établissement et à recevoir un message de confirmation de l'établissement de la session de communication ; et un module d'association apte à associer le terminal SIP et la session de communication et un module d'émission à destination du terminal SIP d'une réponse SIP de succès, les modules d'association et d'émission étant activés sur réception en provenance du serveur Web du message de confirmation de l'établissement de la session de communication.
Le dispositif de communication selon l'invention permet à un utilisateur d'un terminal SIP d'établir, au travers d'un coeur de réseau Web, une communication avec une autre personne, cette dernière pouvant notamment utiliser un navigateur WebRTC ou un autre téléphone SIP relié également au coeur de réseau Web par l'intermédiaire d'un dispositif de communication selon l'invention. Au sens de l'invention, on entend par terminal SIP tout terminal de communication, logiciel ou matériel, capable d'utiliser le protocole de signalisation SIP, défini par la norme RFC 3261, pour établir une communication, par exemple une communication téléphonique, par vidéophonie, de type messagerie instantanée ou de type RCS (en anglais « Rich Communication Suite ») avec un autre terminal SIP. D'autre part, au sens de l'invention, un navigateur WebRTC est un navigateur capable lorsqu'une communication est établie, de recevoir, de traiter et d'envoyer des flux audio et/ou vidéo conformément aux normes WebRTC. Le dispositif de communication selon l'invention permet ainsi à un terminal SIP tout d'abord de s'enregistrer auprès d'un serveur Web, puis d'établir une communication avec un navigateur WebRTC. Ce dispositif de communication permet donc à un terminal SIP et à un serveur Web de communiquer entre eux en dépit de l'utilisation de protocoles de signalisation distincts. Cette communication est rendue possible non seulement grâce à l'établissement d'une session de communication entre le dispositif de communication et le serveur Web, mais aussi grâce à une traduction de protocoles de signalisation mise en oeuvre par le dispositif de communication. Le dispositif de communication se comporte comme un serveur « registrar » au sens de la norme SIP en transformant les requêtes SIP d'enregistrement reçues du terminal SIP en commandes HTTP à destination du serveur Web. D'autre part, le dispositif de communication peut gérer simultanément plusieurs terminaux SIP en associant à chacun d'entre eux une session différente de communication avec le serveur Web. De façon avantageuse, l'invention permet à l'utilisateur de continuer à utiliser son terminal SIP pour établir une communication avec un autre terminal, par exemple un terminal WebRTC, sur une architecture réseau dont le coeur de réseau est un coeur de réseau Web. D'autre part, en conservant l'usage de ses terminaux SIP, l'utilisateur continue de bénéficier de la disponibilité de ces terminaux dédiés aux services de communication qui sont de par leur conception toujours disponibles au contraire des navigateurs WebRTC qui ne sont utilisables que lorsque le terminal informatique qui les accueille est allumé. En outre, les terminaux SIP bénéficient d'une meilleure ergonomie et ne nécessitent pas l'utilisation de périphériques additionnels, tels que les casques ou les microphones. Grâce à ce meilleur confort d'utilisation, l'utilisateur profite d'une meilleure expérience utilisateur. Dans un mode de réalisation particulier de l'invention, le protocole de communication entre le dispositif de communication et le serveur Web est un protocole WebSocket.
Le protocole WebSocket est défini par le standard RFC 6455 (ou par une évolution de ce standard). De façon avantageuse, le protocole WebSocket est supporté nativement par une majorité de serveurs Web. En outre, ce protocole permet d'établir une communication bidirectionnelle entre le serveur Web et le dispositif de communication dès lors que la WebSocket est initialisée. Dans un autre mode de réalisation particulier de l'invention, le protocole de communication entre le dispositif de communication et le serveur Web est un protocole XMPP (« Extensible Messaging and Presence Protocol ») défini par le standard RFC 3920 ou ses évolutions.
Dans un autre mode de réalisation particulier de l'invention, le protocole de communication entre le dispositif de communication et le serveur Web est un protocole HTTP REST. Dans un mode de réalisation particulier de l'invention, le procédé de communication comprend en outre après l'établissement de la session de communication : - une étape de réception d'au moins une requête SIP de gestion d'appel émise par le terminal SIP; une étape de génération, à partir de ladite au moins une requête de gestion d'appel SIP, d'un message de gestion d'appel ; une étape de transmission au serveur Web du message de gestion d'appel via la session de communication. Conformément à l'invention, lorsque le terminal SIP est enregistré, une communication peut être établie entre le terminal SIP et un terminal WebRTC via le dispositif de communication.
L'invention permet ainsi au terminal SIP de transmettre une requête de gestion d'appel à destination d'un navigateur WebRTC en utilisant la session de communication établie précédemment entre le serveur Web et le dispositif de communication. Une requête de gestion d'appel est une requête permettant d'établir ou de gérer une communication à partir du terminal SIP. De telles requêtes sont notamment des requêtes INVITE, MESSAGE, OPTION ou encore REFER. Cette transmission est rendue possible non seulement grâce à une traduction de protocoles de signalisation mise en oeuvre par le dispositif de communication, mais aussi grâce à l'utilisation de la session de communication préalablement établie entre le dispositif de communication et le serveur Web lors de la procédure d'enregistrement du terminal SIP. Dans un mode de réalisation particulier de l'invention, le procédé de communication comprend en outre dans le cadre d'une procédure d'authentification : une étape de réception d'un challenge en provenance du serveur Web en réponse à la requête d'établissement ou au message de gestion d'appel ; une étape de génération d'une réponse SIP d'authentification contenant le challenge ; une étape d'envoi au terminal SIP de la réponse SIP d'authentification ; une étape de réception d'une requête SIP, cette requête SIP contenant une réponse au challenge ; une étape d'envoi au serveur Web de la réponse au challenge. Dans un mode particulier de réalisation de l'invention, la procédure d'authentification est de type « authentification digest ». Le dispositif de communication selon l'invention permet avantageusement d'authentifier l'utilisateur du terminal SIP et ainsi de s'assurer que les requêtes transmises au serveur Web par l'intermédiaire du dispositif de communication sont bien conformes aux privilèges dont bénéficie l'utilisateur du terminal SIP. Cette authentification repose sur un mécanisme de sécurisation de type « challenge/réponse » mis en oeuvre après réception par le serveur Web d'une requête d'établissement d'une session de communication ou d'un message de gestion d'appel.
Le serveur Web envoie un challenge au terminal SIP par l'intermédiaire du dispositif de communication. Lorsque le challenge est émis en réponse à une requête d'établissement, le challenge est transporté par une requête HTTP. A contrario, lorsque le challenge est émis en réponse à un message de gestion d'appel, le challenge transite par la session de communication établie entre le dispositif de communication et le serveur Web.
Sur réception du challenge, le terminal SIP calcule une réponse. Le calcul de cette réponse s'effectue à partir du challenge lui-même et d'un secret partagé entre le terminal SIP et le serveur Web, le secret étant par exemple le mot de passe de l'utilisateur utilisant le terminal SIP.
Le terminal SIP envoie ensuite cette réponse au serveur Web par l'intermédiaire du dispositif de communication. Le serveur Web authentifie l'utilisateur du terminal SIP sur la base de la réponse reçue à son challenge. Dans un mode de réalisation particulier de l'invention, le procédé de 10 communication comprend en outre après l'établissement de la session de communication : une étape de réception d'au moins une réponse à un message de gestion d'appel émis par le serveur Web via la session de communication ; une étape de génération, à partir de ladite au moins une réponse au message de 15 gestion d'appel, d'une réponse SIP; une étape de transmission de la réponse SIP au terminal SIP associé à la session de communication. Le dispositif de communication selon l'invention est ainsi également chargé de relayer au terminal SIP les messages de gestion d'appel émis par le serveur Web et 20 transitant par la session de communication. Dans un mode de réalisation particulier de l'invention, le message de gestion d'appel et ladite au moins une réponse au message de gestion d'appel sont conformes au format JSON (« JavaScript Object Notation »), au format XML (« Extensible Markup Language ») ou au format SIP. 25 Dans un mode de réalisation particulier de l'invention, le procédé de communication comprend en outre, après l'établissement de la session de communication : une étape de récupération auprès du serveur Web des permissions associées au terminal SIP; 30 sur réception d'au moins une deuxième requête SIP de gestion d'appel émise par le terminal SIP, ladite au moins une deuxième requête SIP de gestion d'appel ne contenant pas d'information d'authentification du terminal SIP : o une étape de calcul d'un deuxième challenge à partir des permissions associées au terminal SIP; 35 0 une étape de génération d'une deuxième réponse SIP comprenant le deuxième challenge ; et o une étape de transmission au terminal SIP de la deuxième réponse SIP. Autrement dit, après une première identification de l'utilisateur du terminal SIP auprès du serveur Web, le dispositif de communication utilise la session de communication avec le serveur Web pour dupliquer localement, par exemple dans une mémoire cache, les privilèges de l'utilisateur du terminal SIP. De cette façon, lorsque le dispositif de communication reçoit une requête SIP de gestion d'appel ne contenant pas d'information d'authentification de l'utilisateur du terminal SIP l'ayant émise, le dispositif de communication génère un challenge à partir des privilèges dupliqués localement de cet utilisateur avant de transmettre ce challenge au terminal SIP. Ainsi, le volume des communications entre le dispositif de communication et le serveur Web est minimisé. Dans un mode particulier de réalisation, les différentes étapes du procédé de communication sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un dispositif de communication ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé de communication tel que décrit ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de codes source, codes objet, ou de codes intermédiaires 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 un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. 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 magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Selon un autre aspect, l'invention vise aussi une passerelle de communication comprenant un dispositif de communication selon l'invention et destinée à être placée en coupure de flux entre un terminal SIP et un serveur Web. Dans un mode particulier de réalisation de l'invention, la passerelle de communication comprend également une passerelle média apte : à recevoir des messages au format SRTP (« Secure Real-time Transport Protocol ») en provenance d'un navigateur WebRTC et à les transmettre au terminal SIP dans un format SRTP ou RTP (« Real-time Transport Protocol ») interprétable par le terminal SIP; et à recevoir des messages au format SRTP ou RTP en provenance du terminal SIP et à les transmettre à un navigateur WebRTC au format SRTP conformément au standard WebRTC. Dans un autre mode particulier de réalisation de l'invention, la passerelle de communication comprend également un dispositif de transcodage apte : à convertir le format audio et/ou vidéo d'un contenu reçu d'un navigateur WebRTC en un format audio et/ou vidéo supporté par le terminal SIP; et à convertir le format audio et/ou vidéo d'un contenu reçu du terminal SIP en un format audio et/ou vidéo supporté par un navigateur WebRTC. Selon encore un autre aspect, l'invention vise également un système de communication comprenant au moins un terminal SIP et une passerelle de communication selon l'invention.
Dans un mode particulier de réalisation, le système de communication comprend également au moins un serveur Web. Le système de communication et la passerelle de communication selon l'invention bénéficient des mêmes avantages, cités précédemment, que le procédé de communication et le dispositif de communication.
Brève description des dessins Des caractéristiques et avantages particuliers de la présente invention ressortiront de la description détaillée faite aux figures dans lesquelles : - la figure 1 déjà décrite illustre un exemple, conforme à l'état de la technique, de système de communication reposant sur une architecture WebRTC; la figure 2 illustre un exemple de système de communication selon un mode de réalisation de l'invention ; la figure 3 illustre un exemple d'architecture matérielle d'un dispositif de communication selon l'invention ; la figure 4 représente, dans une variante d'implémentation, les principales étapes du mécanisme d'enregistrement d'un terminal SIP mis en oeuvre durant l'exécution du procédé de communication selon l'invention ; la figure 5 représente, dans une première variante d'implémentation, les principales étapes du mécanisme d'ouverture d'une communication entre un terminal SIP et un terminal WebRTC mis en oeuvre durant l'exécution du procédé de communication selon l'invention ; la figure 6 représente, dans une deuxième variante d'implémentation, les principales étapes du mécanisme d'ouverture d'une communication entre un terminal SIP et un terminal WebRTC mis en oeuvre durant l'exécution du procédé de communication selon l'invention. Description détaillée de l'invention La figure 2 représente, dans son environnement, un système de communication 30 conforme à l'invention, dans un mode particulier de réalisation.
Par souci de simplification, des références identiques sont données sur cette figure aux éléments communs avec le système de communication 10 illustré à la figure 1. Conformément à l'invention, le système de communication 30 comprend deux terminaux SIP 5 et 6 qui peuvent communiquer, par l'intermédiaire d'un réseau de communication 9, conformément au protocole SIP avec un dispositif de communication 8 intégré dans une passerelle de communication 7. Les terminaux SIP 5 et 6 peuvent être, par exemple des téléphones fixes, des téléphones portables ou des téléphones logiciels. Dans l'exemple illustré à la figure 2, le terminal SIP 5 est un téléphone fixe utilisé par l'utilisateur U3 tandis que le terminal SIP 6 est un téléphone portable utilisé par l'utilisateur U4. Le dispositif de communication 8 et la passerelle de communication 7 communiquent en outre avec le serveur Web 3 par l'intermédiaire d'un réseau 4. La passerelle de communication 7 comporte en outre un dispositif de communication 8 conforme à l'invention.
Aucune limitation n'est attachée à la nature de la passerelle de communication 7 qui peut être par exemple un serveur informatique ou encore une passerelle résidentielle.
Le serveur Web 3 communique d'autre part, par l'intermédiaire du réseau 4, avec les navigateurs installés sur les terminaux informatiques 1 et 2 utilisés respectivement par les utilisateurs U1 et U2. Les réseaux de communication 4 et 9 supportent le protocole IP. Aucune autre limitation n'est attachée à la nature des réseaux de communication 4 et 9. Ces réseaux de communication peuvent ainsi être des réseaux filaires ou sans fil (ex : WLAN (Wireless Local Area Network)), privés ou publics, etc. Le dispositif de communication 8 dispose ici de l'architecture matérielle d'un ordinateur, telle qu'illustrée schématiquement à la figure 3.
Il comporte notamment un processeur 8A, une mémoire morte 8B, une mémoire vive 8C, une mémoire non volatile 8D, et des moyens de communications 8E. Le processeur 8A, les mémoires 8B-8D et les moyens de communication 8E peuvent être partagés avec des moyens correspondants de la passerelle de communication 7. La mémoire morte 8B du dispositif de communication 8 constitue un support d'enregistrement lisible par le processeur 8A et sur lequel est enregistré un programme d'ordinateur conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé de communication conforme à l'invention, les étapes de ce procédé de communication étant décrites ultérieurement en référence aux figures 4 à 6, dans un mode particulier de réalisation.
Ce programme d'ordinateur définit de façon équivalente des modules (logiciels) fonctionnels du dispositif de communication 8, tels que notamment un module 8B1 de réception d'une requête d'enregistrement SIP, un module 8B2 de génération d'une requête d'établissement d'une session de communication à partir d'une requête d'enregistrement SIP, un module 8B3 de communication avec un serveur Web apte à transmettre une requête d'établissement d'une session de communication et à recevoir un message de confirmation de l'établissement de la session de communication, un module d'association 8B4 apte à associer un terminal SIP et une session de communication et un module 8B5 d'émission d'une réponse SIP de succès. Le module 8B1 de réception d'une requête d'enregistrement SIP, le module 8B3 de communication avec un serveur Web et le module 8B5 d'émission d'un message SIP utilisent notamment les moyens de communication 8E. Leurs fonctions sont décrites plus en détail ci-dessous en référence aux étapes du procédé de communication illustrées aux figures 4 à 6. La figure 4 représente les principales étapes d'un procédé de communication selon l'invention dans un mode particulier de réalisation dans lequel il est mis en oeuvre par le dispositif de communication 8 lors de l'enregistrement du terminal SIP 5. On suppose que l'utilisateur U3 souhaite établir une communication avec l'utilisateur U1 à partir du terminal SIP 5.
L'utilisateur U3 se connecte sur son compte utilisateur accessible à partir du terminal SIP 5. Sur connexion de l'utilisateur U3, le terminal SIP 5 envoie une demande d'enregistrement au dispositif de communication 8 intégré dans la passerelle de communication 7.
Conformément au protocole SIP, cette demande d'enregistrement prend ici la forme connue en soi d'une requête SIP R1 d'enregistrement de type REGISTER qui permet d'associer le terminal SIP 5 à l'adresse SIP URI-U3 de l'utilisateur U3. Sur réception de la requête SIP R1 d'enregistrement (étape E10), le dispositif de communication 8 génère, lors d'une étape E20, une requête R2 d'établissement d'une session de communication 12 avec le serveur Web 3. Cette requête R2 d'établissement de session comprend un identifiant d'un protocole de communication utilisé pour tous les messages échangés dans le cadre de la session de communication 12 entre le dispositif de communication 8 et le serveur Web 3 ainsi que l'adresse SIP URI-U3 de l'utilisateur U3.
Dans le mode de réalisation décrit ici, le protocole de communication utilisé est le protocole de communication WebSocket tel que défini par le standard RFC 6455 (ou par une évolution de ce standard) et l'identifiant du protocole est l'identifiant « websocket ». Conformément au protocole WebSocket, la requête R2 prend ici la forme d'une requête HTTP d'upgrade. Lors d'une étape E30, le dispositif de communication 8 transmet au serveur Web la requête R2 d'établissement. Sur réception de la requête R2, le serveur Web 3 initie une procédure d'authentification AD du terminal SIP 5.
Dans le cadre de cette procédure d'authentification AD, le serveur Web 3 envoie au dispositif de communication 8 une demande d'identification D1 comprenant un challenge nonce. Dans le mode de réalisation décrit ici, la demande d'identification est une procédure de type « authentification digest » et la requête HTTP associé à ce type d'authentification prend la forme : HTT? GET WWW-Authenticate : Digest realm=SIP URI-U3, qop="auth, auth-int", nonce=(nonce), opaque=(opaque) En variante, la requête HTTP peut ne pas suivre le formalisme « authentification digest ».
Sur réception de ce challenge nonce (étape E40) transporté par la demande d'identification D1, le dispositif de communication 8 génère, lors d'une étape E50, une réponse SIP R3 d'authentification contenant ce challenge nonce. La réponse SIP R3 d'authentification est par exemple une réponse SIP de type 401 Unauthorized contenant le challenge nonce.
La réponse SIP R3 d'authentification est ensuite transmise au terminal SIP 5 lors d'une étape E60. Sur réception de la réponse SIP R3 d'authentification, le terminal SIP 5 génère, une requête SIP R4, de type REGISTER, comprenant des informations d'authentification, notamment une réponse Res au challenge émis par le serveur Web 3 ainsi qu'un identifiant ID-USER3 de l'utilisateur U3, cet identifiant étant par exemple un identifiant IMPI (pour « IP Multimedia Private Identity »). Le terminal SIP 5 transmet ensuite la requête SIP R4 au dispositif de communication 8 Sur réception de la requête SIP R4 (étape E70), le dispositif de communication 8 extrait de la requête SIP R4 la réponse Res au challenge et l'identifiant ID-USER3. Le dispositif de communication 8 génère (étape E80) et transmet (étape E90) au serveur Web 3 une requête de réponse R5 contenant la réponse Res et l'identifiant ID-USER3.
Dans le mode de réalisation décrit ici, la demande d'identification est une requête HTTP qui prend la forme : HTTP GET WWW-Authorization: Digest realm=SIP URI-U3, username = ID-USER3, nonce=(nonce), qop=auth, nc=(nc), cnonce=(cnonce), response=(Res), opaque=(opaque) Sur réception de la requête de réponse R5, le serveur Web 3 vérifie que la réponse Res est valide, i.e. conforme à la réponse Res attendue. Si la réponse Res n'est pas valide, l'utilisateur U3 utilisant le terminal SIP 5 n'est pas authentifié. Le serveur Web 3 transmet alors un message d'erreur d'authentification au dispositif de communication 8. Sur réception de ce message d'erreur, le dispositif de communication 8 transmet au terminal SIP 5 une réponse SIP de type 403 Forbidden.
Si la réponse Res est valide, l'utilisateur U3 utilisant le terminal SIP 5 est authentifié et le serveur Web 3 vérifie que l'utilisateur U3 dispose des droits d'accès au service de communication demandé. La vérification des droits d'accès de l'utilisateur U3 s'effectue en interrogeant une base de données 10 locale ou distante.
Le cas échéant, le serveur Web 3 enregistre l'utilisateur U3, i.e. associe l'adresse IP du terminal SIP 5 à l'adresse SIP URI-U3 de l'utilisateur U3 au sein d'un service de localisation. Un tel service de localisation peut être distant ou hébergé sur le serveur Web 3. Lorsque l'enregistrement est effectué, le serveur Web 3 confirme l'établissement de la session de communication en transmettant au dispositif de communication 8, un message de confirmation R6 sous la forme d'une réponse HTTP. Dans l'exemple décrit ici, la réponse HTTP est de type HTTP 200 OK et comporte un challenge nonce2 pouvant être ultérieurement utilisé par le terminal SIP 5 pour s'identifier auprès du serveur Web3 et/ou du dispositif de communication 8.
En variante, la réponse HTTP 200 OK ne comporte aucun challenge nonce2. Sur réception du message de confirmation R6, le dispositif de communication 8 associe, par exemple dans une base de données interne au dispositif de communication 8, un identifiant (par exemple l'adresse IP) du terminal SIP 5 à un identifiant de la session de communication 12 ouverte entre le dispositif de communication 8 et le serveur 20 Web 3. Lors de l'étape E120, le dispositif de communication 8 transmet au terminal SIP 5 une réponse SIP R7 de type 200 OK, cette réponse SIP R7 confirmant au terminal SIP 5 son bon enregistrement sur le coeur de réseau WebRTC et comportant éventuellement le challenge nonce2 si ce dernier est présent dans le message de 25 confirmation R6. Le dispositif de communication 8 lors d'une étape E130 récupère par l'intermédiaire du serveur Web 3, via la session de communication 12 ouverte avec ce serveur, les privilèges de l'utilisateur U3 du terminal SIP 5 et les sauvegarde localement, par exemple dans une mémoire cache. 30 Nous allons maintenant décrire, dans une première variante de réalisation représentée à la figure 5, les principales étapes du procédé de communication mise en oeuvre par le dispositif de communication 8 lors de l'établissement d'une communication entre le terminal SIP 5 et le navigateur WebRTC du terminal 1. Pour établir une communication, le terminal SIP 5 envoie une requête SIP de 35 gestion d'appel au dispositif de communication 8 intégré dans la passerelle de communication 7.
Conformément au protocole SIP, cette requête SIP de gestion d'appel prend ici la forme d'une requête SIP R8 de type INVITE, cette requête INVITE contenant l'adresse SIP URI-U1 de l'utilisateur U1 ainsi que l'adresse SIP URI-U3 de l'utilisateur U3. Sur réception de la requête de gestion d'appel R8 (étape F10), le dispositif 5 de communication 8 vérifie la présence dans cette requête R8 d'information d'authentification et notamment d'une réponse Res2 au challenge nonce2. Si une réponse Res2 au challenge nonce2 est détectée, le dispositif de communication 8 vérifie que cette réponse est valide et le cas échéant authentifie l'utilisateur U3 du terminal SIP-5. Puis, le dispositif de communication 8 exécute les 10 étapes du procédé de communication F80, F90, F100, F110 et F120 décrites ultérieurement. Si aucune réponse Res2 au challenge nonce2 n'est détectée, le dispositif de communication 8 génère, lors d'une étape F20, un message de gestion d'appel Ml. Ce message de gestion d'appel M1 comprend l'adresse SIP URI-U1 de 15 l'utilisateur U1 et l'adresse SIP URI-U3 de l'utilisateur U3. Dans le mode de réalisation décrit ici, le message de gestion d'appel M1 est décrit, conformément au format JSON, sous la forme : JSON {request: "call", callee: (SIP URI-U1)} Dans le mode de réalisation décrit ici, le dispositif de communication 8 20 identifie la session de communication 12 établie avec le serveur Web 3 lors de l'enregistrement du terminal SIP 5 et transmet le message de gestion d'appel M1 au serveur Web 3 via cette session de communication 12 lors d'une étape F30. Sur réception du message de gestion d'appel, le serveur Web 3 initie, dans le mode de réalisation décrit ici, une procédure d'authentification AD de type 25 « authentification digest » du terminal SIP 5. Dans le cadre de cette procédure d'authentification AD, le serveur Web 3 envoie au dispositif de communication 8 une demande d'identification D2 comprenant un challenge nonce3. Dans le mode de réalisation décrit ici, la demande d'identification D2 est 30 décrite sous la forme : JSON {response: "call", type: "unauthentified", callee: (SIP URI-U1), nonce: (nonce3)} Sur réception de ce challenge (étape F40) via la session de communication 12 avec le serveur Web 3, le dispositif de communication 8 génère, lors d'une étape F50, 35 une réponse SIP R9 d'authentification de type 401 Unauthorized et contenant ce challenge nonce3.
La réponse SIP R9 d'authentification est ensuite transmise au terminal SIP 5 lors d'une étape F60. Sur réception de la réponse SIP R9 d'authentification, le terminal SIP 5 génère une requête SIP R10, de type INVITE, comprenant une réponse Res3 au challenge nonce3 émis par le serveur Web 3, l'adresse SIP URI-Ul de l'utilisateur Ul, l'identifiant ID-USER3 et l'adresse SIP URI-U3 de l'utilisateur U3. Le terminal SIP 5 transmet ensuite la requête SIP R10 au dispositif de communication 8 Sur réception de la requête SIP R10 (étape F70), le dispositif de communication 8 génère (étape F80) et transmet (étape F90) via la session de communication 12 avec le serveur Web 3 une requête de réponse R11 contenant la réponse Res3 au challenge nonce3 émis par le serveur Web 3, l'adresse SIP URI-U1 de l'utilisateur U1, l'identifiant ID-USER3 et l'adresse SIP URI-U3 de l'utilisateur U3, ces données étant extraites de la requête SIP R10.
Dans le mode de réalisation décrit ici, la requête de réponse R11 est décrite sous la forme : 3SON {request: "call", callee: (SIP URI-U1), realm=SIP URI-U3, username=IDUSER3, nonce=(nonce3), nc=(nc), cnonce=(cnonce), response=(Res3)} Sur réception de la requête de réponse R11, le serveur Web 3 vérifie que la réponse Res3 est valide et le cas échéant authentifie l'utilisateur U3 du terminal SIP-5. Lorsque l'utilisateur U3 du terminal SIP 5 est authentifié, le serveur Web 3 interroge le navigateur de l'utilisateur U1 pour savoir si l'utilisateur U1 accepte l'établissement d'une communication avec l'utilisateur U1. Si l'utilisateur U1 accepte l'établissement de la communication, le serveur Web 3 confirme l'établissement de la communication en transmettant au dispositif de communication 8, un message d'acquittement sous la forme d'une requête R12. Dans le mode de réalisation décrit ici, la requête R12 est décrite sous la forme : JSON {response: "call", type: "ok", callee: (SIP URI-U1)} Sur réception de la requête R12 (étape F100), le dispositif de communication 8 transmet (étape F120) au terminal SIP 5 une réponse SIP R13 de type 200 OK, cette réponse SIP R13 confirmant au terminal SIP 5 le bon établissement de la communication avec le navigateur WebRTC du terminal 1. Dans le mode de réalisation décrit ici, le message de gestion d'appel Ml, la demande d'identification D2, la requête de réponse R11 et la requête R12 transitant via la session de communication 12 entre le dispositif de communication 8 et le serveur Web 3 sont décrits conformément au format de données textuel 3SON défini par la norme RFC 7159. En variante, le message de gestion d'appel Ml, la demande d'identification D2, la requête de réponse R11 et la requête R12 sont décrits conformément au format de données textuel XML défini par le consortium W3C. Dans une autre variante, le message de gestion d'appel Ml, la demande d'identification D2, la requête de réponse R11 et la requête R12 sont décrits conformément au protocole SIP. En d'autres termes, le message de gestion d'appel M1 est identique à la requête SIP R8, la demande d'identification D2 à la réponse SIP d'authentification R9, la requête de réponse R11 à la requête SIP R10 et la requête R12 à la réponse SIP R13. Nous allons maintenant décrire dans une seconde variante de réalisation représentée à la figure 6, les principales étapes du procédé de communication mise en oeuvre par le dispositif de communication 8 lors de l'établissement d'une communication entre le terminal SIP 5 et le navigateur WebRTC du terminal 1. Pour établir la communication, le terminal SIP 5 envoie une requête SIP R14 de gestion d'appel au dispositif de communication 8 intégré dans la passerelle de communication 7, cette requête R14 de type INVITE contenant l'adresse SIP URI-U1 de l'utilisateur U1 ainsi que l'adresse SIP URI-U3 de l'utilisateur U3.
Sur réception de cette requête R14 (étape G10), le dispositif de communication 8 vérifie, lors d'une étape G33, la présence dans cette requête R14 d'information d'authentification et notamment d'une réponse Res2 au challenge nonce2. Si une réponse Res2 au challenge nonce2 est détectée, le dispositif de communication 8, lors d'une étape G34, vérifie que cette réponse est valide et le cas échéant authentifie l'utilisateur U3 du terminal SIP-5. Le dispositif de communication 8 génère alors (étape G81) et transmet (étape G91) via la session de communication 12 avec le serveur Web 3 une requête de réponse R17. La requête de réponse R17 contenant la réponse Res2 au challenge nonce2, l'adresse SIP URI-U1 de l'utilisateur U1, l'identifiant ID-USER3 et l'adresse SIP URI-U3 de l'utilisateur U3, ces données étant extraites de la requête SIP R16 ou des privilèges de l'utilisateur U3 sauvegardés localement par le dispositif de communication 8. Puis, le dispositif de communication 8 exécute les étapes du procédé de communication G100, G110 et G120 décrites ultérieurement. Si aucune réponse Res2 au challenge nonce2 n'est détectée, le dispositif de communication 8 initie, dans le mode de réalisation décrit ici, une procédure d'authentification AD de type « authentification digest » du terminal SIP 5.
Dans le cadre de cette procédure d'authentification AD, le dispositif de communication 8 génère, à l'étape G35, un challenge nonce4 à partir des privilèges de l'utilisateur U3, préalablement sauvegardés en mémoire cache. Puis, le dispositif de communication 8 génère, lors d'une étape G50, une réponse SIP d'authentification R15 de type 401 Unauthorized et contenant ce challenge. La réponse SIP d'authentification R15 est ensuite transmise au terminal SIP 5 lors d'une étape G60. Sur réception de la réponse d'authentification R15, le terminal SIP 5 génère une requête SIP R16, de type INVITE, comprenant une réponse Res4 au challenge nonce4 émis par le dispositif de communication, l'adresse SIP URI-U1 de l'utilisateur U1, l'identifiant ID-USER3 et l'adresse SIP URI-U3 de l'utilisateur U3. Le terminal SIP 5 transmet ensuite la requête SIP R16 au dispositif de communication 8 Sur réception de la requête SIP R16 (étape G70), le dispositif de communication 8 génère (étape G80) et transmet (étape G90) via la session de communication avec le serveur Web 3 une requête de réponse R17'. La requête de réponse R17' contient la réponse Res4 au challenge nonce4 émis par dispositif de communication 8, l'adresse SIP URI-U1 de l'utilisateur U1, l'identifiant ID-USER3 et l'adresse SIP URI-U3 de l'utilisateur U3, ces données étant extraites de la requête SIP R16. Sur réception de la requête de réponse R17', le serveur Web 3 vérifie que la réponse Res4 est valide et le cas échéant authentifie l'utilisateur U3 du terminal SIP-5. Lorsque l'utilisateur U3 du terminal SIP 5, le serveur Web 3 interroge le navigateur de l'utilisateur U1 pour savoir si l'utilisateur U1 accepte l'établissement d'une communication avec l'utilisateur U3. Si l'utilisateur U1 accepte l'établissement de la communication, le serveur Web 3 confirme l'établissement de la communication en transmettant au dispositif de communication 8, un message d'acquittement sous la forme d'une requête R18. Sur réception de la requête R18 (étape G100), le dispositif de communication 8 génère (étape G110) et transmet (étape G120) au terminal SIP 5 une réponse SIP R19 de type 200 OK, cette réponse SW confirmant au terminal SIP 5 le bon établissement de la communication avec le navigateur WebRTC du terminal 1.

Claims (13)

  1. REVENDICATIONS1. Procédé de communication entre un terminal SIP (5) et un serveur Web (3), ledit procédé étant destiné à être mis en oeuvre par un dispositif de communication (8) placé en coupure de flux entre ledit terminal SIP (5) et ledit serveur Web (3), ledit procédé comprenant : une étape (E10) de réception d'une requête SIP (R1) d'enregistrement émise par ledit terminal SIP (5), ladite requête (R1) d'enregistrement contenant un identifiant (SIP URI-U3) de l'utilisateur dudit terminal SIP (5) ; une étape (E20) de génération, à partir de ladite requête SIP (R1) d'enregistrement, d'une requête (R2) d'établissement d'une session de communication (12) entre ledit dispositif (8) et ledit serveur Web (3), ladite requête (R2) d'établissement comprenant un identifiant d'un protocole de communication utilisé pour tous les messages échangés entre ledit dispositif (8) et ledit serveur (3) dans le cadre de ladite session de communication (12) ; une étape (E30) de transmission audit serveur Web (3) de ladite requête (R2) d'établissement ; et sur réception en provenance dudit serveur Web (3) d'un message de confirmation (R6) de l'établissement de ladite session de communication (12), une étape (E110) d'association entre ledit terminal SIP (5) et ladite session de communication (12) et une étape (E120) d'émission d'un réponse SIP (R7) de succès à destination dudit terminal SIP (5).
  2. 2. Procédé de communication selon la revendication 1 dans lequel ledit protocole de communication est un protocole WebSocket.
  3. 3. Procédé de communication selon l'une des revendications 1 à 2 comprenant en outre après l'établissement de ladite session de communication (12) : une étape (F10) de réception d'au moins une requête SIP (R8) de gestion d'appel émise par ledit terminal SIP (5) ; une étape (F20) de génération, à partir de ladite au moins une requête SIP (R8) de gestion d'appel, d'un message (M1) de gestion d'appel ; une étape (F30) de transmission audit serveur Web (3) dudit message (M1) de gestion d'appel via ladite session de communication (12).35
  4. 4. Procédé de communication selon l'une des revendications 1 à 3 caractérisé en ce qu'il comprend, dans le cadre d'une procédure d'authentification (AD) : une étape (E40, F40) de réception d'un challenge (nonce, nonce3) en provenance dudit serveur Web (3) en réponse à ladite requête (R2) d'établissement ou audit message (M1) de gestion d'appel ; une étape de génération (E50, F50) d'une réponse SIP (R3, R9) d'authentification contenant ledit challenge (nonce, nonce3) ; une étape (E60, F60) d'envoi audit terminal SIP (5) de ladite réponse SIP (R3, R9) d'authentification ; une étape (E70, F70) de réception d'une requête SIP (R4, R10), ladite requête SIP (R4, R10) contenant une réponse (Res, Res3) audit challenge (nonce, nonce3) ; une étape (E90, F90) d'envoi audit serveur Web (3) de ladite réponse (Res, Res3) audit challenge (nonce, nonce3).
  5. 5. Procédé de communication selon l'une des revendications 1 à 4 comprenant en outre après l'établissement de ladite session de communication (12) : une étape (F100) de réception d'au moins une réponse (R12) à un message (M1) de gestion d'appel émis par ledit serveur Web (3) via ladite session de communication (12) ; une étape (F110) de génération, à partir de ladite au moins une réponse (R12) au message (M1) de gestion d'appel, d'une deuxième réponse SIP (R13) ; une étape (F120) de transmission de ladite deuxième réponse SIP (R12) audit terminal SIP (5) associé à ladite session de communication (12).
  6. 6. Procédé de communication selon l'une des revendications 4 à 5 dans lequel ledit message (M1) de gestion d'appel et ladite au moins une réponse (R12) au message (M1) de gestion d'appel sont conformes au format JSON, au format XML ou au format SIP.
  7. 7. Procédé de communication selon la revendication 4 comprenant en outre après l'établissement de ladite session de communication (12) : - une étape (E130) de récupération auprès dudit serveur Web (3) des permissions associées à l'utilisateur dudit terminal SIP (5) ; - sur réception d'au moins une deuxième requête SIP (R14) de gestion d'appel émise par ledit terminal SIP (5), ladite au moins une deuxième requête SIP (R14) degestion d'appel ne contenant pas d'information d'authentification (Res2) dudit terminal SIP (5) : o une étape de calcul (G35) d'un deuxième challenge (nonce 4) à partir desdites permissions ; 0 une étape de génération (G50) d'une deuxième réponse SIP (R15) comprenant ledit deuxième challenge (nonce4) ; et o une étape de transmission (G60) au terminal SIP (5) de ladite deuxième réponse SIP (R15).
  8. 8. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé de communication selon l'une quelconque des revendications 1 à 7 lorsque ledit programme est exécuté par ordinateur.
  9. 9. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé de communication selon l'une quelconque des revendications 1 à 7.
  10. 10. Dispositif de communication (8) destiné à être placé en coupure de flux entre un terminal SIP (5) et un serveur Web (3), ledit dispositif (8) comprenant : un module (8B1) de réception d'une requête SIP (R1) d'enregistrement émise par ledit terminal SIP (5), ladite requête SIP (R1) d'enregistrement contenant un identifiant (SIP URI-U3) de l'utilisateur dudit terminal SIP (5) ; un module (8B2) de génération, à partir de ladite requête SIP (R1) d'enregistrement, d'une requête (R2) d'établissement d'une session de communication (12) entre ledit dispositif (8) et ledit serveur Web (3), ladite requête (R2) d'établissement comprenant un identifiant d'un protocole de communication utilisé pour tous les messages échangés entre ledit dispositif (8) et ledit serveur (3) dans le cadre de ladite session de communication (12) ; un module (8B3) de communication avec ledit serveur Web (3) apte à transmettre ladite requête (R2) d'établissement et à recevoir un message de confirmation (R6) de l'établissement de ladite session de communication (12) ; et un module (8B4) d'association apte à associer ledit terminal SIP (5) et ladite session de communication (12) et un module (8B5) d'émission à destination dudit terminal SIP (5) d'un réponse SIP (R7) de succès, lesdits modules d'association (8B4) et d'émission (8B5) étant activés sur réception en provenance dudit serveur Web (3)dudit message de confirmation (R6) de l'établissement de ladite session de communication (12).
  11. 11. Passerelle de communication (7) comprenant un dispositif de communication (8) selon la revendication 10.
  12. 12. Système de communication (30) comprenant au moins un terminal SIP (5) et une passerelle de communication (7) selon la revendication 11.
  13. 13. Système de communication (30) selon la revendication 12 comprenant également au moins un serveur Web (3).
FR1462966A 2014-12-19 2014-12-19 Procede et dispositif de communication entre un terminal sip et un serveur web Withdrawn FR3030958A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1462966A FR3030958A1 (fr) 2014-12-19 2014-12-19 Procede et dispositif de communication entre un terminal sip et un serveur web

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1462966A FR3030958A1 (fr) 2014-12-19 2014-12-19 Procede et dispositif de communication entre un terminal sip et un serveur web

Publications (1)

Publication Number Publication Date
FR3030958A1 true FR3030958A1 (fr) 2016-06-24

Family

ID=52627436

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1462966A Withdrawn FR3030958A1 (fr) 2014-12-19 2014-12-19 Procede et dispositif de communication entre un terminal sip et un serveur web

Country Status (1)

Country Link
FR (1) FR3030958A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113938469A (zh) * 2021-08-27 2022-01-14 上海云翌通信科技有限公司 非sip协议终端和sip协议终端通话方法，网关及sip服务器
CN117596231A (zh) * 2024-01-18 2024-02-23 深圳星网信通科技股份有限公司 通信方法、终端设备、系统及介质

Citations (3)

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

Patent Citations (3)

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

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FRANKS NORTHWESTERN UNIVERSITY P HALLAM-BAKER VERISIGN J ET AL: "HTTP Authentication: Basic and Digest Access Authentication; rfc2617.txt", 19990601, 1 June 1999 (1999-06-01), XP015008400, ISSN: 0000-0003 *
JAMES UNDERY UBIQUITY CATEGORY: STANDARDS TRACK SANJOY SEN NORTEL NETWORKS VESA TORVINEN ERICSSON: "Enhanced Usage of HTTP Digest Authentication for SIP <draft-undery-sip-auth-01.txt>; draft-undery-sip-auth-01.txt", 20020601, no. 1, 1 June 2002 (2002-06-01), XP015005567, ISSN: 0000-0004 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113938469A (zh) * 2021-08-27 2022-01-14 上海云翌通信科技有限公司 非sip协议终端和sip协议终端通话方法，网关及sip服务器
CN117596231A (zh) * 2024-01-18 2024-02-23 深圳星网信通科技股份有限公司 通信方法、终端设备、系统及介质
CN117596231B (zh) * 2024-01-18 2024-05-28 深圳星网信通科技股份有限公司 通信方法、终端设备、系统及介质

Similar Documents

Publication Publication Date Title
US10819757B2 (en) System and method for real-time communication by using a client application communication protocol
US9648006B2 (en) System and method for communicating with a client application
EP2291980B1 (fr) Acces reseau a distance via un reseau visite
KR20110013516A (ko) 디바이스 및 서버 능력을 전달하는 방법
EP3639541A1 (fr) Procédé de configuration d&#39;un terminal
US9923844B1 (en) Conveying instant messages via HTTP
EP2087698B1 (fr) Procédé d&#39;etablissement d&#39;une connexion securisöe, equipement CFM et produit programme d&#39;ordinateur correspondants
WO2016083751A1 (fr) Procede de communication entre un terminal equipe d&#39;un client webrtc et un terminal accessible via un cœur de reseau ims
EP2873211B1 (fr) Procédé d&#39;enregistrement d&#39;au moins une adresse publique dans un réseau ims et application correspondante
FR3030958A1 (fr) Procede et dispositif de communication entre un terminal sip et un serveur web
EP2898715B1 (fr) Procedes de verification et de controle dans un coeur de reseau ip multimedia, et serveurs
EP3646554B1 (fr) Procédé de traitement d&#39;une requête et serveur d&#39;un coeur de réseau ip multimédia
EP2868058B1 (fr) Procédé d&#39;émission d&#39;un message par un serveur d&#39;un coeur de réseau ip multimedia ims, et serveur
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
JP5331032B2 (ja) ネットワークの呼制御システム
WO2011073584A1 (fr) Procede de controle d&#39;acces a un reseau local
WO2017220883A1 (fr) Procédé de détermination d&#39;un ensemble de formats de codage pour établir une communication
FR3001351A1 (fr) Enregistrement d&#39;un equipement client par l&#39;intermediaire d&#39;un serveur mandataire dans un reseau de communication
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
FR2988951A1 (fr) Procede d&#39;enregistrement d&#39;un serveur aupres d&#39;une pluralite de coeurs de reseau, et serveur.
FR2881593A1 (fr) Procede et systeme d&#39;enregistrement d&#39;utilisations, serveur hss et serveur d&#39;application d&#39;un reseau ims
EP2651093A1 (fr) Procédé d&#39;appairage d&#39;un élément de sécurité à un terminal de télécommunications et système correspondant

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20160624

ST Notification of lapse

Effective date: 20170831