FR2890270A1 - Unite de serveur, unite de client, procede d'exploitation d'une unite de serveur et procede d'exploitation d'une unite de client - Google Patents

Unite de serveur, unite de client, procede d'exploitation d'une unite de serveur et procede d'exploitation d'une unite de client Download PDF

Info

Publication number
FR2890270A1
FR2890270A1 FR0606285A FR0606285A FR2890270A1 FR 2890270 A1 FR2890270 A1 FR 2890270A1 FR 0606285 A FR0606285 A FR 0606285A FR 0606285 A FR0606285 A FR 0606285A FR 2890270 A1 FR2890270 A1 FR 2890270A1
Authority
FR
France
Prior art keywords
poc
unit
client
client unit
server
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.)
Granted
Application number
FR0606285A
Other languages
English (en)
Other versions
FR2890270B1 (fr
Inventor
Norbert Schwagmann
Andreas Schmidt
Holger Schmidt
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.)
Intel Deutschland GmbH
Original Assignee
Infineon Technologies AG
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 Infineon Technologies AG filed Critical Infineon Technologies AG
Publication of FR2890270A1 publication Critical patent/FR2890270A1/fr
Application granted granted Critical
Publication of FR2890270B1 publication Critical patent/FR2890270B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

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/40—Support for services or applications
    • H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/10—Push-to-Talk [PTT] or Push-On-Call services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/16—Communication-related supplementary services, e.g. call-transfer or call-hold
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • H04W76/45—Connection management for selective distribution or broadcast for Push-to-Talk [PTT] or Push-to-Talk over cellular [PoC] services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Unité de serveur d'un système de communication qui, dans le cas d'un conflit entre la demande selon laquelle aucune invitation ne doit être transmise à une première unité de client et la demande selon laquelle une deuxième unité de client invite la première unité de client à une session de communication, décide (501 à 506) si une invitation à une session de communication est transmise à la première unité de client.

Description

UNITE DE SERVEUR, UNITE DE CLIENT, PROCEDE D'EXPLOITATION D'UNE UNITE
DE SERVEUR ET PROCEDE D'EXPLOITATION D'UNE UNITE DE CLIENT L'invention concerne une unité de serveur, une unité de client, un procédé d'exploitation d'une unité de serveur et un procédé d'exploitation d'une unité de client.
Le service de communication Push-to-talk-over- Cellular permet à un utilisateur d'un terminal de téléphonie mobile de transmettre simultanément des données vocales à un ou plusieurs récepteurs.
Pour cela, il est typiquement prévu au niveau du terminal de téléphonie mobile une touche PoC spéciale dont l'actionnement permet à l'utilisateur de commencer à émettre des données vocales.
Les données vocales sont habituellement distribuées dès l'émission au moyen d'un réseau de communication de téléphonie mobile, c'est-à-dire qu'elles sont transmises un récepteur souhaité ou à des récepteurs souhaités. Ce processus est appelé streaming .
La transmission est effectuée dans le procédé semi-duplex, c'est-à-dire que pendant la génération et pendant la transmission seul l'émetteur, c'est-à-dire l'utilisateur, qui génère et envoie les données vocales, peut transmettre des données vocales aux récepteurs; cependant, les récepteurs ne peuvent pas envoyer en même temps des données vocales à l'émetteur. Notamment, l'émetteur ne peut pas être interrompu par les récepteurs.
Concrètement, une communication par PoC correspond du point de vue de l'utilisateur aux radiocommunications CB classiques, cependant avec en plus le fait que l'émetteur peut transmettre des données vocales dans le monde entier à des récepteurs qui peuvent être joints par la technique de communication appropriée d'au moins un réseau de communication par téléphonie mobile.
Les utilisateurs de PoC, qui sont impliqués dans une communication PoC, c'est-à-dire une session de communication par PoC, de façon active, c'està-dire comme émetteur, ou de façon passive, c'est-à-dire comme récepteur, sont désignés dans la suite par participant PoC à la communication PoC.
Un utilisateur de PoC a la possibilité d'activer dans le réseau de communication, qui établit le service de communication PoC, ce que l'on appelle à un Incoming Session Barring (ISB), comme décrit dans [1]. Dans ce cas, tous les PoC-Calls adressés l'utilisateur, c'est-à- dire toutes les invitations aux communications PoC, sont rejetés. Un tel flux de messages correspondant est représenté dans la figure 1.
La figure 1 représente un schéma de flux de messages 100 selon l'état de la technique.
Une première unité PoC-Client 101, un serveur de participant PoC 102, un serveur de commande/de participant PoC 103 ainsi qu'une deuxième unité PoCClient 104 participent au flux de messages représenté dans la figure 1.
À l'étape 205, l'utilisateur de la première unité PoC-Client 101 ne souhaite pas recevoir d'appels PoC (PoC-Calls) et active en conséquence le ISB au niveau du terminal de communication qu'il utilise et qui constitue la première unité PoC-Client 101.
À l'étape 106, il est signalé à une unité du réseau de communication, qui délivre le service de communication PoC à un utilisateur de la première unité PoC-Client 101, dans le cas présent le serveur de participant PoC 102, qu'il faut activer ISE. Ceci est effectué au moyen d'un message PUBLISH 113.
À l'étape 107, le serveur de participant PoC 112 envoie en confirmation un message 200 OK 114 à la première unité POC-Client 101. À l'étape 108, l'utilisateur de la deuxième unité PoC-Client 104 invite maintenant l'utilisateur de la première unité PoC--Client 101 à une communication PoC. En conséquence, à l'étape 108, un message INVITE 115 est envoyée par la deuxième unité PoC-Client 104 à le serveur de commande/de participant PoC 103 qui transmet ce message à l'étape 109 au serveur de participant PoC 102 (qui est concrètement responsable de la première unité PoC-Client 101).
À l'étape 110, le serveur de participant PoC 102 vérifie si ISB est initialisé pour la première unité PoCClient 101, c'est-à-dire s'il est activé. Si c'est le cas, l'invitation à une communication PoC est rejetée ou en d'autres termes bloquée.
En conséquence, le serveur de participant PoC 102 envoit à l'étape 111 un message 403 FORBIDDEN 116 au serveur de commande/de participant PoC 103 qui transmet le message 403 FORBIDDEN 116 à l'étape 112 à la deuxième unité PoC-Client de sorte que l'utilisateur de la deuxième unité PoCClient 104 peut être informé que l'invitation à la communication PoC a été rejetée.
Le flux de messages représenté dans la figure 1 est prévu selon les spécifications de l'Open Mobile Alliance (OMA).
En outre, un utilisateur de POC a la possibilité de définir ce que l'on appelle une Reject-List et de le signaler au réseau de communication qui établit le service de communication PoC (voir [1]). Un Reject-List est une liste d'utilisateurs de PoC (respectivement d'unités PoC-Client utilisées par ces utilisateurs). Tous les PoC-Calls, qui sont adressés à l'utilisateur qui a défini le Reject-List (respectivement à l'unité PoCClient utilisée par lui), et qui ont été établis par un utilisateur qui apparaît dans le Reject-List, sont rejetés. Le flux de messages correspondant est similaire à celui représenté dans la figure 1.
Outre PoC, il existe également d'autres services de communication qui présentent la fonctionnalité permettant à un utilisateur de bloquer tous les Calls (ou ceux d'un groupe défini d'utilisateurs) adressés à l'utilisateur (par exemple des appels ou des invitations à des sessions de communication) déjà du côté du réseau de communication qui établit le service de communication respectif.
Dans certains services de communication, en plus de la fonctionnalité d'un ISB décrite ci-dessus, on dispose de la fonctionnalité permettant à un premier utilisateur de demander auprès d'un deuxième utilisateur que le deuxième utilisateur établisse un Call (par exemple une liaison de communication vocale) avec le premier utilisateur.
Ceci est connu par exemple dans le cadre d'une téléphonie vocale normale et est désigné également par fonction Call-Back. Dans des systèmes de communication PoC, la demande de rappel est également désignée par Instant Personal Alert.
Cette fonctionnalité est également disponible dans PoC. Un flux de messages correspondant est représenté dans la figure 2.
La figure 2 représente un schéma de flux de messages selon l'état de la technique.
De façon analogue à la figure 1, une première unité PoC-Client 201, un serveur de participant PoC 202, un serveur de commande/de participant PoC 203 et une deuxième unité PoC-Client 204 participent au flux de message représenté.
À l'étape 205, l'utilisateur de la première unité PoC-Client 201 souhaite demander à un utilisateur de la deuxième unité PoC-Client 204 de le contacter par PoC, c'est-à-dire de l'inviter à une communication PoC.
En conséquence, la première unité PoC-Client 201 envoie à l'étape 206 un message MESSAGE 219 au serveur de participant PoC 202 (voir le document [3]). Le message MESSAGE 219 est conformé selon SIP (Session Initiation Protocol) et le format du contenu du message MESSAGE 219 est spécifié pour PoC. Le message MESSAGE 219 est concrètement transmis au moyen du serveur de participant PoC respectif, c'est-à-dire qu'il est transmis dans ce cas à l'étape 207 du serveur de participant PoC 202 au serveur de commande/de participant PoC 203 et est enfin transmis à l'étape 208 de ce dernier à la deuxième unité PoC-Client 204.
À l'étape 209, la deuxième unité PoC-Client 204 envoie en confirmation un message 200 OK 220 qui est transmis de façon analogue au message MESSAGE 219, aux étapes 210 et 211, à la première unité PoC-Client 201.
À l'étape 212, l'invitation est indiquée à l'utilisateur de la deuxième unité PoC-Client 204. Dans ce cas, on suppose que l'utilisateur de la deuxième unité PoC-Client 204 souhaite donner suite à l'invitation.
En conséquence, la deuxième unité PoC-Client 204 envoie à l'étape 213 un message INVITE 221 qui est transmis de façon analogue au message MESSAGE 219, dans les étapes 214 à 215, à la première unité PoC-Client 201. À l'étape 216, la première unité PoC-Client 201 envoie en confirmation un message 200 OK 222, qui est également transmis de façon analogue au message MESSAGE 219, dans les étapes 217 et 218, à la deuxième unité PoCClient 204.
L'utilisateur de la deuxième unité PoC-Client 204 a la possibilité, par exemple par une commande simple, de donner suite à l'invitation et d'effectuer concrètement un rappel direct de l'utilisateur de la première unité PoC-Client 201.
La combinaison de la fonctionnalité, expliquée en se référant à la figure 1, d'un Incoming Session Barring et de la fonctionnalité, expliquée en se référant à la figure 2, de la demande de rappel peut cependant poser des problèmes. Par exemple, un utilisateur prend part à une conversation et active l'Incoming Session Barring au début de la conversation pour PoC de sorte qu'il ne peut pas être gêné (par des Calls) au cours de la conversation. Cependant, l'utilisateur a besoin d'urgence, au cours de la conversation, d'une information d'un collaborateur en déplacement qui se trouve momentanément chez un client. L'utilisateur envoie alors un Instant Personal Alert au collaborateur en déplacement, c'est-à-dire que le collaborateur en déplacement est invité à contacter l'utilisateur par PoC (Rappel) dès que le collaborateur en déplacement a le temps, par exemple n'est pas dérangé. Peu de temps après la transmission de l'Instant Personal Alert, le collaborateur en déplacement a le temps et établit un PoC-Call avec l'utilisateur. Cependant, si l'utilisateur a activé l'ISB au début de la conversation et a oublié de le désactiver pour permettre au collaborateur en déplacement d'effectuer le rappel correspondant, le PoCCall du collaborateur en déplacement est bloqué.
Même si l'utilisateur y pensait et désactivait l'ISB de façon à permette le rappel du collaborateur en déplacement, il apparaîtrait le problème que l'utilisateur pourrait être de nouveau joint par tous les autres utilisateurs par PoC et pourrait être éventuellement dérangé pendant la conversation. Dans ce cas, il faudrait que l'utilisateur active de nouveau l'ISB après le rappel du collaborateur en déplacement.
Le cas d'application décrit montre qu'une utilisation simultanée de la fonctionnalité ISB et de la fonctionnalité Call-Back pose des problèmes ou entraîne des comportements indésirables du service de communication PoC. Un Instant Personal Alert (Prière de rappeler) selon l'état de la technique est non seulement judicieux dans le cas d'une activation existante mais simule à l'utilisateur une fonctionnalité qui n'existe pas dans ce cas. Dans l'exemple ci-dessus, l'utilisateur demande au collaborateur en déplacement de le rappeler bien que ce ne soit pas possible.
Dans les documents [2], [3], [4] et [5], il est décrit le SIP (Session Initiation Protocol).
Dans le document [6], il est décrit un terminal de communication qui indique à l'utilisateur ou rejette des appels selon des règles en mémoire dans le terminal de communication. Par exemple, il est prévu une liste rouge comportant des données relatives à des terminaux de communication ou à des utilisateurs dont les appels ne sont pas indiqués.
Le but de l'invention est de permettre l'utilisation en parallèle, améliorée par rapport à l'état de la technique, d'Incoming Session Barring et de la fonctionnalité Call-Back.
Le but de invention est atteint par une unité de serveur, une unité de client, un procédé d'exploitation d'une unité de serveur et un procédé d'exploitation d'une unité de client présentant les caractéristiques suivantes.
Il est proposé une unité de serveur d'un système de communication, lequel système de communication comporte une première unité de client et une deuxième unité de client, l'unité de client étant conçue pour décider si une invitation à une session de communication concernant la première unité de client est transmise par la deuxième unité de client, en se fondant sur une information de conflit qui est délivrée par l'unité de serveur et qui spécifie s'il existe un conflit entre un premier message de demande envoyé par la première unité de client et un deuxième message de demande envoyé par la première unité de client. Le premier message de demande spécifie qu'aucune invitation à des sessions de communication concernant la première unité de client, ne doit être transmis par la deuxième unité de client à la première unité de client et le deuxième message de demande spécifie que la deuxième unité de client invite la première unité de client à une session de communication.
Il est en outre proposé une unité de client d'un système de communication, lequel système de communication comporte une autre unité de client, l'unité de client étant conçue pour envoyer un premier message de demande qui spécifie qu'aucune invitation à des sessions de communication concernant la première unité de client ne doit être transmise par l'autre unité de client à la première unité de client. L'unité de client est en outre conçue pour envoyer un deuxième message de demande qui spécifie que l'autre unité de client invite la première unité de client à une session de communication et à déterminer une information de conflit qui spécifie s'il existe un conflit entre le premier message de demande et le deuxième message de demande.
En outre, il est proposé un procédé d'exploitation d'une unité de serveur et un procédé d'exploitation d'une unité de client conformément à l'unité de serveur décrite ci-dessus respectivement à l'unité de client décrite ci-dessus.
Concrètement, il est proposé une possibilité d'éviter le problème selon lequel un utilisateur est invité par un autre utilisateur (au moyen d'une unité de client qu'il utilise) à le rappeler (rappel téléphonique, invitation à une session PoC, etc.), bien que des rappels soient bloqués par l'autre utilisateur, par exemple à cause d'une liste rouge définie par l'utilisateur, sur laquelle se trouve l'autre utilisateur, ou parce que l'utilisateur a actuellement décidé qu'aucun appel (aucune invitation à des sessions PoC etc.) ne doit être effectué vers son unité PoC-Client (comme dans le cas de PoC lors de l'activation d'un ISB (Incoming Session Barring). En se fondant sur la détermination d'un tel conflit, l'unité de serveur, c'est-à-dire une unité du réseau de communication qui délivre le service de communication correspondant (par exemple une téléphonie vocale ou PoC (Push-to-talk-over-Cellular), décide si l'autre utilisateur peut effectué, par exemple dans une période déterminée, le rappel demandé qui ne doit donc pas être bloqué dans le réseau de communication. Par exemple, dans le cas d'une liste rouge, l'autre utilisateur est exclus de la liste rouge pour une période donnée qui est déterminée par exemple par l'utilisateur. De façon analogue, dans le cas où l'utilisateur a déterminé qu'aucun appel ne doit être établi vers son unité PoC-Client, on peut définir un niveau d'exclusion pour l'autre utilisateur de sorte que l'utilisateur peut effectuer des rappels dans une période donnée, c'est-à-dire que ces rappels sont établis par le réseau de communication. Concrètement, le blocage d'invitations entrantes à des sessions de communication, qui ont été établies par un ou plusieurs utilisateurs définis, est automatiquement exclu.
Le conflit peut être résolu en utilisant l'invention de sorte que les fonctionnalités d'une demande de rappel et d'un blocage d'appels entrants (respectivement d'invitation à des sessions de communication) peuvent être utilisées de façon fiable est sûre. Notamment, un utilisateur peut se fier au fonctionnement correct de ces fonctionnalités.
La communication entre l'unité de client, qui est par exemple réalisée au moyen d'un terminal de téléphonie mobile, et l'unité de serveur respectivement le réseau de communication (par exemple un réseau de téléphonie mobile) peut être effectué par exemple conformément à http (Hypertext Transfer Protocol), H.323, WAP (Wireless Application Protocol) ou SIP (Session Initiation Protocol).
Des perfectionnements de l'invention ressortiront des revendications dépendantes. Les autres conformations de l'invention, qui sont décrites conjointement avec l'unité de serveur, sont aussi logiquement valables pour l'unité de client, le procédé d'exploitation d'une unité de serveur et le procédé d'exploitation d'une unité de client.
Dans un mode de réalisation, l'unité de serveur comporte un dispositif de réception d'information de conflit qui est conçu pour recevoir l'information de conflit de l'unité de client. Dans un autre mode de réalisation, l'unité de serveur comporte un dispositif de détermination qui est conçu pour déterminer l'information de conflit.
La survenance d'un conflit (entre le premier message de demande et le deuxième message de demande) peut donc être déterminée par l'unité de serveur ou par l'unité de client. Lorsqu'elle détecte un conflit, l'unité de serveur peut également être conçue pour signaler ce conflit à la première unité de client.
L'unité de serveur peut comporter un dispositif de réception d'information d'intervalle de temps qui est conçu pour recevoir la spécification d'un intervalle de temps de la part de la première unité de client. L'unité de serveur peut en conséquence être conçu, dans le cas d'un conflit entre le premier message de demande et le deuxième message de demande, pour décider que l'invitation à la session de communication concernant la première unité de client est transmise par la deuxième unité de client dans le cas où l'invitation a été envoyée dans l'intervalle de temps spécifié.
L'intervalle de temps est par exemple déterminé par l'utilisateur de la première unité de client, par exemple par une unité PoC-Client. L'utilisateur a ainsi le contrôle total de cette fonctionnalité.
Le deuxième message de demande spécifie par exemple que la deuxième unité de client doit établir une liaison de communication vocale, une liaison de communication de téléphonie vidéo ou une liaison de communication de message textuel avec la première unité de client.
Le deuxième message de demande peut également spécifier que la deuxième unité de client invite la première unité de client à une session de communication PoC.
Le premier message de demande peut par exemple signaler un Incoming Session Barring. L'unité de client peut être conçue pour transmettre l'information de conflit à une unité de serveur.
Dans un mode de réalisation, l'unité de client est conçue pour décider si une invitation à une session de communication concernant la première unité de client est transmise par l'autre unité de client à la première unité de client et pour signaler le résultat de la décision à l'unité de serveur.
Des exemples de réalisation de l'invention sont 5 expliqués en détail dans la suite et sont représentés dans les figures.
La figure 1 représente un schéma de flux de messages selon l'état de la technique.
La figure 2 représente un schéma de flux de messages 10 selon l'état de la technique.
La figure 3 représente un système de communication selon un exemple de réalisation de l'invention.
La figure 4 est une vue schématique d'un terminal de communication selon un exemple de réalisation de 15 l'invention.
La figure 5 représente un organigramme selon un exemple de réalisation de l'invention.
La figure 6 représente un schéma de flux de messages selon un exemple de réalisation de l'invention.
La figure 7 représente un organigramme selon un exemple de réalisation de l'invention.
La figure 8 représente un schéma de flux de messages selon un exemple de réalisation de l'invention.
La figure 9 représente un organigramme selon un 25 exemple de réalisation de l'invention.
La figure 10 représente un schéma de flux de messages selon un exemple de réalisation de l'invention.
La figure 3 représente un système de communication 300 selon un exemple de réalisation de l'invention.
Une première unité PoC-Client 301, une deuxième unité PoC-Client 302 et une troisième unité PoC-Client 303 sont couplées chacune à un serveur de participant PoC (PoC-Serveur Participant Function) 305 à chaque fois par l'intermédiaire d'une interface 304. Les serveurs de participant PoC 305 sont couplés à un serveur de commande PoC (PoC-Server Controlling Function) 306. Les unités PoC-Client 301, 302, 303 sont réalisées chacune au moyen d'un terminal de communication, par exemple au moyen d'un terminal de téléphonie mobile.
Le serveur de commande PoC 306 est couplé à un serveur GM/PS (Group Management/Presence) 307. Le serveur GM/PS 307 comporte la fonctionnalité d'un serveur GM et d'un serveur PS (à cet égard, on fait référence dans la suite à la fonctionnalité d'un serveur GM respectivement d'un serveur PS). Le serveur GM/PS peut également être conformé de façon séparée sous la forme d'un serveur GM et d'un serveur PS. Dans le cadre de sa fonctionnalité comme serveur GM, le serveur GM/PS gère des réglages d'utilisateur qui concernent le Group Management, par exemple une liste rouge définie par un utilisateur d'une unité PoC-Client 301, 302, 303 peut être gérée par le serveur GM/PS 307 (voir ci-dessous). Dans le cas de sa fonctionnalité comme serveur GM, le serveur GM/PS gère des réglages d'utilisateur qui concernent la Presence , c'est-à-dire la disponibilité, d'utilisateurs des unités PoC-Client 301, 302, 303. Par exemple, le serveur GM/PS 307 gère l'information concernant celle des unités PoC-Client 301, 302, 303 pour laquelle l'ISB est actuellement activé.
Les interfaces 304 sont proposées par exemple par le RAN (Radio Access Network), le réseau central (Core Network, CN) et l'IMS (Internet Protocol based Multimedia Subsystem) d'un système de communication UMTS (Universal Mobil Telecommunication Système) ou un système de communication GSM (Global System for Mobile Communication).
Cependant, les interfaces 304 peuvent être également proposées par exemple par un réseau de communication PSTN (Public Switched Telephone Network).
Les unités PoC-Client 301, 302, 303 sont intégrées chacune dans un terminal de communication qui est conçu par exemple selon l'interface respective 304 en terminal de téléphonie mobile pour la communication conformément à la norme UMTS, la norme GSM, la norme GPRS (General Packet Radio Service) ou une autre norme de communication par téléphonie mobile.
Les terminaux de communication implémentent, en plus de leur fonction comme unités PoC-Client, d'autres fonctions comme expliqué dans la suite en se référant la figure 4.
La figure 4 est une vue schématique d'un terminal de communication 400 selon un exemple de réalisation de l'invention.
Comme mentionné, le terminal de communications 400 est constitué par une unité PoC-Client 400 qui est conformé conformément à la première unité PoC-Client 301, la deuxième unité PoC-Client 302 et la troisième unité PoC-Client 303. L'unité PoC-Client 400 remplit concrètement les fonctionnalités PoC pures du terminal de communication, par exemple elle est appropriée à l'échange de messages avec le serveur de participant PoC correspondant 305 (par exemple pour établir un PoC-Call ou pour envoyer un Instant Personal Alert).
Le terminal de communication 400 implémente en outre une unité GM/PSClient 402. L'unité GM/PS-Client 402 remplit les fonctionnalités qui concernent les réglages spécifiques à un utilisateur du terminal de communication 401 dans le réseau de communication PoC 308. Dans le cas de la détermination d'un Rject-List (ce que l'on appelle une liste rouge (Black List)), l'unité GM/PS-Client fonctionne comme une unité GM (Group Management)-Client. Dans le cas de l'activation de ISB, l'unité GM/PSClient fonctionne comme une unité PS (Presence)-Client.
Le serveur de participant PoC 305, le serveur de commande PoC 306 et le serveur GM 307 font partie d'un réseau de communication PoC 308 qui fournit le service de communication PoC à la première unité PoC-Client, la deuxième unité PoC-Client 302 et la troisième unité PoCClient 303.
En ce qui concerne la communication nécessaire avec le réseau de communication PoC 308, l'unité PoC-Client 401 et l'unité GM/PS-Client 402 accède à des piles de protocoles 403, par exemple à des piles de protocoles selon SIP (Session Initiation Protocol) ou le http (Hypertext Transfer Protocol). En outre, un modem 404 permet la communication avec le réseau de communication PoC 308.
Une application PoC 405 est installée sur le terminal de communication 400 qui règle l'interaction entre l'unité PoC-Client 401 et l'unité GM/PSClient 402, comme décrit ci-dessous. Dans le procédé fondé sur des terminaux, lequel est expliqué ci-dessous, l'application PoC 405 traite (détecte et évite) par exemple le conflit qui survient lorsque l'on utilise la fonctionnalité Call- Back, lorsque l'ISB est activé.
L'application PoC 405 reçoit des données d'utilisateur de l'utilisateur du terminal de communication 400 au moyen de l'interface utilisateur 406. Les lignes en pointillé 407 indique qu'une interaction directe entre l'unité PoC-Client 401 et l'unité GM/PS-Client 402 peut également se produire avec l'utilisateur au moyen de l'interface utilisateur 406. Notamment, toutes les interactions décrites dans la suite entre l'application PoC 405 et l'interface utilisateur 406 (respectivement l'utilisateur) peuvent également se produire entre l'unité PoC-Client 401 respectivement l'unité GM/PS 402 et l'interface utilisateur 406 (respectivement l'utilisateur).
Un procédé selon un exemple de réalisation de l'invention est expliqué dans la suite en se référant à la figure 5, lequel procédé est concrètement fondé sur des terminaux. Ceci présente notamment l'avantage qu'il n'est pas nécessaire d'implémenter de nouvelles fonctionnalités par rapport à des réseaux de communication PoC classiques dans le réseau de communication PoC 308. Notamment, aucune normalisation de la nouvelle fonctionnalité n'est nécessaire.
La figure 5 représente un organigramme 500 selon un 15 exemple de réalisation de l'invention.
On suppose que l'unité PoC-Client 401 transmet au serveur de participant PoC305 correspondant une message qui signale un Instant Personal Alert pour une autre unité PoC-Client. Concrètement, l'unité PoC-Client 401 (respectivement l'utilisateur correspondant) demande un rappel de l'autre unité PoC-Client (respectivement de l'utilisateur correspondant). À l'étape 501, on vérifie s'il apparaît un conflit car l'unité GM/PS-Client 402 a activé ISB et en conséquence des PoC-Calls, qui sont adressés à l'unité PoC-Client 401, doivent être fondamentalement rejetés ou bien l'autre unité PoC-Client (ou son utilisateur) se trouve sur une liste rouge (Black List, Reject List) définie par l'utilisateur du terminal de communication 400 au moyen de l'unité GM/PS-Client 402, et en conséquence des PoC-Clients, qui sont établis par l'autre unité PoC-Client et qui sont adressés à l'unité PoC-Client 401, seront rejetés.
La détection de conflit, c'est-à-dire la vérification de la présence d'un conflit, peut être effectuée par le système de communication PoC 308 ou par l'application PoC 405 elle-même. Si la détection de conflit est effectuée par le système de communication
PoC 308, le serveur de participant PoC 305 correspondant vérifie alors, après la réception de l'Instant Personal Alert par le client PoCClient 401, si un conflit est apparu. Ceci est possible car le serveur de participant PoC 305 peut être informé au moyen du serveur GM/PS 307 si l'ISB destiné à l'unité PoC-Client 401 est actuellement activé (c'est-àdire si l'unité GM/PS-Client 402 a activé l'ISB) ou si l'autre unité PoCClient se trouve sur une liste rouge définie par l'unité GM/PS-Client 402 (et transmise de façon appropriée au serveur GM/PS 307).
Si le serveur de participant PoC 305 détecte la survenance d'un conflit, il envoie alors un message d'erreur correspondant à la première unité PoCClient 401. La première unité PoC-Client 401 informe ensuite l'application PoC 405 de la survenance d'un conflit.
Si la détection de conflit est effectuée par le terminal de communication 400 lui-même, l'application PoC 405 vérifie alors les réglages actuels, c'est-à-dire si l'ISB est activé ou si une liste rouge est définie lorsque l'utilisateur souhaite envoyer un Instant Personal Alert, et peut alors déterminer si un conflit apparaît. L'unité GM/PS-Client 402 peut interroger l'application PoC 405 sur les réglages actuels ou bien ceux-ci sont signalés à ladite application par l'unité GM/PS-Client 402.
Indépendamment du fait que la détection de conflit soit réalisée par le réseau de communication PoC 308 ou par l'application PoC 405, l'application PoC 405 est informée à la fin de l'étape 501 de la survenance d'un conflit. On suppose dans la suite qu'un conflit apparaît.
À l'étape 502, l'application PoC 405 signale à l'utilisateur du terminal de communication 400 la présence d'un conflit et propose à l'utilisateur une période, ou offre à l'utilisateur la possibilité de choisir une période, pendant laquelle le blocage, c'est-à-dire le rejet automatique, de PoC-Calls qui. sont adressés à l'unité poC-Client 401 et qui sont initialisés par l'autre unité PoC-Client, doit être supprimé, c'est-àdire arrêté. Dans ce cas, on suppose que l'utilisateur confirme cela à l'application 405 et choisit une période correspondante.
À l'étape 503, l'application PoC 405 modifie au moyen de l'unité GM/PS 402 et les réglages valables pour l'unité PoC-Client 401 (c'est-à-dire l'état d'activation de ISB et/ou la liste rouge) dans le serveur GM/PS 307. La modification des réglages est expliquée plus précisément dans la suite en se référant à un exemple. Le serveur de participant PoC 305 est automatiquement informé par le serveur GM/PS 307 que les réglages ont été modifiés. La modification des réglages peut se faire de façon classique ou bien il est signalé en plus des valeurs de paramètres qui spécifient combien de temps les réglages modifiés seront valables avant le retour aux réglages précédents.
Le procédé selon l'exemple de réalisation est fondé sur des terminaux en ce sens que la modification des réglages est effectuée par l'application PoC 405, donc par le terminal de communication 400.
À l'étape 504, il est maintenant signalé l'Instant Personal Alert planifié. Ceci est effectué en transmettant un message correspondant de l'application PoC 405 au serveur de participant PoC par le biais de l'unité PoC-Client 401. Puis, le message est transmis à l'autre unité PoCClient.
À l'étape 505, l'unité PoC-Client 401 peut maintenant être jointe par l'autre unité PoC-Client, c'est-à-dire que l'autre unité PoC-Oient peut adresser à l'unité PoC-Client 401 des PoC-Calls sans que ceux-ci soient bloqués.
A l'étape 506, on effectue la modification des réglages, c'est-à-dire que l'on retourne aux réglages d'origine. Ceci peut être effectué suivant deux variantes en fonction de l'étape 503. Si le terminal de communication 400 a signalé à l'étape 503 la modification de façon classique, l'application PoC 405 reprend de façon classique, à la fin de la période déterminée à l'étape 502 ou après que l'autre unité PoC-Client a effectué le rappel, les modifications des réglages par le biais de l'unité GM/PS-Client 402 par une signalisation correspondante au réseau de communication moyenne 308.
Si le terminal de communication 400 signale à l'étape 503 des valeurs de paramètre qui spécifient le moment où l'on retourne aux réglages d'origine, on retourne aux réglages d'origine du côté du réseau de communication PoC 308 à l'instant spécifié par les valeurs de paramètre signalées.
Un exemple du procédé, expliqué en se référant à la figure 5, est expliqué dans la suite en se référant à la 25 figure 6.
La figure 6 représente un schéma de flux de messages 600 selon un exemple de réalisation de l'invention.
Le flux de messages représenté est généré entre une unité GM-Client 601, une première unité PoC-Client 602, un serveur de participant PoC 603, un serveur GM 604 et une deuxième unité PoC-Client 605 qui sont disposés conformément à la figure 3 et à la figure 4, l'unité GM-Client 601 correspondant à l'unité GM/PS-Client 402 et la première unité PoC-Client 602 correspondant à l'unité PoC-Client 401. Étant donné que l'on utilise dans cet exemple une liste rouge (Black List), cela concerne le serveur GM 604 qui correspond au serveur GM/PS 307 (de façon analogue, cela concerne pour cette raison l'unité GM 601).
À l'étape 606, l'utilisateur du terminal de communication, qui réalise l'unité GM-Client 601 et la première unité PoC-Client 602, dresse une liste rouge (Black List) par le biais de son unité GM-Client 601 en envoyant un premier message http PUT 617 dans le serveur GM 604 qui lui est associé. La liste rouge est donc connue aussi bien du serveur GM 604 que de l'unité GM-Client 601. En outre, à l'étape 601, le serveur de participant PoC 603, qui est responsable de l'utilisateur, est informé par le serveur GM 604, par le biais d'un premier message NOTIFY 618, de la liste rouge. Le premier message NOTIFY 618 est conformé par exemple selon SIP NOTIFY, par exemple comme décrit dans le document [5].
La liste rouge a la fonctionnalité de bloquer déjà dans le serveur de participant PoC 603 tous les PoCCalls, qui sont adressés à la première unité PoC-Client 602, et qui ont été générés par des utilisateurs (respectivement les unité PoC-Client utilisés par ces utilisateurs) qui se trouvent sur la liste rouge, c'est-à-dire que le serveur de participant PoC 603 ne transmettent pas ces PoC-Calls à la première unité PoCClient 602. L'utilisateur de la première unité PoC-Client 602 n'a donc aucune connaissance de ces PoC-Calls entrants. Les utilisateurs, qui sont dans cet exemple sur la liste rouge, sont l'utilisateur de la deuxième unité PoC-Client 605 ( User B ) et un autre utilisateur ( User C ).
À l'étape 608, l'utilisateur de la première unité PoC-Client 602 souhaite envoyer, par le biais de l'application 405, un Instant Personal Alert à l'utilisateur de la deuxième unité PoC-Client 605. Avant d'envoyer l'Instant Personal Alert à l'utilisateur de la deuxième unité PoC-Client 605, l'application PoC 405 demande auprès de l'unité GM-Client 601 (qui est réalisée comme expliqué dans ce cas également par le terminal de communication 400) quels utilisateurs se trouvent sur la liste rouge spécifiée par l'utilisateur de la première unité PoC-Client.
Cette information permet à l'application PoC 405 de détecter qu'il serait judicieux d'envoyer un Instant Personal Alert lors des réglages d'utilisateur actuels de l'utilisateur de la première unité PoC-Client 602 (c'est-à-dire la liste rouge actuellement spécifiée), car la tentative de l'utilisateur de la deuxième unité PoCClient 605 d'effectuer un rappel en réaction à l'Instant Personal Alert, c'est-à-dire de tenter de joindre l'utilisateur de la première unité PoC-Client 602 par le biais de PoC, serait bloquée par le réseau de communication PoC 308 (concrètement le serveur de participant PoC 603).
L'application PoC-Client 405 signale ce conflit à l'utilisateur de la première unité PoC-Client 602 et propose à l'utilisateur une période de 30 minutes (dans cet exemple) pendant laquelle le blocage de PoC-Calls entrants sera supprimé par l'utilisateur de la deuxième unité PoC-Client 605 (c'est-à-dire les PoC-Calls qui ont été générés par l'utilisateur de la deuxième unité PoCClient 605). L'utilisateur de la première unité PoCClient 602 modifie la période, par exemple 60 minutes, et le confirme à l'application PoC 405.
En conséquence,l'application PoC 405 demande à l'unité GM-Client 601 d'effacer l'utilisateur de la deuxième unité PoC 403 de la liste rouge. L'unité GM-Client 601 le fait à l'étape 609 de façon appropriée en transmettant un deuxième message HTTP PUT 619 au serveur GM 604. Le serveur GM 604 informe le serveur de participant PoC 603 à l'étape 610 de la modification de la liste rouge qui ne contient plus maintenant que l'autre utilisateur User C , par un deuxième message NOTIFY 620 (selon SIP NOTIFY). En outre, l'application PoC 405 démarre une minuterie à 60 minutes.
Dans une variante expliquée en se référant à la figure 5, l'unité GMClient 601 réalise dans un autre mode de réalisation une action, qui est nouvelle par rapport à l'état de la technique, auprès du serveur GM 604 en transmettant à l'étape 609 au serveur GM 604 un paramètre qui spécifie que l'utilisateur de la deuxième unité PoC-Client 605 sera effacé de la liste rouge pendant 60 minutes. En conséquence, l'effacement sera de nouveau effectué au bout de 60 minutes par le serveur GM 604 (cette variante de réalisation n'est pas représentée dans la figure 6).
À l'étape 611, la première unité PoC-Client 602 envoie l'Instant Personal Alert, prévu pour l'utilisateur de la deuxième unité PoC-Client 605, par le biais d'un premier message MESSAGE 621 (conformé par exemple selon SIP MESSAGE) au serveur de participant PoC 603. Le serveur de participant PoC 603 transmet l'Instant Personal Alert à la deuxième unité PoC-Client 605 par le biais d'un deuxième message MESSAGE 622 selon SIP MESSAGE.
L'Instant Personal Alert peut comporter en plus des Instant Personal Alert classiques un paramètre qui spécifie la période de validité de l'Instant Personal Alert à 60 minutes. Ceci est indiqué dans la figure 6 dans le premier message MESSAGE 621 et le deuxième message MESSAGE 622 par < time-limit: 60min . Dans ce cas, la deuxième unité PoC-Client 605 est informée de la limitation dans le temps de la possibilité d'effectuer un rappel conformément au Instant Personal Alert (et ceci peut être indiqué à l'utilisateur de la deuxième unité PoC-Client 605.
A l'étape 613, l'utilisateur de la deuxième unité PoC-Client a la possibilité pendant 60 minutes de joindre l'utilisateur de la première unité PoC-Client par le biais de PoC.
À l'étape 614 (la suivante n'est pas réalisée dans la variante de réalisation susmentionnée), l'application PoC 405 demande au bout de 60 minutes à l'unité GM-Client 601 de mettre l'utilisateur de la deuxième unité PoCClient 605 sur la liste rouge. À l'étape 615, l'unité GM-Client 601 effectue cette action en transmettant un deuxième message http-Put 623 au serveur GM 604. À l'étape 616, le serveur GM 604 informe le serveur de participant PoC 603 de cette nouvelle modification par un troisième message NOTIFY 624 (selon SIP NOTIFY). La liste rouge comporte maintenant l'utilisateur de la deuxième unité PoC-Client 605 User B et l'autre utilisateur User C . Ainsi, au bout des 60 minutes (de la période de validité), un PoC-Call, adressé par l'utilisateur de la deuxième unité PoC-Client 605 à l'utilisateur de la première unité PoC- Client 602, est de nouveau bloqué.
Des procédés selon d'autres modes de réalisation, qui sont concrètement des procédés fondés sur des réseaux, sont expliqués dans la suite en se référant à la figure 7, la figure 8, la figure 9 et la figure 10. L'exemple de réalisation, expliqué en se référant à la figure 7 et la figure 8, présente l'avantage d'utiliser un Instant Personal Alert se présentant sous une forme déjà normalisée. Ainsi, dans cet exemple de réalisation, il y a une compatibilité avec des réseaux de communication PoC déjà existants. Dans le mode de réalisation expliqué en se référant à la figure 9 et la figure 10, l'Instant Personal Alert est augmenté d'un paramètre qui spécifie que le blocage de Calls est supprimer par l'utilisateur concerné par l'Instant Personal Alert et qui spécifie une période de validité de cette suppression du blocage.
La figure 7 représente un organigramme 700 selon un exemple de réalisation de l'invention.
L'idée à la base du procédé expliqué dans la suite est que le serveur de participant PoC 305 détermine un conflit et demande auprès du terminal de communication 400, qui constitue la première unité PoC-Client 301, si le serveur de participant PoC 305 bénéficiera d'une exception de réglages d'utilisateur actuels pour un utilisateur auquel un Instant Personal Alert sera transmis.
On suppose que l'unité PoC-Client 301 transmet (selon le souhait de l'utilisateur de la première unité PoC-Client 301) un Instant Personal Alert qui est adressé à un autre utilisateur (respectivement l'unité PoCClient utilisée par l'autre utilisateur).
À l'étape 701, une détection de conflit est effectuée dans le réseau de communication PoC 308. Étant donné que le serveur de participant PoC 305 connaît les réglages d'utilisateur instantanés (ISB et/ou liste rouge) grâce au serveur GM/PS 307, il vérifie après réception de l'Instant Personal Alert provenant de la première unité PoC-Client 306 si un conflit apparaît. Si c'est le cas, on passe à l'étape 702.
Dans ce cas, on suppose qu'un conflit apparaît, c'est-à-dire que l'autre utilisateur, auquel l'Instant Personal Alert est adressé, se trouve sur une liste rouge spécifiée par la première unité 301, ou l'ISB destiné à la première unité PoC-Client 301 est activé.
A l'étape 702, le serveur de participant PoC 305 transmet un message Info à la première unité PoC-Client 301 pour l'informer du présent conflit. En outre, le serveur de participant PoC 305 propose par le message Info de supprimer pour une période déterminée la règle de blocage pour l'autre utilisateur, c'est-à-dire le réglage consistant à bloquer des PoC-Calls générés par l'autre utilisateur et adressés à l'utilisateur de la première unité PoC-Client 301. L'unité PoC-Client 301 en informe l'application PoC 405 de façon appropriée.
A l'étape 703, il est effectué une requête d'utilisateur (Requête User) relative à une exception provisoire (de réglages d'utilisateur actuellement valables). L'application PoC 405 demande à l'utilisateur s'il est d'accord de supprimer la règle de blocage pour l'autre utilisateur pendant une période déterminée. Si l'utilisateur est d'accord, il peut également choisir une période autre que la période proposée.
A l'étape 704, l'application PoC 405 informe l'unité PoC-Client 301 de la réaction de l'utilisateur. Par conséquent, l'unité PoC-Client 301 transmet un message de réponse Info au serveur de participant PoC 305 qui contient, en fonction de l'étape 703, la spécification d'une période choisie par l'utilisateur.
A l'étape 705, l'exception est réalisée de façon appropriée, c'est-à-dire que le serveur de participant PoC 305 modifie (efface) la règle de blocage pour l'autre utilisateur. En outre, l'Instant Personal Alert est transmis à l'unité PoC-Client utilisée par l'autre utilisateur.
En option, à l'étape 706, il est effectué une modification des réglages d'utilisateur dans le réseau de communication PoC 308. Le serveur de participant PoC 305 modifie alors les réglages d'utilisateur (état d'activation de l'ISB et/ou la liste rouge) dans le serveur GM/PS 305 pour la période pour laquelle la règle de blocage pour l'autre utilisateur sera supprimée. Ceci peut se faire grâce au serveur de participant PoC 305 qui modifie le réglage d'utilisateur et qui reprend cette modification à la fin de la période ou grâce au serveur de participant PoC 305 qui modifie les réglages d'utilisateur dans le serveur GM/PS 307 puis signale au serveur GM/PS 307 la période au bout de laquelle le serveur GM/PS 307 reprend automatiquement la modification.
En option, à l'étape 706, l'exception de la règle de blocage pour l'autre utilisateur n'est valable que pour le service de communication PoC (Instant Personal Alert est une caractéristique du service de communication PoC) et le serveur de participant PoC 305 lui-même est informé de l'exception de la règle de blocage et, pour cette raison, les réglages d'utilisateur n'ont pas nécessairement besoin d'être modifiés de façon explicite dans le serveur GM/PS 305.
A l'étape 707, l'unité PoC-Client utilisée par l'autre utilisateur peut joindre la première unité PoCClient 301 sans que le serveur de participant PoC 305 bloque les PoC-Calls qui sont générés par l'autre utilisateur (respectivement son unité PoC-Client) et qui sont adressés à la première unité PoC-Client 301.
A l'étape 708, l'exception est supprimée. Ceci est effectué par exemple lorsque que la période s'est écoulée ou lorsqu'un rappel est effectué. La suppression de l'exception est réalisée, selon le mode de réalisation, par le serveur de participant PoC 305 ou par le serveur GM/PS 307, comme expliqué ci-dessus.
Il est décrit dans la suite, en se référant à la figure 8, un exemple du procédé expliqué en se référant à la figure V. La figure 8 représente un schéma de flux de message 800 selon un exemple de réalisation de l'invention.
Étant donné que l'on utilise ISB dans cet exemple, l'unité PS-Client 801, qui correspond à l'unité GM/PSClient 402, et un serveur PS 804, qui correspond au serveur GM/PS 307, participent au flux de messages représenté. En outre, une première unité PoC-Client 802, qui correspond à l'unité PoC-Client 401 (et donc à la première unité PoC-Client 301), un serveur de participant PoC 803, qui correspond au serveur de participant PoC correspondant 305, et une deuxième unité PoC-Client 805, qui correspond à la deuxième unité PoC-Client 302, participent au flux de message représenté.
À l'étape 806, la première unité PoC-Client 802 active ISB au moyen de l'unité PS-Client 801 qui lui est associée en transmettant un message PUBLISH 817 (par exemple selon SIP PUBLISH, voir le document [2]) au serveur PS 807 par le biais de l'unité PS-Client 801. En conséquence, ISB est activé pour la première unité PoCClient 802 dans le serveur PS 804. À l'étape 807, le serveur PS 804 informe le serveur de participant PoC 803, au moyen d'un message NOTIFY 818 (selon SIP NOTIFY), que 1'ISB est activé pour la première unité PoC-Client. Tant que l'ISB est activé pour la première unité poC-Client 802, tous les PoC-Calls, adressés à la première unité PoC-Client 802, sont bloqués par le serveur de participant PoC 803.
À l'étape 808, l'utilisateur de la première unité PoC-Client 802 ordonne d'envoyer un Instant Personal Alert à l'utilisateur de la deuxième unité PoC-Client 805 ( User B ). Pour cela, l'utilisateur de la première unité PoC-Client 802 envoie à l'étape 809, au serveur de participant PoC 803, à l'aide de l'application Po( 405 et de la première unité PoC-Client 802, un Instant Personal Alert pour l'utilisateur de la deuxième unité PoC-Client 805 par le biais d'un premier message MESSAGE 819 (selon SIP MESSAGE).
À l'étape 810, le serveur de participant PoC 803, qui est informé, grâce au message NOTIFY 818, que l'ISB est activé pour la première unité PoCClient 802, détecte la survenance d'un conflit après la réception de l'Instant Personal Alert (c'est-à-dire après la réception du premier message MESSAGE 819).
Si l'ISB n'était pas activé pour la première unité PoC-Client 802, mais qu'un Reject-List (liste rouge) était défini qui contient l'utilisateur de la deuxième unité PoC-Client 805, le serveur de participant PoC 803 détecterait le conflit correspondant en comparant les entrées de la liste rouge avec le récepteur prévu de l'Instant Personal Alert.
S'il a détecté un conflit, le serveur de participant PoC 803 envoie à la première unité PoC-Client 802 un message Info, sous la forme d'un deuxième message MESSAGE 820 (selon SIP MESSAGE), au moyen duquel il informe la première unité PoC-Client 802 du conflit (dans la figure 8, c'est indiqué par Alert Conflict: ISB ). En outre, le serveur de participant PoC 803 propose, par le biais du deuxième message MESSAGE 820, par exemple de supprimer la règle de blocage de l'utilisateur de la deuxième unité PoC-Client 805 pendant 30 minutes, c'est-à-dire que des PoC-Calls, générés par l'utilisateur de la deuxième unité PoC-Client 805 et adressés à la première unité PoC-Client 802, ne peuvent pas être bloqués par le serveur de participant PoC 803 pendant une durée de 30 minutes (ceci est indiqué dans la figure 8 par proposed-resolution: ISB suspension for User B; proposed-time-limit: 30 min ).
Ensuite, la première unité PoC-Client 802 informe de façon appropriée l'application PoC 405 du conflit et de la proposition. Dans ce cas, on suppose que l'utilisateur de la première unité PoC-Client 802 accepte la proposition. En conséquence, l'application PoC 405 donne, par le biais de la première unité PoC-Client 802 et d'un quatrième message MESSAGE 821 (selon SIP MESSAGE), à l'étape 812, une réponse positive qui signale que la proposition est acceptée.
A l'étape 813, le serveur de participant PoC 803 délivre ensuite une exception de blocage de l'utilisateur de la deuxième unité PoC-Client 805, c'est-à-dire supprime la règle de blocage de l'utilisateur de la deuxième unité PoC-Client 805 et démarre une minuterie de 30 minutes à l'étape 813.
En outre, à l'étape 814, l'Instant Personal Alert est transmis par le biais d'un cinquième message MESSAGE 822 (selon SIP MESSAGE) à la deuxième unité PoC-Client 805.
A l'étape 815, l'utilisateur de la deuxième unité PoC-Client 805 a maintenant la possibilité de joindre l'utilisateur de la première unité PoC-Client 802 par le biais de PoC, c'est-à-dire de transmettre avec succès un PoC-Call à la première unité PoC-Client 802.
A l'étape 816, au bout de 30 minutes, l'exception de blocage de l'utilisateur de la deuxième unité PoC-Client est de nouveau supprimée dans le serveur de participant PoC 803, c'est-à-dire que des PoC-Calls, qui sont générés par l'utilisateur de la deuxième unité PoC-Client et qui sont adressés à la première unité PoC-Client 802, sont de nouveau bloqués par le serveur de participant PoC 803.
Un autre procédé, concrètement fondé sur des réseaux, est expliqué dans la suite en se référant la figure 9.
La figure 9 représente un organigramme 900 selon un exemple de réalisation de l'invention.
L'idée à la base du procédé expliqué dans la suite est que, lors de l'émission d'un Instant Personal Alert, le terminal de communication signale en plus un paramètre qui commande le serveur de participant PoC de générer une exception dans le cas d'un conflit sans rappel auprès de l'unité PoC-Client correspondante.
En option, à l'étape 901, une détection de conflit est réalisé dans le terminal de communication 400. Étant donné que l'application PoC 405 a connaissance des réglages d'utilisateur provisoires (ISB et/ou liste rouge) par le biais de l'unité GM/PS-Client 402, elle peut vérifier à chaque Instant Personal Alert que pourrait envoyer un utilisateur du terminal de communication, si un conflit apparaît. Si c'est le cas, ce que l'on suppose dans la suite, le processus passe à l'étape 902.
A l'étape 902, une requête User est réalisée pour un réglage d'exception provisoire. Avant que le terminal de communication 400 n'envoie l'Instant Personal Alert, l'application PoC 405 demande à l'utilisateur du terminal de communication 400 si un rappel doit être effectué à chaque fois (c'està-dire ne doit pas être bloqué) et pendant combien de temps une règle d'exception correspondante (exception de la règle de blocage) doit être valide. Étant donné que cette requête peut toujours être réalisée, donc indépendamment de la survenance d'un conflit, l'étape 901 est optionnelle.
L'Instant Personal Alert est envoyé à l'étape 903. Pour cela, l'unité PoCClient 400 envoie l'Instant Personal Alert au serveur de participant PoC correspondant 305, en signalant en plus qu'un rappel de l'autre utilisateur, auquel l'Instant Personal Alert est adressé, doit être effectué à chaque fois dans la période spécifiée à l'étape 902par l'utilisateur du terminal de communication 400 (on suppose ici que l'utilisateur a répondu de façon appropriée à la requête User à l'étape 902), indépendamment des réglages d'utilisateur du moment.
A l'étape 904, une détection de conflit est effectuée dans le réseau de communication PoC 308. Le serveur de participant PoC 305, qui a connaissance des réglages d'utilisateur actuels (ISB et/ou liste rouge) grâce au serveur GM/PS 305, vérifie après réception de l'Instant Personal Alert provenant de l'unité PoC-Client 401 si un conflit apparaît. Dans le cas où un conflit apparaît, on passe à l'étape 905. Dans le cas où aucun conflit n'apparaît, l'Instant Personal Alert est simplement transmis à un utilisateur correspondant. Les étapes 905 à 908 correspondent aux étapes 705 à 708; comme déjà mentionné, on suppose que l'on a signalé à l'étape 903 qu'un rappel doit être effectué à chaque fois dans la période spécifiée.
Un exemple du procédé expliqué en se référant à la figure 9 est décrit dans la suite en se référant à la 30 figure 10.
La figure 10 représente un schéma de flux de message 1000 selon un exemple de réalisation de l'invention.
De façon analogue au flux de message représenté dans la figure 8, le flux de message représenté dans la figure est situé entre une unité PS-Client 1001, une première unité PoC-Client 1002, un serveur de participant PoC 1003, un serveur PS 1004 et une deuxième unité PoC-Client 1005. De façon analogue à l'étape 806 dans la figure 8, la première unité PoC-Client 1002 active ISB à l'étape 2006 par le biais d'un message PUBLISH 1017, ce dont le serveur PS 1004 informe à l'étape 2007, analogue à l'étape 807, le serveur de participant PoC 1003 par le biais d'un message NOTIFY 1018.
A l'étape 1008, l'utilisateur de la première unité PoC-Client 1002 souhaite envoyer, par le biais de l'application PoC 405, un Instant Personal Alert à l'utilisateur de la deuxième unité PoC-Client 1005. Ensuite, en option, l'application PoC 405 demande à l'unité PS 1001 les réglages d'utilisateur actuels. Dans ce cas, l'application PoC est donc informée par l'unité PS-Client 1001 de l'activation actuelle de ISB. L'application PoC 405 demande ensuite à l'utilisateur de la première unité PoC-Client 1002 si le rappel de l'utilisateur de la deuxième unité PoC-Client 1005 (comme demandé par:L'Instant Personal Alert) sera à chaque fois autorisé c'est-à-dire s'il ne sera pas bloqué (c'est-èdire que le PoC-Call correspondant ne sera pas bloqué), bien que ISB soit activé. (De façon analogue, on traite le cas où l'utilisateur de la deuxième unité PoC-Client 1005 se trouve sur une liste rouge qui est définie pour l'unité PoC-Client 1002). En outre, dans le cas où une exception de la règle de blocage de l'utilisateur de la deuxième unité PoC-Client 1005 doit être établie, car un appel doit être permis à chaque fois, l'application PoC 405 demande pendant combien de temps l'exception sera valable. À l'étape 1009, l'application PoC 405 envoie au serveur de participant PoC
1003, par l'intermédiaire de la première unité PoC-Client 1002, l'Instant Personal Alert souhaité pour l'utilisateur de la deuxième unité PoC-Client 1005 au moyen d'un premier message MESSAGE 1019 (selon SIP MESSAGE) ; il est en outre signalé par le premier message MESSAGE 1019 que la règle de blocage (dans le cas d'un conflit) sera supprimée pendant 45 minutes. Ceci est indiqué dans la figure 10 par block-suspension: 45 min .
À l'étape 1010, le serveur de participant PoC 1003, qui est informé par le message NOTIFY 1018 que l'ISB est activé pour la première unité PoCClient 1002, détecte le conflit après réception de l'Instant Personal Alert. Dans le cas où ISB n'est pas activé, mais qu'une liste rouge est définie pour la première unité PoC-Client 1002 qui contient l'utilisateur de la deuxième unité PoC-Client 1005, le serveur de participant PoC 1003 détecte le conflit en comparant les entrées de la liste rouge avec le récepteur prévu de l'Instant Personal Alert.
Le serveur de participant PoC 1003 établit une exception de blocage (c'est-à-dire une exception de la règle de blocage) pour l'utilisateur de la deuxième unité PoC-Client 1005 et démarre une minuterie de 45 minutes. À l'étape 1011, l'Instant Personal Alert est ensuite transmis à la deuxième unité PoC-Client 1005 à l'aide d'un deuxième message MESSAGE 1020 (selon SIP MESSAGE) ; il est alors signalé que la règle de blocage est supprimée pendant 45 minutes (ce qui est indiqué dans la figure 10 par block-suspension: 45 min ).
À l'étape 2012, la réception de l'Instant Personal Alert est indiquée à l'utilisateur de la deuxième unité PoC-Client 1005. Dans ce cas, on suppose que l'utilisateur de la deuxième unité PoC-Client 1005 effectuera un rappel. En conséquence, la deuxième unité PoC-Client 1005 envoie au serveur de participant PoC 1003un premier message INVITE 1021 au moyen d'un serveur de participant PoC 305 (non représenté) associé à l'unité PoC-Client 1005. Le premier message INVITE 1021 est par exemple conformé selon SIP INVITE, cf. le document [4].
On suppose qu'au moment de la réception du premier message INVITE 1021 par le serveur de participant PoC 1003, les 45 minutes ne se sont pas encore écoulés et l'exception de blocage de l'utilisateur de la deuxième unité PoC-Client 1005 est toujours valide. Le serveur de participant PoC 1003 décide donc à l'étape 1014 de transmettre le premier message INVITE 1021, ce qui se fait à l'étape 1015 au moyen d'un deuxième message INVITE 1022 qui est transmis à la première unité PoC-Client 1002.
A l'étape 1014, on supprime l'exception de blocage de l'utilisateur de la deuxième unité PoC-Client 1005 en raison du rappel réussi, c'est-à-dire que des PoC-Calls, générés par la deuxième unité PoC-Client 1005 et adressés à la première unité PoC-Client 1002 sont de nouveau bloqués par le serveur de participant PoC 1003. Dans un autre mode de réalisation, l'exception de blocage n'est supprimée à l'étape 1016 que si les 45 minutes se sont écoulées.
Dans ce document, on a cité les publications suivantes: [1] Push to talk over ellular (PoC) ; List Management and Do-not-Disturb; Poc Release 2.0.
[2] RFC 3903 "Session Initiation Protocol (SIP) Extension for Event State Publication" [3] RFC 3428 "Session Initiation Protocol (SIP) 30 Extension for Instant Messaging" [4] RFC 3261 "SIP: Session Initiation Protocol" [5] RFC 3265 "Session Initiation Protocol (SIP)-Specific Event Notification" [6] US 6701160 Liste des references Schéma de flux de messages 101 Première unité PoC-Client 102 Serveur de participant PoC 103 Serveur de commande/de participant PoC 104 Deuxième unité PoC-Client à 112 Étapes de processus 113 à 116 Messages 200 Schéma de flux de messages 201 Première unité PoC-Client 202 Serveur de participant PoC 203 Serveur de commande/de participant PoC 204 Deuxième unité PoC-Client 205 à 218 Étapes de processus 219 à 222 Messages 300 Système de communication 301 à 303 Unités PoC-Client 304 Interface 305 Serveur de participant PoC 306 Serveur de commande PoC 307 Serveur GM/PS 308 Réseau de communication PoC 400 Terminal de communication 401 Unité PoC-Client 402 Unité GM/PS-Client 403 Piles de protocoles 404 Modem 405 Application PoC 406 Interface utilisateur 407 Lignes en pointillé Organigramme Étapes de processus 501 à 506 602 603 604 605 606 à 616 617 à 624 Unité GM-Client Première unité PoC-Client Unité de serveur PoC Serveur GM Deuxième unité PoC-Client Étapes de processus Messages Organigramme Étapes de processus 701 à 708 800 801 802 803 804 805 806 à 816 817 à 822 Schéma de flux de messages Unité PS-Client Première unité PoC-Client Serveur de participant PoC Serveur PS Deuxième unité PoC-Client Étapes de processus Messages Organigramme 901 à 908 Étapes de processus 1000 1001 1002 1003 1004 1005 1006 à 1016 Étapes de processus 1017 à 1022 Messages Schéma de flux de messages Unité PS-Client Première unité PoC-Client Unité de participant PoC Serveur PS Deuxième unité PoC-Client

Claims (12)

Revendications
1. Unité de serveur d'un système de communication, lequel système de communication comporte une première unité (101) de client et une deuxième unité (_04) de client, caractérisée en ce que - l'unité (103) de serveur est conçue pour décider si une invitation à une session de communication concernant la première unité (101) de client est transmise par la deuxième unité (104) de client, en se fondant sur une information de conflit qui est délivrée par l'unité (103) de serveur et qui spécifie s'il existe un conflit entre un premier message de demande envoyé par la première unité de client et un deuxième message de demande envoyé par la première unité de client, - le premier message de demande spécifiant qu'aucune invitation à des sessions de communication concernant la première unité de client, ne doit être transmise par la deuxième unité de client à la première unité de client et - le deuxième message de demande spécifiant que la deuxième unité de client invite la première unité de client à une session de communication.
2. Unité de serveur selon la revendication 1, caractérisée en ce qu'elle comporte un dispositif de réception d'information de conflit qui est conçu pour recevoir l'information de conflit de l'unité de client.
3. Unité de serveur selon la revendication 1, caractérisée en ce qu'elle comporte un dispositif de détermination qui est conçu pour déterminer l'information de conflit.
4. Unité de serveur selon l'une des revendications 1 à 3, caractérisée en ce qu'elle comporte un dispositif de réception d'information d'intervalle de temps qui est conçu pour recevoir la spécification d'un intervalle de temps de la part de la première unité de client, l'unité de serveur étant conçu, dans le cas d'un conflit entre le premier message de demande et le deuxième message de demande, pour décider que l'invitation à la session de communication concernant la première unité de client est transmise par la deuxième unité de client dans le cas où l'invitation a été envoyée dans l'intervalle de temps spécifié.
5. Unité de serveur selon l'une des revendications 1 à 4, caractérisée en ce que le deuxième message de demande spécifie que la deuxième unité de client doit établir une liaison de communication vocale, une liaison de communication de téléphonie vidéo ou une liaison de communication de message textuel avec la première unité de client.
6. Unité de serveur selon l'une des revendications 1 à 5, caractérisée en ce que le deuxième message de demande spécifie que la deuxième unité de client invite la première unité de client à une session de communication PoC.
7. Unité de serveur selon la revendication 6, caractérisée en ce que le premier message de demande signale un Incoming Session Barring.
8. Procédé d'exploitation d'une unité de serveur d'un système de communication, lequel système de communication comporte une première unité de client et une deuxième unité de client, caractérisé en ce que: l'unité de serveur est conçue pour décider si une invitation à une session de communication concernant la première unité de client est transmise par la deuxième unité de client, concernant la première unité de client est transmise par la deuxième unité de client, en se fondant sur une information de conflit qui est délivrée par l'unité de serveur et qui spécifie s'il existe un conflit entre un premier message de demande envoyé par la première unité de client et un deuxième message de demande envoyé par la première unité de client, - le premier message de demande spécifiant qu'aucune invitation à des sessions de communication concernant la première unité de client, ne doit être transmise par la deuxième unité de client à la première unité de client et - le deuxième message de demande spécifiant que la deuxième unité de client invite la première unité de client à une session de communication.
9. Unité de client d'un système de communication, caractérisé lequel système de communication comporte une autre unité de client, caractérisée en ce que l'unité de client est conçue - pour envoyer un premier message de demande qui spécifie qu'aucune invitation à des sessions de communication concernant la première unité de client ne doit être envoyée à la première unité de client par l'autre unité de client; -pour envoyer un deuxième message de demande qui 20 spécifie que l'autre unité de client invite la première unité de client une session de communication; - pour déterminer une information de conflit qui spécifie s'il existe un conflit entre le premier message de demande et le deuxième message de demande.
10. Unité de client selon la revendication 9, caractérisée en ce qu'elle est conçue pour transmettre l'information de conflit à une unité de serveur du système de communication.
11. Unité de client selon la revendication 9, caractérisée en ce qu'elle qui est conçue pour décider, en se fondant sur l'information de conflit, si une invitation à une session de communication concernant la première unité de client est transmise par l'autre unité de client à la première unité de client et pour signaler le résultat de la décision à l'unité de serveur.
12. Procédé d'exploitation d'une unité de client d'un système de communication, lequel système de communication comporte une autre unité de client,caractérisé en ce que l'unité de client - envoie un premier message de demande qui spécifie qu'aucune invitation à des sessions de communication concernant la première unité de client n'est transmise par l'autre unité de client à la première unité de client; -envoie un deuxième message de demande qui spécifie que l'autre unité de client invite la première unité de client à une session de communication; - détermine une information de conflit qui spécifie s'il existe un conflit entre le premier message de demande et le deuxième message de demande.
FR0606285A 2005-07-11 2006-07-11 Unite de serveur, unite de client, procede d'exploitation d'une unite de serveur et procede d'exploitation d'une unite de client Expired - Fee Related FR2890270B1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102005032302A DE102005032302A1 (de) 2005-07-11 2005-07-11 Server-Einheit, Client-Einheit, Verfahren zum Betreiben einer Server-Einheit und Verfahren zum Betreiben einer Client-Einheit

Publications (2)

Publication Number Publication Date
FR2890270A1 true FR2890270A1 (fr) 2007-03-02
FR2890270B1 FR2890270B1 (fr) 2011-08-05

Family

ID=37575388

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0606285A Expired - Fee Related FR2890270B1 (fr) 2005-07-11 2006-07-11 Unite de serveur, unite de client, procede d'exploitation d'une unite de serveur et procede d'exploitation d'une unite de client

Country Status (4)

Country Link
US (1) US20070027993A1 (fr)
CN (1) CN100574507C (fr)
DE (1) DE102005032302A1 (fr)
FR (1) FR2890270B1 (fr)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100656485B1 (ko) 2006-02-13 2006-12-11 삼성전자주식회사 Ｐｔａ 서비스 제공 방법 및 그 시스템
US20080214141A1 (en) * 2007-03-01 2008-09-04 Ian Benjamin Burdick System and method for allowing callback on an emergency call
US8355396B1 (en) * 2007-11-01 2013-01-15 Sprint Communications Company L.P. Customized network congestion messaging for terminal adapters
US8671202B2 (en) 2007-12-20 2014-03-11 Ooma, Inc. Mechanisms for role negotiation in the establishment of secure communication channels in peer-to-peer environments
US20090276537A1 (en) * 2007-12-20 2009-11-05 Deverick James W Mechanisms for role negotiation in the establishment of secure communication channels in peer-to-peer environments
JP5381086B2 (ja) * 2008-10-06 2014-01-08 日本電気株式会社 通信システム及び通信制御方法
JP2010114870A (ja) * 2008-10-06 2010-05-20 Nec Corp 通信システム及び通信制御方法
JP5381087B2 (ja) * 2008-10-06 2014-01-08 日本電気株式会社 通信システム及び通信制御方法
WO2017057962A1 (fr) * 2015-10-01 2017-04-06 Samsung Electronics Co., Ltd. Procédé et appareil destinés à la gestion d'un service de mcptt
CN109391593B (zh) * 2017-08-08 2022-04-19 展讯通信（上海）有限公司 用于媒体会话的重试时间确定方法及装置、存储介质、终端

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4278844A (en) * 1979-03-26 1981-07-14 Bell Telephone Laboratories, Incorporated Communication system selective call screening arrangement
EP0605106A1 (fr) * 1992-12-03 1994-07-06 Data Security, Inc. Système de sécurité pour ordinateurs pour appliquer une ligne de conduite
US6011909A (en) * 1997-01-06 2000-01-04 Motorola, Inc. Alerting user engaged in a first communications session on a first network to a request to establish a second communications session on a second network
US6249674B1 (en) * 1998-12-16 2001-06-19 Nortel Networks Limited Emergency disablement of termination restrictions
US6701160B1 (en) * 2000-05-22 2004-03-02 Motorola, Inc. Method and apparatus to locally block incoming selected calls
DE10235798B4 (de) * 2002-08-05 2004-09-23 Siemens Ag Verfahren und eine Vorrichtung zum Anmelden und Verbinden von R-Gesprächen mit intelligenten Netzwerkdiensten (IN-Diensten)
US7315518B1 (en) * 2002-09-05 2008-01-01 Art Technology Group, Inc. Method and apparatus for the prevention of unwanted calls in a callback system
DE602004008974T2 (de) * 2004-05-26 2008-06-19 Telefonaktiebolaget Lm Ericsson (Publ) Server und verfahren zur steuerung der verwaltung von gruppen
US20060026051A1 (en) * 2004-07-30 2006-02-02 Idx Investment Corporation System and method for directly scheduling health care patient appointments
FI20045298A0 (fi) * 2004-08-16 2004-08-16 Nokia Corp Mediapalvelun reititys
KR100666984B1 (ko) * 2004-09-24 2007-01-10 삼성전자주식회사 푸쉬 투 토크 오버 셀룰러 시스템 사용자의 응답 모드에따른 호 처리 시스템 및 방법
KR100677506B1 (ko) * 2004-10-23 2007-02-02 엘지전자 주식회사 Ｐｔｔ 서비스 예약 방법
US20060242279A1 (en) * 2005-04-25 2006-10-26 Bonnie Chen Methods of wireless data synchronization and supporting apparatus and readable medium
US8681751B2 (en) * 2005-07-11 2014-03-25 Nokia Corporation Method and apparatus for providing presence information in support of wireless communication services

Also Published As

Publication number Publication date
CN100574507C (zh) 2009-12-23
CN1897755A (zh) 2007-01-17
FR2890270B1 (fr) 2011-08-05
US20070027993A1 (en) 2007-02-01
DE102005032302A1 (de) 2007-01-25

Similar Documents

Publication Publication Date Title
FR2890270A1 (fr) Unite de serveur, unite de client, procede d&#39;exploitation d&#39;une unite de serveur et procede d&#39;exploitation d&#39;une unite de client
EP1856901B1 (fr) Procede et systeme d&#39;information des participants a une conversation telephonique
EP2381683A1 (fr) Procédé et système de gestion d&#39;une session de diffusion en continu d&#39;un flux vidéo affiché en direct
FR2877791A1 (fr) Procede de production et/ou de commande automatique d&#39;une conference de telecommunication avec une pluralite d&#39;abonnes terminal de conference de telecommunication et serveur de conference de telecommunication.
FR2890818A1 (fr) Serveur de teleconference, terminal de telecommunications, procede de generation d&#39;un message de commande de teleconference, procede de commande d&#39;une teleconference, supports de memorisation...
EP2310990A1 (fr) Procede d&#39;ajout automatique d&#39;une adresse dans un carnet d&#39;adresses
FR2877523A1 (fr) Procede de gestion informatisee d&#39;une teleconference et de serveurs de teleconferences.
EP1886514B1 (fr) Systeme et procede de telecommunication en mode ptt, module de gestion, serveur, terminal et programme pour ce systeme
EP3210369A1 (fr) Methode de filtrage de messages pour fournir une fonction de type &#34;ne pas deranger&#34;
FR2897453A1 (fr) Procede et dispositif de declenchement de transfert d&#39;activite(s) entre terminaux, a partir d&#39;evenements associes a des identifiants d&#39;utilisateurs
WO2012042150A1 (fr) Procédé de gestion de la priorité de flux média préliminaires
WO2008046697A1 (fr) Enrichissement de la signalisation dans une session de communication de type &#39; push to talk &#39; par insertion d&#39;une carte de visite
EP1578152A1 (fr) Procédé, serveur et système de gestion d&#39;une session &#34;push-to-talk&#34;
FR2889638A1 (fr) Terminal de telecommunications, systeme de telecommunications, unite de serveur de session de telecommunications, procede de generation et d&#39;emission d&#39;un message de session de telecommunications
EP3219090B1 (fr) Procédé et dispositif de communication
EP2923482B1 (fr) Service de communication voix a partir d&#39;un reseau social
EP2273774B1 (fr) Procédé de notification d&#39;une demande d&#39;établissement d&#39;appel
EP2100430B1 (fr) Procédé et système de télécommunication permettant à au moins deux utilisateurs distincts d&#39;accéder à un meme ensemble d&#39;informations
EP1980130B1 (fr) Localisation et routage d&#39;un appel
WO2005062568A1 (fr) Procede et systeme de gestion dune session de transmission de donnees en flux continu et en temps reel
EP1936934A1 (fr) Procédé de diffusion d&#39;un flux depuis une plate-forme de service, produit programme d&#39;ordinateur et plate-forme de service correspondants
FR3080512A1 (fr) Procede et systeme de detection de coupures de communications mobiles et de retablissement automatique des communications.
EP2334033A1 (fr) Procédé et système de notification d&#39;un terminal appelant
FR2977436A1 (fr) Procede et dispositif de filtrage d&#39;appels
FR2904902A1 (fr) Procede et systeme d&#39;authentification d&#39;utilisateurs dans un reseau de communication

Legal Events

Date Code Title Description
TP Transmission of property

Owner name: INTEL MOBILE COMMUNICATIONS GMBH, DE

Effective date: 20120228

ST Notification of lapse

Effective date: 20150331