WO2008046697A1 - Enrichissement de la signalisation dans une session de communication de type ' push to talk ' par insertion d'une carte de visite - Google Patents

Enrichissement de la signalisation dans une session de communication de type ' push to talk ' par insertion d'une carte de visite Download PDF

Info

Publication number
WO2008046697A1
WO2008046697A1 PCT/EP2007/059499 EP2007059499W WO2008046697A1 WO 2008046697 A1 WO2008046697 A1 WO 2008046697A1 EP 2007059499 W EP2007059499 W EP 2007059499W WO 2008046697 A1 WO2008046697 A1 WO 2008046697A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication
signaling
business card
client
invitation
Prior art date
Application number
PCT/EP2007/059499
Other languages
English (en)
Inventor
Patrick Legrand
Johann Daigremont
Original Assignee
Alcatel Lucent
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 Alcatel Lucent filed Critical Alcatel Lucent
Priority to JP2009532746A priority Critical patent/JP2010507302A/ja
Publication of WO2008046697A1 publication Critical patent/WO2008046697A1/fr

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/10Push-to-Talk [PTT] or Push-On-Call services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/40Connection management for selective distribution or broadcast
    • H04W76/45Connection management for selective distribution or broadcast for Push-to-Talk [PTT] or Push-to-Talk over cellular [PoC] services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08Upper layer protocols
    • H04W80/10Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/4061Push-to services, e.g. push-to-talk or push-to-video

Definitions

  • the present invention relates to communication networks. More specifically, it relates to the invitation by a communication client of one or more other communication clients to establish a communication session, in particular of the type called "PoC" ("Push to talk over Cellular" in English).
  • PoC Push to talk over Cellular
  • Push to TaIk is a half duplex communication service that allows parties to communicate interactively but not simultaneously.
  • a command (button, key 7) of each client makes it possible to switch the client from a reception mode to a transmission mode and vice versa.
  • This service has been adapted for cellular communication networks and then referred to as PoC ("Push to talk over Cellular").
  • PoC Push to talk over Cellular
  • OMA Open Mobile
  • a client wishing to initiate a "PoC” type communication session transmits an invitation message to a PoC communication server.
  • This invitation message is a SIP request "Invite”.
  • This type of request is primarily specified in the Internet Engineering Task Force (IETF) RFC 3261, Session Initiation Protocol.
  • the invitation message contains the logical address URI ("Uniform Resource Identifier") of the client issuing the invitation, as well as the recipient customer (s) (that is to say that the issuer wishes to invite to the communication session "PoC").
  • URI Uniform Resource Identifier
  • PoC communication server One of the roles of the PoC communication server is to transmit the invitation received from the sending (or calling) client to the invited (or called) client or clients, thanks to the addresses contained in the invitation message.
  • the guest client is typically a mobile communication terminal, including cellular. It has a visualization means, usually a screen, on which information about the invitation can be displayed.
  • the communication client user can decide whether or not to accept the invitation.
  • the specifications of the OMA do not specify the information conveyed by the invitation messages.
  • the SIP protocol specifies a set of headings. These headers make it possible to transmit the logical address (URI) of the calling client.
  • the guest communication client can therefore display this logical address on its screen.
  • the user corresponding to this logical address is known to the called user, it can be part of a directory and information contained in this directory can be displayed in addition to or in place of the logical address.
  • caller ID caller information
  • a logical address may not be sufficient for the user to decide whether or not to accept the invitation to a communication session. Indeed, a logical address is not necessarily very legible (it does not necessarily correspond to the name of the user of the calling client).
  • the logical address is associated with information stored locally by the client, it is possible to implement it only in the case where the invitation message comes from a correspondent Already known. It does not apply to the case of a new correspondent, and in this case does not provide any information that aids the decision-making process of the called user.
  • the invention firstly relates to a communication client having:
  • a sound production circuit for producing a sound signal representative of data received on a downlink communication channel and a sound acquisition circuit for producing data intended to be transmitted over an upstream communication channel
  • a signaling interface capable of transmitting signaling messages over a signaling channel. Some of these signaling messages are intended to establish a communication session with one or more other communication clients,
  • a man-machine interface comprising means for controlling this signaling interface, and means for, when a "Push to TaIk" type communication session is established, to switch between a transmission mode in which the microphone is active and a reception mode in which the microphone is not active,
  • display means provided for displaying information based on data contained in some of the signaling messages received.
  • the communication client according to the invention is innovative in that:
  • the display means are able to display, in whole or in part, the business cards contained in the signaling messages received.
  • the signaling interface may be in accordance with the SIP protocol and provided for transmitting the business card in an "Invite" signaling message intended to establish the communication session with one or more other clients. Communication.
  • the business card can be inserted into an SDP part of the "Prompt" signaling message.
  • the business card may conform to the "vCard" format.
  • the memory provided for storing a business card may also be provided for storing a set of business cards, each associated with a user and a user profile, and the communication client has means for determining a business card. among this set before it is transmitted in a signaling message.
  • the subject of the invention is a signaling protocol for a mobile communication network, comprising an invitation signaling message intended to establish a "Push to TaIk" type communication session between a calling communication client and one or more clients. called communication.
  • This signaling message contains the logical address of the calling communication client and an address of the called communication client or clients.
  • the signaling protocol is novel in that the invitation signaling message further contains a business card associated with a user of the calling communication client.
  • the invitation signaling message is transmitted by the calling communication client to a communication server intended to transmit it to the communication client or clients called according to the address or addresses that 'it contains.
  • the signaling message may be a multi-party "Invite" message conforming to the SIP standardization and in which the business card is contained in a portion conforming to the SDP protocol.
  • this business card can conform to the vCard format.
  • the invention also relates to a software product containing a code for implementing the communication protocol according to the invention.
  • code may optionally be downloaded from an application server on the communication clients.
  • FIG. 1 schematizes a communication network making it possible to implement the invention.
  • Figure 2 schematically shows a signaling message according to the invention.
  • a communication client A can communicate with a mobile communication network N.
  • This mobile communication network is typically a cellular network of GSM, UMTS, CDMA, and so on. It can be a converged network with a mobile subnet and a fixed subnet, allowing both fixed and mobile communication clients to communicate together.
  • Such network can be compliant with the IMS architecture (Internet Multimedia S ⁇ bsystem) standardized by 3GPP and TISPAN.
  • the communication client N can communicate with one or more other communication clients B 7 C.
  • a communication terminal can be connected to the communication network by a rising channel, making it possible to transmit to the communication network N data (voice, video, etc.) originating from the user of the client. communication; a downstream channel for receiving data from the network (and indirectly generally from another communication client); and a signaling channel for bidirectional transmission of signaling messages between the communication client and the network N.
  • the communication clients are typically communication terminals having audio production and acquisition circuits allowing the establishment of communication session type "voice". They may or may have more advanced means such as screens, cameras, etc. allowing the establishment of multimedia communication session (video etc.).
  • the sound production circuit is typically a loudspeaker or headset for producing a sound signal representative of data received on the downlink communication channel.
  • the sound acquisition circuit is typically a microphone for producing data which is then transmitted to the communication network via the upstream communication channel.
  • the communication clients A, B, C also have signaling interfaces for sending and receiving signaling messages on the signaling channel connecting them to the communication network N.
  • Signaling interfaces may be SIP-compliant as defined in the Internet Engineering Task Force (IETF) RFC 3261 and possibly extensions to this SIP defined later by NETF or other standardization bodies.
  • IETF Internet Engineering Task Force
  • the communication client A In order to establish a "PoC" ("call to talk over cell”) communication session, the communication client A sends an invitation signal message Ml to the communication network N.
  • PoC "call to talk over cell”
  • the communication client A has a human-machine interface which comprises means for controlling the signaling interface and initiating the transmission of this invitation signaling message M1.
  • This human-machine interface is typically composed of a set of keys, possibly in addition to a touch screen, wheels etc. that allow the user to control and control the communication client. Through this human-machine interface, it can trigger the initiation of a communication session type "PoC".
  • This same man-machine interface also has means (keys, wheels, etc.) for, when a "Push to TaIk" communication session is established, to switch between a reception mode and a transmission mode.
  • the sound acquisition circuit In the receive mode, the sound acquisition circuit is not active.
  • the transmission mode In the transmission mode, generally, the sound production circuit is not active.
  • the invitation signaling message Ml can be transmitted to an SC communication server within the communication network.
  • This communication server is able to understand the content of the message of Ml invitation signaling and, depending on this content, to transmit it to the communication clients called B and C.
  • Figure 2 schematizes such an invitation signaling message according to the SIP protocol and the standard specifications of the OMA for a "PoC" service.
  • This invitation signaling message Ml is then an "INVITE" message defined by the RFC 3261 of NETF.
  • E S1P formed by a set of SIP stubborn.
  • These headers contain at least the logical address of the user of the communication client A. They also contain information allowing the routing of the invitation message to the communication server SC.
  • the "INVITE" signaling message also contains a part
  • the signaling message M1 also contains a P2 part, also conforming to this SDP protocol, as specified in the standardization documents mentioned above and issued by the OMA.
  • This P2 part contains the logical addresses of the guest communications clients.
  • the following code is an illustrative example of an SIP compliant invitation signaling message and OMA specification.
  • the first excerpt represents the headers E s , p of this invitation message.
  • the words in bold represent the keywords of the grammar of the SIP protocol and have been formatted only for the sake of readability.
  • invitation message Ml is a "multi-part” message, comprising several parts conforming to the SDP protocol (Pl and P2, as well as P3 which will be subsequently described).
  • Request-URI sip PoCConferenceFactoryURI .networkA.net P-Preferred-Identity: "PoC User A” ⁇ sip: PoC-
  • the PI part conforming to the SDP protocol, can be in the following form:
  • Part P2 also compliant with the SDP protocol, can be in the following form:
  • this part P2 contains the addresses of the called communication clients B, C ("sip: PoC-UserB@networkB.com” and "sip: PoC-UserC@networkC.com”).
  • the communication server SC is provided to transmit this invitation signal message Ml to the communication clients B and C according to the addresses ("sip: PoC-UserB@networkB.com” and "sip: PoC-UserC @ networkC .com ") contained in this message.
  • the message M1 is therefore duplicated in a message MI B sent to the communication client B and a message M1 c sent to the communication client C.
  • a part P3 is also inserted in the invitation signaling message M1 sent by the calling communication client A.
  • This part P3 contains a business card of the user. It can be stored previously in a memory provided for this purpose within the communication client. The communication client can then be provided to automatically insert this business card stored in the invitation signaling messages issued. Optionally, a confirmation from the user may be requested, or the automatic insertion may be the subject of a configuration option of this communication client.
  • the memory can store several business cards.
  • the determination of the business card to be transmitted can be performed automatically when the user logs in to the communication client ("login").
  • business cards can be provided and stored, corresponding to different profiles: for example, a business card, a private business card etc.
  • the communication client has means for determining a business card among all the stored business cards, prior to transmission in a signaling message Ml.
  • This business card can be in vCard format.
  • This vCard format has the merit of being widely used in emails and allows interoperability between invitation messages and emails as well as between applications and services using them.
  • vCard format (“Versitcard) is standardized in version 3.0 by IETF RFC 2425 and 2426, respectively entitled "A MIME Content-Type for Directory Information” and "vCard MIME Directory Profile”.
  • Other business card specifications are of course possible, while remaining within the scope of the invention.
  • the business card may contain various information relating to the user of the communication client: his name of use or patronymic, his email address, his physical address, telephone numbers, title and / or professional function, etc.
  • this part P3 which contains the business card can be as follows:
  • This part P3 contained in the signaling message Ml is maintained in the signaling messages MI and MI B c transmitted by the communication server SC respectively communication clients B and C.
  • the communication servers B and C have display means, including a screen.
  • the information contained in the map can be displayed, partially or totally, on this screen. They thus provide the user of the communication clients called additional information to decide whether to accept the invitation. Some information can be displayed automatically (caller names %), while others will be displayed only after a specific action of the user (addresses ). This separation may be dependent on the size of the display screen.
  • the user of the communication client B or C can thus be informed of his name, his company, his address and so on. and this information can inform him sufficiently for his decision-making. It can thus filter certain incoming calls, and possibly discard unsolicited invitations of the "spamming" type.
  • This business card received by a communication client may optionally be stored in a memory provided for this purpose, and be managed by an application type "address book". This storage and this application allow a user to manage these contacts and keep track of interlocutors.
  • the business cards can also be transmitted by other signaling messages than the invitation signaling messages.
  • signaling messages may be transmitted by a communication client called B to the calling communication client A and / or to the other communication client called C.
  • These signaling messages containing the business card of the user of the communication client B, allow the communication clients A and C to know this personal information and possibly store this business card among their contacts.

Landscapes

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

Abstract

Protocole de signalisation de type SIP pour réseau de communication mobile (N), comportant un message de signalisation d'invitation (Ml), 'INVITE', destiné à établir une session de communication de type 'Push to TaIk' entre un client de communication appelant (A) et un ou plusieurs clients de communication appelés (B, C) et contenant l'adresse logique du client de communication appelant et une adresse du ou des clients de communication appelés. Le protocole se caractérise en ce que le message de signalisation d'invitation (Ml) contient en outre une carte de visite associée à un utilisateur du client de communication appelant (A).

Description

Enrichissement de la signalisation dans une session de communication de type « Push to TaIk » par insertion d'une carte de visite
La présente invention est relative aux réseaux de communication. Plus précisément, elle concerne l'invitation par un client de communication d'un ou plusieurs autres clients de communication pour établir une session de communication, notamment de type dit « PoC » (« Push to talk over Cellular » en langue anglaise).
Le service « Push to TaIk » (PTT) est un service de communication de type « half duplex » qui permet à des parties de communiquer de façon interactive mais non simultanée. Une commande (bouton, touche...) de chaque client permet de commuter le client d'un mode de réception vers un mode d'émission et vice-versa.
Ce service a été adapté pour les réseaux cellulaires de communication et alors désigné par l'acronyme PoC (« Push to talk over Cellular » ; « Presser pour parler par réseau cellulaire »). Un tel service est promu actuellement par l'OMA (Open Mobile
Alliance). Il est par exemple décrit et spécifié dans les documents « Push to talk over Cellular (PoC) - Architecture » (OMA-AD_PoC-Vl_0-20060609-A), et « OMA PoC Control Plane » (OMA-TS-PoC-ControlPlane-Vl_0-20060609-A). Ces deux documents ont été publiés le 9 juin 2006.
Selon ces spécifications normalisées, un client voulant initier une session de communication de type « PoC » transmet un message d'invitation à un serveur de communication PoC. Ce message d'invitation est une requête SIP « Invite ». Ce type de requête est principalement spécifié dans le RFC 3261 de l'IETF (Internet Engineering Task Force) intitulé « Session Initiation Protocol ».
Le message d'invitation contient l'adresse logique dite URI (« Uniform Resource Identifier », en langue anglaise) du client émetteur de l'invitation, ainsi que du ou des clients destinataires (c'est-à-dire que l'émetteur souhaite inviter à la session de communication « PoC »).
Un des rôles du serveur de communication PoC est de transmettre l'invitation reçue du client émetteur (ou appelant) vers le ou les clients invités (ou appelés), grâce aux adresses contenues dans le message d'invitation.
Le client invité est typiquement un terminal de communication mobile, notamment cellulaire. Il dispose d'un moyen de visualisation, généralement un écran, sur lequel des informations relatives à l'invitation peuvent s'afficher.
En fonction de ces informations, l'utilisateur du client de communication peut décider d'accepter ou non l'invitation.
Les spécifications de l'OMA ne précisent guère les informations véhiculées par les messages d'invitation. Le protocole SIP spécifie un ensemble d'entêtés. Ces entêtes permettent de transmettre l'adresse logique (URI) du client appelant. Le client de communication invité peut donc afficher cette adresse logique sur son écran. Dans le cas où l'utilisateur correspondant à cette adresse logique est connu de l'utilisateur appelé, il peut faire partie d'un répertoire et des informations contenues dans ce répertoire peuvent être affichées en plus ou à la place de l'adresse logique. Une telle possibilité est par exemple décrite dans la demande de brevet US2005/0287997. Cet enseignement, extérieur aux travaux de normalisation de l'OMA, décrit une solution dans laquelle des informations relatives à l'appelant (« caller ID ») sont insérées dans les messages de signalisation et associées par le client de communication appelé avec un carnet d'adresses afin d'afficher des informations supplémentaires à l'utilisateur.
Toutefois, cet état de la technique n'est guère satisfaisant. Dans le premier cas, une adresse logique peut ne pas être suffisante pour l'utilisateur pour décider convenablement d'accepter ou non l'invitation à une session de communication. En effet, une adresse logique n'est pas forcément très lisible (elle ne correspond pas forcément au nom de l'utilisateur du client appelant). Pour ce qui est de la seconde situation, dans laquelle l'adresse logique est associée à des informations mémorisées localement par le client, elle n'est possible à mettre en oeuvre que dans le cas où le message d'invitation provient d'un correspondant déjà connu. Elle ne s'applique pas au cas d'un nouveau correspondant, et ne fournit dans ce cas aucune information aidant à la prise de décision de l'utilisateur appelé.
Des solutions ont également été développées pour permettre la transmission d'informations supplémentaires dans une application PoC. Il s'agit par exemple des solutions décrites dans les demandes de brevets US2006/0046755, US2006/0121927 et US 2006/0040686, qui exposent des moyens de communication d'images durant une session « PoC ».
Toutefois ces développements ne permettent pas la transmission d'informations supplémentaires permettant aux clients appelés de décider d'accepter ou non l'invitation à une session de communication. En effet, dans la demande US 2006/0040686, par exemple, l'établissement de la session de communication demeure conforme à l'état de la technique et ce n'est qu'une fois cette session établie, et que le client appelé a accepté l'appel, qu'il peut recevoir une image en provenance d'un serveur.
Il ne peut donc pas tirer profit de cette image pour décider d'accepter ou non l'appel entrant. Par conséquent, un besoin existe pour améliorer l'état de la technique et permettre aux clients appelés de disposer des informations nécessaires pour décider d'accepter ou non une invitation à une session de communication, de type « PoC » (« Push to talk over Cellular »).
L'invention a pour premier objet un client de communication disposant :
- d'un circuit de production sonore pour produire un signal sonore représentatif de données reçues sur un canal de communication descendant et d'un circuit d'acquisition sonore pour produire des données destinées à être transmises sur un canal de communication montant,
- une interface de signalisation, apte à transmettre sur un canal de signalisation des messages de signalisation. Certains de ces messages de signalisation sont destinés à établir une session de communication avec un ou plusieurs autres clients de communication,
- une interface homme-machine comprenant des moyens pour commander cette interface de signalisation, et des moyens pour, lorsqu'une session de communication de type « Push to TaIk » est établie, basculer entre un mode d'émission dans lequel le microphone est actif et un mode de réception dans lequel le microphone n'est pas actif,
- des moyens d'affichage prévus pour afficher des informations basées sur des données contenues dans certains des messages de signalisation reçus.
Le client de communication selon l'invention est novateur en ce que :
- il dispose en outre d'une mémoire prévue pour stocker une carte de visite associée à un utilisateur du client de communication, et destinée à être transmise par un ou plusieurs messages de signalisation vers le ou les autres clients de communication, et en ce que - les moyens d'affichages sont aptes à afficher, totalement ou partiellement, les cartes de visite contenues dans les messages de signalisation reçus.
Selon un mode de réalisation de l'invention, l'interface de signalisation peut être conforme au protocole SIP et prévue pour transmettre la carte de visite dans un message de signalisation « Invite » destiné à établir la session de communication avec un ou plusieurs autres clients de communication.
La carte de visite peut être insérée dans une partie SDP du message de signalisation « Invite ».
Selon une mise en oeuvre de l'invention, la carte de visite peut être conforme au format « vCard ».
Optionnellement, la mémoire prévue pour stocker une carte de visite peut être également prévue pour mémoriser un ensemble de cartes de visite, chacune associée à un utilisateur et un profil d'utilisateur, et le client de communication possède des moyens pour déterminer une carte de visite parmi cet ensemble préalablement à son émission dans un message de signalisation.
L'invention a pour second objet un protocole de signalisation pour réseau de communication mobile, comportant un message de signalisation d'invitation destiné à établir une session de communication de type « Push to TaIk » entre un client de communication appelant et un ou plusieurs clients de communication appelés. Ce message de signalisation contient l'adresse logique du client de communication appelant et une adresse du ou des clients de communication appelés.
Selon l'invention, le protocole de signalisation est novateur en ce le message de signalisation d'invitation contient en outre une carte de visite associée à un utilisateur du client de communication appelant. Selon un mode de réalisation de l'invention, le message de signalisation d'invitation est transmis par le client de communication appelant à un serveur de communication prévu pour le transmettre vers le ou les clients de communication appelés en fonction de la ou des adresses qu'il contient. Selon une mise en oeuvre de l'invention, le message de signalisation peut être un message « Invite » multi-parties conforme à la normalisation SIP et dans lequel la carte de visite est contenue dans une partie conforme au protocole SDP.
Optionnellement, cette carte de visite peut être conforme au format vCard.
L'invention a également pour objet un produit logiciel contenant un code destiné à mettre en œuvre le protocole de communication selon l'invention. Un tel code peut éventuellement être téléchargé depuis un serveur applicatif sur les clients de communication.
L'invention et ses caractéristiques apparaîtront de façon plus claire dans la description de mises en oeuvre qui va suivre.
La figure 1 schématise un réseau de communication permettant de mettre en œuvre l'invention.
La figure 2 représente de façon schématique un message de signalisation selon l'invention.
Dans l'exemple de la figure 1 , un client de communication A peut communiquer avec un réseau de communication mobile N. Ce réseau de communication mobile est typiquement un réseau cellulaire de type GSM, UMTS, CDMA etc. Il peut s'agir d'un réseau convergeant, comportant un sous-réseau mobile et un sous-réseau fixe et permettant à des clients de communication tant fixes que mobiles de communiquer ensemble. Un tel réseau peut être conforme à l'architecture IMS (Internet Multimedia Sυbsystem) normalisée par le 3GPP et TISPAN.
Par l'intermédiaire de ce réseau de communication N, le client de communication N peut communiquer avec un ou plusieurs autres clients de communication B7 C.
De façon connue en soi, un terminal de communication peut être connecté au réseau de communication par un canal montant, permettant de transmettre vers le réseau de communication N, des données (voix, vidéo...) provenant de l'utilisateur du client de communication ; un canal descendant permettant la réception de données provenant du réseau (et indirectement généralement d'un autre client de communication) ; et d'un canal de signalisation permettant la transmission bidirectionnelle de messages de signalisation entre le client de communication et le réseau N.
Les clients de communication sont typiquement des terminaux de communication disposants de circuits de production et d'acquisition sonores permettant l'établissement de session de communication de type « voix ». Ils peuvent ou outre disposer de moyens plus avancés comme des écrans, des caméras etc. permettant l'établissement de session de communication multimédia (vidéo etc.).
Le circuit de production sonore est typiquement un haut-parleur ou un casque permettant de produire un signal sonore représentatif de données reçus sur le canal de communication descendant. Le circuit d'acquisition sonore est typiquement un microphone destiné à produire des données qui sont ensuite émise vers le réseau de communication via le canal de communication montant. Les clients de communication A, B, C disposent en outre d'interfaces de signalisation pour émettre et recevoir des messages de signalisation sur le canal de signalisation les connectant au réseau de communication N.
Ces interfaces de signalisation peuvent être conformes au protocole SIP tel que défini dans le RFC 3261 de l'IETF {Internet Engineering Task Force) et éventuellement aux extensions de ce protocole SIP définies ultérieurement par NETF ou d'autres organismes de normalisation.
Afin d'établir une session de communication de type « PoC » (« Pυsh to talk over Cellυlar »), le client de communication A émet un message de signalisation d'invitation Ml vers le réseau de communication N.
Le client de communication A dispose d'une interface homme- machine qui comprend des moyens pour commander l'interface de signalisation et déclencher l'émission de ce message de signalisation d'invitation Ml. Cette interface homme-machine est typiquement composée d'un ensemble de touches, éventuellement en outre d'un écran tactile, de molettes etc. qui permettent à l'utilisateur de commander et contrôler le client de communication. Par l'intermédiaire de cette interface homme-machine, il peut donc déclencher l'initiation d'une session de communication de type « PoC ».
Cette même interface homme-machine dispose également de moyens (touches, molettes...) pour, lorsqu'une session de communication « Push to TaIk » est établie, basculer entre un mode de réception et un mode d'émission. Dans le mode de réception, le circuit d'acquisition sonore n'est pas actif. Dans le mode d'émission, généralement, le circuit de production sonore n'est pas actif.
Le message de signalisation d'invitation Ml peut être transmis à un serveur de communication SC au sein du réseau de communication. Ce serveur de communication est apte à comprendre le contenu du message de signalisation d'invitation Ml et, en fonction de ce contenu, de le transmettre vers les clients de communication appelés B et C.
La figure 2 schématise un tel message de signalisation d'invitation conforme au protocole SIP et aux spécifications normalisés de l'OMA pour un service « PoC ».
Ce message de signalisation d'invitation Ml est alors un message « INVITE » défini par le RFC 3261 de NETF.
Il comporte une première partie ES1P formée par un ensemble d'entêtés SIP. Ces entêtes contiennent au moins l'adresse logique de l'utilisateur du client de communication A. Elles contiennent aussi des informations permettant l'acheminement du message d'invitation jusqu'au serveur de communication SC.
Le message de signalisation « INVITE » contient également une partie
Pl contenant des informations décrivant la session de communication établir et permettant la négociation de ces paramètres par les différentes parties. Ces paramètres peuvent être, par exemple, relatifs à l'encodage des flux média à mettre en œuvre etc. De façon connue en soi, cette partie est conforme au protocole SDP
(« Session Description Protocol »).
Le message de signalisation Ml contient également une partie P2, également conforme à ce protocole SDP, ainsi qu'il est spécifié dans les documents normalisateurs sus-mentionnés et issus de l'OMA. Cette partie P2 contient les adresses logiques des clients de communications invités.
Le code suivant est un exemple illustratif de message de signalisation d'invitation conforme au protocole SIP et aux spécifications de l'OMA. Le premier extrait représente les entêtes Es,p de ce message d'invitation. Les mots en gras représentent les mots-clés de la grammaire du protocole SIP et n'ont été mis en forme que dans un souci de lisibilité.
On peut remarquer l'entête « Content-Type: multipart/mixed » qui signifie que le message d'invitation Ml est un message « multi-parties », comportant plusieurs parties conformes au protocole SDP (Pl et P2, ainsi que P3 qui sera ultérieurement décrit).
SIP INVITE request
Request-URI sip : PoCConferenceFactoryURI .networkA.net P-Preferred-Identity: "PoC User A" <sip:PoC-
UserA@networkA.net>
Accept-Contact: *; +g .poc . talkburst ; require; explicit
User-Agent: PoC-client/OMAl .0 Acme-Talk5000/vl .01
Privacy: id Contact: <sip: PoC-
ClientA. networkA . net> ; +g . poc . talkburst
Supportée.: timer
Session-Expires: 1800 ;refresher=uac
ALLOW: INVITE,ACK7 CANCEL, BYE, REFER,MESSAGE, SUBSCRIBE, NOTIFY7PUBLISH
Content-Type: multipart/mixed P-Alerting-Mode: MAO
La partie Pl , conforme au protocole SDP, peut se présenter sous la forme suivante :
Content-Type: application/sdp C= IN IP6 5555: : aaa : bbb : ecc : ddd m= audio 3456 RTP/AVP 97 a= rtpmap:97 AMR a= rtcp:5560 m= application 2000 udp TBCP a= fmtp : TBCP queuing=l; tb_priority=2 ; timestamp=l
La partie P2, elle aussi conforme au protocole SDP, peut se présenter sous la forme suivante :
Content-Type : application/resource-lists+xml
Content-Disposition: récipient-Iist
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns= "urn: ietf rparams :xτnl :ns : resource-lists" xmlns :xsi="http : //www.w3. org/200l/XMLSchema- instance">
<list>
<entry uri="sip : PoC-UserB@networkB . corn" /> <entry uri= "sip : PoC-UserC@networkC.com" />
</list>
</resource-lists>
Comme décrit précédemment, cette partie P2 contient les adresses des clients de communication B, C appelés (« sip:PoC-UserB@networkB.com » et «sip:PoC-UserC@networkC.com »).
Le serveur de communication SC est prévu pour transmettre ce message de signalisation d'invitation Ml vers les clients de communication B et C en fonction des adresses (« sip:PoC-UserB@networkB.com » et «sip:PoC- UserC@networkC.com ») contenues dans ce message. Dans l'exemple de la figure 1 , le message Ml est donc dupliqué en un message MIB transmis au client de communication B et un message Mlc transmis au client de communication C. En outre, selon l'invention une partie P3 est également insérée dans le message de signalisation d'invitation Ml émis par le client de communication A appelant.
Cette partie P3 contient une carte de visite de l'utilisateur. Elle peut être stockée préalablement dans une mémoire prévue à cet effet au sein du client de communication. Le client de communication peut alors être prévu pour automatiquement insérer cette carte de visite stockée dans les messages de signalisation d'invitation émis. Eventuellement, une confirmation de l'utilisateur peut être demandée, ou bien l'insertion automatique peut être l'objet d'une option de configuration de ce client de communication.
Si un même client de communication est susceptible d'être utilisé par plusieurs utilisateurs différents, la mémoire peut stocker plusieurs cartes de visite. Dans un tel cas, la détermination de la carte de visite à transmettre peut être effectuée de façon automatique lors de la connexion de l'utilisateur au client de communication (« login »).
Éventuellement, pour un même utilisateur, plusieurs cartes de visite peuvent être prévues et stockées, correspondant à différents profils : par exemple, une carte de visite professionnelle, une carte de visite privée etc.
Dans tous les cas, le client de communication dispose de moyens pour déterminer une carte de visite parmi l'ensemble des cartes de visite stockées, préalablement à l'émission dans un message de signalisation Ml.
Cette carte de visite peut être conforme au format vCard. Ce format vCard a le mérite d'être largement utilisé dans les courriers électroniques et permet ainsi une interopérabilité entre les messages d'invitation et les courriers électroniques ainsi qu'entre les applications et services les utilisant.
Ce format vCard (« Versitcard ») est normalisé dans sa version 3.0 par les RFC 2425 et 2426 de l'IETF, intitulés respectivement « A MIME Content- Type for Directory Information » et « vCard MIME Directory Profile ». D'autres spécifications de cartes de visite sont bien entendu possibles, tout en demeurant dans le cadre de l'invention.
La carte de visite peut contenir différentes informations relatives à l'utilisateur du client de communication : son nom d'usage ou patronymique, son adresse électronique, son adresse physique, des numéros de téléphones, son titre et/ou sa fonction professionnelle etc.
Conformément au protocole SDP, cette partie P3 qui contient !a carte de visite peut être comme suit :
Content-Type: application/x-vcard begin:vcard fn: Smith n: : Smith; Bob org :Alcatel ; adr:; /Route de Nozay;Marcoussis; ; F-91461
Cedex; France email ; internet : Bob . Smith@alcatel . fr tβl;work:+33 (0)1 69 63 xx xx tel; fax: +33 (0)1 69 63 xx xx version: 2.1 end: vcard
Cette partie P3 contenue dans le message de signalisation Ml est maintenue dans les messages de signalisation MIB et Mlc transmis par le serveur de communication SC respectivement aux clients de communication B et C.
Les serveurs de communication B et C disposent de moyens d'affichage, notamment d'un écran. Les informations contenues dans la carte de visite peuvent alors être affichées, partiellement ou totalement, sur cet écran. Elles offrent ainsi à l'utilisateur des clients de communication appelés des informations supplémentaires permettant de décider l'acceptation ou non de l'invitation. Certaines informations peuvent être affichées automatiquement (noms de l'appelant...), tandis que d'autres ne seront affichés qu'après une action spécifique de l'utilisateur (adresses...). Cette séparation peut être dépendante de la taille de l'écran d'affichage.
Même s'il ne connaît pas l'utilisateur du client de communication A, l'utilisateur du client de communication B ou C peut ainsi être informé de son nom, de sa société, de son adresse etc. et ces informations peuvent l'informer suffisamment pour sa prise de décision. Il peut ainsi filtrer certains appels entrant, et éventuellement écarter les invitations non sollicitées de type « spamming ».
Il peut aussi se préparer mentalement et physiquement à un appel entrait (en sortant un dossier, une documentation etc.)
Cette carte de visite reçue par un client de communication peut optionnellement être stockée dans une mémoire prévue à cet effet, et être gérée par une application de type « carnet d'adresses ». Cette mémorisation et cette application permettent à un utilisateur de gérer ces contacts et de garder trace des interlocuteurs.
Selon une mise en œuvre de l'invention, les cartes de visite peuvent également être transmises par d'autres messages de signalisation que les messages de signalisation d'invitation.
Par exemple, des messages de signalisation peuvent être transmis par un client de communication appelé B vers le client de communication appelant A et/ou vers l'autre client de communication appelé C. Ces messages de signalisation, contenant la carte de visite de l'utilisateur du client de communication B, permettent aux clients de communication A et C de connaître ces informations personnelles et d'éventuellement stocker cette carte de visite parmi leurs contacts.

Claims

REVENDICATIONS
1) Client de communication (A) disposant : - d'un circuit de production sonore pour produire un signal sonore représentatif de données reçues sur un canal de communication descendant et d'un circuit d'acquisition sonore pour produire des données destinées à être transmises sur un canal de communication montant, et
- une interface de signalisation, apte à transmettre sur un canal de signalisation des messages de signalisation (Ml) ; certains desdits messages de signalisation étant des messages d'invitation, destinés à établir une session de communication avec un ou plusieurs autres clients de communication (B,
C),
- une interface homme-machine comprenant des moyens pour commander ladite interface de signalisation, et des moyens pour, lorsqu'une session de communication de type « Push to TaIk » est établie, basculer entre un mode d'émission dans lequel ledit microphone est actif et un mode de réception dans lequel ledit microphone n'est pas actif,
- des moyens d'affichage prévus pour afficher des informations basées sur des données contenues dans certains des messages de signalisation reçus, caractérisé en ce qu'il dispose en outre d'une mémoire prévue pour stocker une carte de visite associée à un utilisateur dudit client de communication, et destinée à être transmise par un ou plusieurs messages d'invitation vers le ou lesdits autres clients de communication, et en ce que lesdits moyens d'affichages sont aptes à afficher, totalement ou partiellement, les cartes de visite contenues dans lesdits messages de signalisation reçus. 2) Client de communication selon la revendication 1 , dans lequel ladite interface de signalisation est conforme au protocole SIP et prévue pour transmettre ladite carte de visite dans un message de signalisation « Invite » destiné à établir ladite session de communication avec un ou plusieurs autres clients de communication.
3) Client de communication selon la revendication précédente, dans lequel ladite carte de visite est insérée dans une partie SDP dudit message de signalisation « Invite ».
4) Client de communication selon l'une des revendications précédentes, dans lequel ladite carte de visite est conforme au format « vCard ».
5) Client de communication selon l'une des revendications précédentes, dans lequel ladite mémoire prévue pour stocker une carte de visite est également prévue pour mémoriser un ensemble de cartes de visite, chacune associée à un utilisateur et un profil d'utilisateur, et possédant en outre des moyens pour déterminer une carte de visite parmi ledit ensemble préalablement à l'émission dans un message de signalisation (Ml).
6) Protocole de signalisation pour réseau de communication mobile (N), comportant un message de signalisation d'invitation (Ml) destiné à établir une session de communication de type « Push to TaIk » entre un client de communication appelant (A) et un ou plusieurs clients de communication appelés (B, C) et contenant l'adresse logique dudit client de communication appelant et une adresse dudit ou desdits clients de communication appelés, caractérisé en ce que ledit message de signalisation d'invitation (Ml) contient en outre une carte de visite associée à un utilisateur dudit client de communication appelant (A). 7) Protocole de signalisation selon la revendication précédente, dans lequel ledit message de signalisation d'invitation (Ml) est transmis par ledit client de communication appelant (A) à un serveur de communication (SC) prévu pour le transmettre vers le ou lesdits clients de communication appelés (B, C) en fonction de la ou desdites adresses.
8) Protocole de signalisation selon l'une des revendications 5 ou 6, dans lequel ledit message de signalisation est un message « Invite » multi- parties conforme à la normalisation SIP et dans lequel ladite carte de visite est contenue dans une partie conforme au protocole SDP.
9) Protocole de signalisation selon l'une des revendications 5 à 7, dans lequel ladite carte de visite est conforme au format vCard.
10) Produit logiciel contenant un code destiné à mettre en œuvre le protocole de communication selon l'une des revendications 6 à 9.
11) Protocole de signalisation pour réseau de communication mobile (N), comportant un message de signalisation d'invitation (Ml) destiné à établir une session de communication entre un client de communication appelant (A) et un ou plusieurs clients de communication appelés (B, C) et contenant l'adresse logique dudit client de communication appelant et une adresse dudit ou desdits clients de communication appelés, caractérisé en ce que ledit message de signalisation d'invitation (Ml) contient en outre une carte de visite associée à un utilisateur dudit client de communication appelant (A).
12) Protocole de signalisation selon la revendication précédente, dans lequel ladite carte de visite est conforme au format vCard. 13) Protocole de signalisation selon la revendication précédente dans lequel ledit message de signalisation d'invitation est un message « Invite » conforme à la normalisation SIP.
14) Protocole de signalisation selon la revendication précédente, dans lequel ladite carte de visite est contenue dans une partie conforme au protocole SDP, dudit message de signalisation d'invitation.
15) Réseau de communication mettant en œuvre un client de communication conforme à l'une des revendications 1 à 5.
PCT/EP2007/059499 2006-10-18 2007-09-11 Enrichissement de la signalisation dans une session de communication de type ' push to talk ' par insertion d'une carte de visite WO2008046697A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2009532746A JP2010507302A (ja) 2006-10-18 2007-09-11 名刺の挿入による「プッシュ・ツー・トーク」タイプ通信セッションのシグナリングの向上

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0654332 2006-10-18
FR0654332A FR2907621B1 (fr) 2006-10-18 2006-10-18 Enrichissement de la signalisation dans une session de communication de type "push to talk" par insertion d'une carte de visite

Publications (1)

Publication Number Publication Date
WO2008046697A1 true WO2008046697A1 (fr) 2008-04-24

Family

ID=38009515

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/059499 WO2008046697A1 (fr) 2006-10-18 2007-09-11 Enrichissement de la signalisation dans une session de communication de type ' push to talk ' par insertion d'une carte de visite

Country Status (7)

Country Link
US (1) US7869821B2 (fr)
EP (1) EP1921835A1 (fr)
JP (1) JP2010507302A (fr)
KR (1) KR20090068335A (fr)
CN (1) CN101166314A (fr)
FR (1) FR2907621B1 (fr)
WO (1) WO2008046697A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101951702A (zh) * 2010-08-19 2011-01-19 浙江元亨通信技术有限公司 一种基于手机终端实现单工通信的方法
EP2605491A1 (fr) 2011-12-15 2013-06-19 Oberthur Technologies Procédé d'initiation d'une conversation

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8295881B2 (en) * 2009-02-12 2012-10-23 Alcatel Lucent Virtual card (VCARD) container for creating and sending electronic business cards
CN107277284A (zh) * 2017-04-26 2017-10-20 捷开通讯(深圳)有限公司 基于VoLTE的语音通话方法和系统、存储装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060040686A1 (en) * 2004-08-17 2006-02-23 Samsung Electronics Co., Ltd. Apparatus and method for displaying an image of a speaker in a push-to-talk communication service in a push-to-talk portable terminal
US20060046755A1 (en) * 2004-08-24 2006-03-02 Kies Jonathan K System and method for transmitting graphics data in a push-to-talk system
US20060121927A1 (en) * 2004-12-08 2006-06-08 Samsung Electronics Co., Ltd. Method for transmitting message during PTT call service in mobile communication terminal

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040219925A1 (en) * 2003-04-30 2004-11-04 Motorola, Inc. Image data transfer over a dispatch voice channel

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060040686A1 (en) * 2004-08-17 2006-02-23 Samsung Electronics Co., Ltd. Apparatus and method for displaying an image of a speaker in a push-to-talk communication service in a push-to-talk portable terminal
US20060046755A1 (en) * 2004-08-24 2006-03-02 Kies Jonathan K System and method for transmitting graphics data in a push-to-talk system
US20060121927A1 (en) * 2004-12-08 2006-06-08 Samsung Electronics Co., Ltd. Method for transmitting message during PTT call service in mobile communication terminal

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101951702A (zh) * 2010-08-19 2011-01-19 浙江元亨通信技术有限公司 一种基于手机终端实现单工通信的方法
EP2605491A1 (fr) 2011-12-15 2013-06-19 Oberthur Technologies Procédé d'initiation d'une conversation

Also Published As

Publication number Publication date
CN101166314A (zh) 2008-04-23
US7869821B2 (en) 2011-01-11
EP1921835A1 (fr) 2008-05-14
FR2907621A1 (fr) 2008-04-25
FR2907621B1 (fr) 2009-01-23
JP2010507302A (ja) 2010-03-04
KR20090068335A (ko) 2009-06-26
US20080096599A1 (en) 2008-04-24

Similar Documents

Publication Publication Date Title
CN100592831C (zh) 终端及其内容共享的方法和系统
TWI239172B (en) Method and system for group communications
CN1985489B (zh) 在多媒体通信系统中提供不同服务的方法和装置
US8339437B2 (en) Video communication method, video communication system and integrated media resource server
EP1856901B1 (fr) Procede et systeme d&#39;information des participants a une conversation telephonique
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.
JP4851531B2 (ja) プッシュツートーク型サービスのための方法および装置
FR2911459A1 (fr) Procede de signalisation permettant la prise en compte de la raison de l&#39;appel
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
US9282152B2 (en) Providing push to all (PTA) service
WO2008052458A1 (fr) Procédé, système et terminal d&#39;acquisition d&#39;informations de caractères médiatiques.
WO2010043168A1 (fr) Procédé d&#39;envoi et de réception de fichier de tonalité d&#39;appel multimédia
FR2931024A1 (fr) Conversion voix vers texte en temps reel pour services de telecommunication
FR2889900A1 (fr) Procede pour la creation assistee par ordinateur d&#39;un message de vote, procede pour la determination assistee par ordinateur d&#39;au moins un resultat de vote
EP3361746B1 (fr) Systeme de gestion de flux media
CN101193345B (zh) 终端及其内容共享的方法和系统
US20130335510A1 (en) System for exchanging ptt messages for brief multi video conferences
WO2019081836A1 (fr) Procédé et entité de gestion d&#39;une session multimédia entre un terminal appelant et au moins un terminal appelé, terminal et programme d&#39;ordinateur correspondants
CN101938574A (zh) 包交换域中彩铃信息传输方法及系统及彩铃服务器和终端
EP2064855A1 (fr) Procede de communication entre plusieurs terminaux
Roy Handbook on Networked Multipoint Multimedia Conferencing and Multistream Immersive Telepresence Using SIP: Scalable Distributed Applications and Media Control Over Internet
CN105577697B (zh) 对多媒体数据流传输跑马灯信息的方法和通信装置
EP2073493A1 (fr) Procédé de communication multimédia, serveur et produit programme d&#39;ordinateur correspondants
FR2927491A1 (fr) Procede et dispositif de transfert d&#39;un signal de flux multimedia au cours d&#39;une session de communication
KR20080079028A (ko) Sip를 이용한 보류된 호의 보류 해제 요청 방법

Legal Events

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

Ref document number: 07820109

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 1020097007805

Country of ref document: KR

ENP Entry into the national phase

Ref document number: 2009532746

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07820109

Country of ref document: EP

Kind code of ref document: A1