FR3121808A1 - Procédés et dispositifs d’enrichissement et de traitement d’un message de signalisation - Google Patents

Procédés et dispositifs d’enrichissement et de traitement d’un message de signalisation Download PDF

Info

Publication number
FR3121808A1
FR3121808A1 FR2103531A FR2103531A FR3121808A1 FR 3121808 A1 FR3121808 A1 FR 3121808A1 FR 2103531 A FR2103531 A FR 2103531A FR 2103531 A FR2103531 A FR 2103531A FR 3121808 A1 FR3121808 A1 FR 3121808A1
Authority
FR
France
Prior art keywords
signaling message
header
terminal
parameter
caller
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.)
Pending
Application number
FR2103531A
Other languages
English (en)
Inventor
Bertrand Bouvet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR2103531A priority Critical patent/FR3121808A1/fr
Publication of FR3121808A1 publication Critical patent/FR3121808A1/fr
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/42025Calling or Called party identification service
    • H04M3/42034Calling party identification service
    • H04M3/42042Notifying the called party of information on the calling party
    • 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/10Architectures or entities
    • H04L65/1045Proxies, e.g. for session initiation protocol [SIP]
    • 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/10Architectures or entities
    • H04L65/1046Call controllers; Call servers
    • 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/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2203/00Aspects of automatic or semi-automatic exchanges
    • H04M2203/60Aspects of automatic or semi-automatic exchanges related to security aspects in telephonic communication systems
    • H04M2203/6027Fraud preventions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2203/00Aspects of automatic or semi-automatic exchanges
    • H04M2203/60Aspects of automatic or semi-automatic exchanges related to security aspects in telephonic communication systems
    • H04M2203/6045Identity confirmation

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Telephone Function (AREA)
  • User Interface Of Digital Computer (AREA)

Abstract

L'invention concerne un procédé d’enrichissement d’au moins un message de signalisation d’une communication émis par un premier terminal d’un premier utilisateur à destination d’un second terminal d’un second utilisateur, ledit procédé étant mis en œuvre par un dispositif d’enrichissement et caractérisé en ce qu’il comprend :- une étape de réception dudit au moins un message de signalisation comprenant au moins une identité dudit premier utilisateur ;- une étape d’insertion dans un premier entête dudit au moins un message de signalisation d’au moins une donnée obtenue en fonction de ladite au moins une identité reçue ;- une étape d’attribution d’une valeur d’enrichissement à un paramètre d’un deuxième entête dudit au moins un message de signalisation ;- une étape d’émission dudit message de signalisation vers ledit au moins un second terminal. Figure pour l'abrégé : Figure 4

Description

Procédés et dispositifs d’enrichissement et de traitement d’un message de signalisation
1. Domaine de l'invention
La demande d’invention se situe dans le domaine des télécommunications et de façon privilégiée mais non limitative au niveau des services de téléphonie et de visiophonie sur réseau fixe et mobile.
2. Art Antérieur
Les utilisateurs des services de télécommunications (téléphonie, visiophonie) reçoivent de plus en plus d’appels non sollicités avec à la clef de nombreux désagréments (ligne occupée, temps perdu, dérangements, etc.). En réaction, un grand nombre d’entre eux, ne décrochent plus lorsque les appels entrants présentent un numéro d’appelant inconnu/non présent dans leur répertoire téléphonique et ce même si l’appel est souhaité. Ainsi, de nombreuses entreprises n’arrivent plus à contacter leurs clients par téléphone ce qui peut, par exemple, engendrer des coûts tels que des délais supplémentaires de traitement d’un dossier, des relances par courrier, des pertes de chiffre d’affaire, etc.
Afin d’augmenter les chances de joindre leurs clients, certaines entreprises envoient au préalable un SMS à l’appelé indiquant qu’un conseiller de la société va les contacter prochainement en présentant un numéro de téléphone particulier pour discuter d’un sujet particulier. Mais ce mode de fonctionnement n’est pas optimal car il engendre également des coûts supplémentaires non négligeables (nécessité de connaître le numéro de téléphone mobile du client, coût du SMS, gestion du processus de synchronisation du SMS avec l’appel téléphonique, etc.)
Le service de présentation du nom de l’appelant CNIP (service Calling Name Identity Presentation) défini dans les organismes de standardisation UIT, ETSI, 3GPP, permet de résoudre partiellement le problème. En effet, lorsque le service de présentation du numéro de l’appelant CLIP (service Calling Line Identification Presentation défini dans les organismes de standardisation UIT, ETSI, 3GPP) / OIP (Originating Identification Presentation pour le cas des réseaux VoIP IMS) est actif, et lorsque le numéro de l’appelant est disponible et non masqué, ce service permet à l’appelé d’obtenir le nom de l’appelant, dès lors que le terminal dispose de moyens activés pour restituer cette information. Concrètement, le terminal de l’appelé peut, en phase de présentation d’un appel, restituer le nom de l’appelant dès lors que celui-ci est présent dans le message de signalisation de l’appel. A noter que la restitution peut être conditionnée au fait que l’appelé ait souscrit à un abonnement particulier auprès de son opérateur ou au fait que l’appelé n’ait pas désactivé le service CNIP via, par exemple, une page de configuration accessible depuis son compte client.
Ainsi, ce service est particulièrement intéressant pour l’appelé. En effet, il lui permet de connaître l’identité de l’interlocuteur avant d’accepter une communication. L’appelé ayant pris connaissance du nom de l’appelant, répondra à l’appel si bien sûr celui-ci est souhaité. En corollaire, ce service est également particulièrement intéressant pour une entreprise car il permet de présenter aux appelés (les clients) son identité (nom/marque) en remplacement ou en complément de son numéro de téléphone (généralement pas connu des appelés) avec comme conséquence un taux plus élevé de joignabilité des clients.
Techniquement, le service CNIP est rendu par un équipement réseau de l’opérateur de l’appelé. L’équipement réseau est par exemple un CAA (Commutateur à Autonomie d’Acheminement) dans le cas d’un appel RTC (réseau téléphonique commuté) sur un réseau fixe en mode circuit, un VMSC (pour Visited Mobile Switch Center en anglais) dans le cas d’un appel mobile sur un réseau mobile 2G/3G ou un serveur d’application téléphonique TAS (pour Telephony Application Server en anglais) dans le cas d’un appel VoIP (pour Voice Over IP en anglais) sur un réseau fixe/mobile 4G/5G/WiFi.
Cet équipement ne dispose généralement que d’une seule logique de service (service Calling Name Retreival) et d’une seule interface externe vers une base de données qui recense les informations à restituer et associées aux identifiants des appelants. Ne pouvant consulter de manière simultanée plusieurs bases de données, cet équipement ne peut donc pas appliquer une logique de traitement appropriée en fonction, par exemple de la provenance d’une information associée à un identifiant d’appelant donné.
A noter également qu’une évolution fonctionnelle de cet équipement nécessiterait des coûts importants en termes d’études, de développement et de validation pour les fournisseurs mais également des coûts importants en terme de mise à jour du système d’information (SI) des opérateurs (études et validation de la nouvelle architecture du SI et coûts de licence complémentaires attaché à l’équipement réseau pour bénéficier de ces multiples consultations de bases de données et traitements de logique de service associée).
En outre, le service (CNIP) repose sur des bases de données clients propres à chaque opérateur. Par conséquent, lorsque l’appel provient d’un appelant pris en charge par un opérateur tiers, ce service ne permet pas d’obtenir le nom de l’appelant car celui-ci n’est pas connu de l’opérateur de l’appelé (pas présent dans la base de données de l’opérateur appelé). A noter que ce constat est identique pour le service de présentation du nom CNAP (Calling NAme Presentation) proposé sur le réseau mobile et qui est le pendant du service de présentation du nom CNIP proposé sur le réseau fixe.
Sur le réseau mobile il existe une solution permettant de pallier en partie cette limitation. En effet, il est possible d’utiliser une application de téléphonie alternative à celle proposée par défaut par le constructeur du terminal mobile ou du fournisseur de l’OS (pour Operating System en anglais). Une telle application alternative permet d’obtenir des informations complémentaires concernant le numéro d’un appelant. Elles sont le plus souvent fournies et partagées par les utilisateurs de l’application ou par un opérateur de télécommunications et permettent de qualifier le numéro de l’appelant (télémarketing, acceptable, spam, etc.).
En outre, il existe une solution complémentaire, proposée aux opérateurs de télécommunications par des sociétés spécialisées, qui permet à un opérateur de télécommunications d’enrichir les informations de qualification d’un appel entrant, via un accès à une base de données opérée par la société spécialisée qui recense des couples numéro de téléphone / nom d’une entreprise. La société spécialisée est alors responsable de la mise à jour des couples et de la pertinence des données stockées dans la base de données.
S’il est envisageable de proposer un tel service basé sur des informations collectées par la communauté, par des entreprises spécialisées ou fournies par des opérateurs de télécommunications en utilisant les mécanismes techniques existants du service CNIP, se pose alors le problème de la priorisation / cohabitation de ces informations de qualification d’appels entrants avec les informations retournées par le service CNIP lors de leur restitution au niveau du terminal appelé, lorsque le service CNIP est actif.
A noter que la même problématique est soulevée concernant le service CNAP du réseau mobile.
3. Exposé de l'invention
L'invention vient améliorer l'état de la technique et propose à cet effet un procédé d’enrichissement d’au moins un message de signalisation d’une communication émis par un premier terminal d’un premier utilisateur à destination d’un second terminal d’un second utilisateur, ledit procédé étant mis en œuvre par un dispositif d’enrichissement et caractérisé en ce qu’il comprend :
  • une étape de réception dudit au moins un message de signalisation comprenant au moins une identité dudit premier utilisateur ;
  • une étape d’insertion dans un premier entête dudit au moins un message de signalisation d’au moins une donnée obtenue en fonction de ladite au moins une identité reçue ;
  • une étape d’attribution d’une valeur d’enrichissement à un paramètre d’un deuxième entête dudit au moins un message de signalisation ;
  • une étape d’émission dudit message de signalisation vers ledit au moins un second terminal.
Avantageusement, selon l'invention, un message de signalisation d’une communication téléphonique ou visiophonique est enrichie afin d’ajouter des données permettant à un équipement informatique, tel qu’un serveur applicatif, de réaliser un traitement optimisé et approprié du message de signalisation lors de l’établissement de l’appel dans le but de présenter à l’appelé une information la plus complète possible concernant l’identité de l’appelant. Concrètement, le procédé reçoit un message de signalisation d’une communication et obtient ensuite l’identité de l’appelant, par exemple, via les entêtes SIP FROM et / ou PAI (pour Private-Asserted-Identity) compris dans le message de signalisation SIP INVITE d’un appel entrant. Un fois obtenu, l’identité est utilisée pour obtenir, par exemple depuis au moins une base de données locale ou distante, une donnée associée à l’identité appelante. Cette donnée peut comprendre des informations concernant l’appelant telles que son nom, un objet d’appel, un libellé particulier de qualification de ce numéro appelant (télémarketing, spam, acceptable, etc.) ou plus généralement n’importe quelle chaîne de caractères en lien avec l’appelant. La donnée est ensuite insérée dans un entête particulier du message de signalisation, par exemple, un entête propriétaire SIP. A noter que dans le cas du protocole SIP le standard IETF RFC3261 précise bien que les entêtes propriétaires doivent être transportés de manière transparente par les équipements applicatifs SIP fonctionnant en mode proxy ou B2BUA (Back To Back User Agent). Le procédé attribue ensuite une valeur d’enrichissement à un paramètre d’un deuxième entête du message de signalisation tel que le paramètre SIP DISPLAY de l’entête SIP FROM et/ou PAI puis émet le message à destination du terminal de l’appelé. La valeur d’enrichissement est par exemple une chaîne de caractères telle que « Magic », le nom du processus informatique qui exécute le procédé d’enrichissement ou encore n’importe quelle chaîne de caractères, par exemple, contenue dans un fichier de configuration du dispositif d’enrichissement et qui indique un enrichissement du message de signalisation par le dispositif d’enrichissement.
On entend par identifiant une suite de caractères qui sert à identifier un objet, comme par exemple un terminal, un service ou un utilisateur lors d’une communication. L’identifiant peut être un nom, une adresse de messagerie, une adresse IP ou un numéro (par exemple un numéro de téléphone). De façon connue, en protocole SIP :
  • l’identifiant peut être au format SIP URI ou au format TEL URI ;
  • l’identifiant appelant non certifié par l’opérateur de télécommunications de l’appelant est contenu dans l’entête SIP FROM ;
  • l’identifiant appelant certifié par l’opérateur de télécommunications de l’appelant est contenu dans l’entête SIP PAI. Il peut y avoir deux PAI dans le message de signalisation d’appel SIP INVITE : un au format SIP URI et un au format TEL URI, avec des contenus généralement identiques mais pouvant parfois être différents.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce qu’un identifiant de service est en outre inséré dans ledit premier entête.
Avantageusement, ce mode de réalisation permet d’ajouter une information complémentaire (un identifiant de service) au premier entête tel que le nom du service qui a fourni la donnée associée à l’identité de l’appelant. Cet identifiant de service permet, par exemple, à un dispositif recevant le message de signalisation de réaliser un traitement différentié du message de signalisation en fonction de la provenance (c’est-à-dire du service) de la donnée contenue dans le premier entête.
L'invention concerne également un procédé de traitement d’au moins un message de signalisation d’une communication émis par un premier terminal d’un premier utilisateur à destination d’un second terminal d’un second utilisateur, ledit procédé étant mis en œuvre par un dispositif de traitement et caractérisé en ce qu’il comprend :
  • une étape de réception dudit au moins un message de signalisation ;
  • une étape d’obtention du contenu d’un paramètre d’un deuxième entête dudit au moins un message de signalisation comprenant une chaîne de caractères ;
et lorsque ladite chaîne de caractères est vide ou correspond à une valeur d’enrichissement insérée par un dispositif d’enrichissement
  • une étape de modification dudit paramètre dudit deuxième entête en fonction de la valeur d’un premier entête dudit message de signalisation ;
  • une étape d’émission dudit message de signalisation vers ledit au moins un second terminal.
Avantageusement, ce mode de réalisation permet de traiter un message de signalisation en fonction des données contenues dans les entêtes du message sans avoir besoin de consulter, par exemple auprès d’une base de données du système d’information et/ou du réseau de l’opérateur appelé, l’état (actif/inactif) du service CNIP/CNAP et/ou du service CLIP.
Lors de la réception du message de signalisation, le procédé obtient le contenu, par exemple une chaîne de caractères, du paramètre d’un deuxième entête tel que le paramètre SIP DISPLAY de l’entête FROM et/ou PAI puis le teste. Si la chaîne de caractères est vide ou correspond à une valeur d’enrichissement insérée par un dispositif d’enrichissement, alors son contenu est modifié en fonction de la valeur d’un premier entête, par exemple propriétaire, compris dans le message de signalisation. Le message de signalisation est ensuite émis à destination du terminal de l’appelé.
Dans le cas où le contenu du paramètre du deuxième entête n’est pas vide ou correspond à une valeur qui n’est pas une valeur d’enrichissement insérée par un dispositif d’enrichissement alors cela signifie que le service CNIP/CNAP y a inséré une information associée à l’appelant et que les données reçues du service CNIP/CNAP sont considérées comme prioritaires par rapport aux informations de qualification de l’appelant insérées par le procédé d’enrichissement.
A noter que le service CNIP/CNAP utilise, conformément à la standardisation, en protocole SIP, le paramètre SIP DISPLAY, pour y insérer le nom de l’appelant si l’appelant est également client de l’opérateur appelé.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ledit paramètre dudit deuxième entête est en outre modifié en fonction de la valeur d’un troisième entête dudit message de signalisation.
Avantageusement, ce mode de réalisation permet de modifier, par exemple, le contenu (par exemple une chaîne de caractères) du paramètre SIP DISPLAY de l’entête FROM et/ou PAI du message de signalisation en fonction du contenu (par exemple une chaîne de caractères) d’un premier entête tel que l’entête propriétaire mais aussi du contenu (par exemple une chaîne de caractères) d’un troisième entête tel que le contenu du paramètre SIP URI de l’entête FROM. Ainsi ce mode de réalisation permet de modifier le paramètre du deuxième entête sans avoir besoin de consulter, par exemple auprès d’une base de données du système d’information et/ou du réseau de l’opérateur appelé, l’état (actif/inactif) du service CLIP.
Ce mode de réalisation permet également d’éviter des développements logiciels supplémentaires au niveau du système d’information de l’opérateur de l’appelé, en particulier au niveau des comptes utilisateurs et de leurs pages de configuration qui permettent de gérer l’activation ou la désactivation d’un service tel que le service CLIP ou la restitution en fonction de l’état (actif/inactif) du service CLIP des informations de qualification du numéro d’appelant. A noter que la règlementation de certains pays impose de proposer à l’appelé la possibilité d’activer/désactiver la restitution de l’information de qualification de l’appelant.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ledit paramètre dudit deuxième entête est modifié en fonction de la valeur d’un troisième entête dudit message de signalisation lorsque ledit premier entête dudit message de signalisation comprend un identifiant de service.
Avantageusement, ce mode de réalisation permet de modifier, par exemple, le contenu du paramètre SIP DISPLAY de l’entête FROM et/ou PAI du message de signalisation uniquement lorsqu’un identifiant de service est présent dans un entête propriétaire du message de signalisation. Ainsi ce mode de mise en œuvre permet de simplifier le traitement. En effet, lorsque l’entête propriétaire du message de signalisation ne contient pas un identifiant de service alors il n’est alors pas utile de traiter le contenu d’un troisième entête tel que l’entête FROM.
L'invention concerne également un dispositif d’enrichissement d’au moins un message de signalisation d’une communication émis par un premier terminal d’un premier utilisateur à destination d’un second terminal d’un second utilisateur, ledit dispositif étant caractérisé en ce qu’il comprend :
  • un module de réception dudit au moins un message de signalisation comprenant au moins une identité dudit premier utilisateur ;
  • un module d’insertion dans un premier entête dudit au moins un message de signalisation d’au moins une donnée obtenue en fonction de ladite au moins une identité obtenue ;
  • un module d’attribution d’une valeur d’enrichissement à un paramètre d’un deuxième entête dudit au moins un message de signalisation ;
  • un module d’émission dudit message de signalisation vers ledit au moins un second terminal.
L'invention concerne également un dispositif de traitement d’au moins un message de signalisation d’une communication émis par un premier terminal d’un premier utilisateur à destination d’un second terminal d’un second utilisateur, ledit traitement étant caractérisé en ce qu’il comprend :
  • un module de réception dudit au moins un message de signalisation ;
  • un module d’obtention du contenu du paramètre d’un deuxième entête dudit au moins un message de signalisation comprenant une chaîne de caractère ;
  • un module de modification dudit paramètre dudit deuxième entête en fonction de la valeur d’un premier entête dudit message de signalisation ;
  • un module d’émission dudit message de signalisation vers ledit au moins un second terminal.
Le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).
L'invention concerne également des programmes d'ordinateur comportant des instructions pour la mise en œuvre respectivement des procédés ci-dessus selon l'un quelconque des modes particuliers de réalisation décrits précédemment, lorsque lesdits programmes sont exécutés par un processeur. Les procédés peuvent être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. Ces programmes peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'enregistrement ou support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Les supports d'enregistrement mentionnés ci-avant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.
Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Ces dispositifs de traitement et d’enrichissement et ce programme d'ordinateur présentent des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec le procédé de traitement et d’enrichissement.
4. Liste des figures
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
La illustre un exemple d’environnement de mise en œuvre selon un mode particulier de réalisation de l’invention,
La illustre l’architecture d’un dispositif d’enrichissement mettant en œuvre l’invention selon un mode particulier de réalisation,
La illustre l’architecture d’un dispositif de traitement mettant en œuvre l’invention selon un mode particulier de réalisation,
La illustre des étapes des procédés d’enrichissement et de traitement selon un mode particulier de réalisation de l’invention.
5. Description d'un mode de réalisation de l'invention
La illustre un exemple d'environnement de mise en œuvre de l'invention selon un mode particulier de réalisation. L’environnement représenté en comprend un réseau de communication 100 auquel sont connectés des terminaux 101 et 105. Le réseau de communication 100 peut être un réseau de communications mobile avec un réseau d’accès de type GSM, EDGE, 3G, 3G+, 4G, 5G, WiFi, etc. ou un réseau de communication fixe avec réseau d’accès de type ADSL, Fibre, VDSL, Câble, WiFi, etc. Le réseau de communication 100 peut aussi être un réseau de communication IP mis en œuvre par une architecture de réseau VoIP (pour Voice over IP) de type IMS (IP Multimedia Subsystem) ou tout autre architecture de réseau par exemple de type NGN (pour Next Generation Network). Le réseau de communication 100 peut correspondre à un groupe de réseaux de communication d’opérateurs de télécommunications différents, interconnectés entre eux par l’intermédiaire de serveurs d’interconnexion ou bien un réseau de communication d’un seul opérateur.
Dans l’exemple décrit à l’appui de la , le réseau 100 correspond à un réseau NGN de communication d’un opérateur apte à faire communiquer un terminal appelant 101 et un terminal appelé 105. Ainsi, les serveurs 102, 103 et 104, représentent respectivement les serveurs du réseau NGN de l’opérateur de télécommunications de l’appelé. Le serveur 102 est par exemple un « Session Routeur » (SR) correspondant au serveur d’entrée du réseau de l’opérateur appelé. Le serveur 103 est par exemple un « Telephony Application Server » (TAS) apte à gérer les services téléphoniques de l’appelé tels que le service CLIP et le service CNIP/CNAP. Le serveur 104 est, par exemple un a-SBC (pour Access Session Border Controler), ou un P-CSCF (pour Proxy Call State Control Function).
Les terminaux 101 et 105 peuvent être tous types de terminaux permettant d’établir des sessions de communication de type téléphonique ou visiophonique et aptes à restituer à un utilisateur des informations obtenues via par exemple les services CLIP/CNIP. Les terminaux 101 et 105 peuvent correspondre à un téléphone portable, un téléphone fixe, un smartphone (téléphone intelligent en anglais), une tablette, une télévision connectée à un réseau de communication, un objet connecté, une voiture autonome, ou un ordinateur personnel.
Ces terminaux peuvent émettre et recevoir tous types de communications, via le réseau de communication 100. L’environnement représenté en comprend également deux espaces de stockage numérique, 106 et 107.
L’élément 106 est par exemple une base de données permettant de stocker des informations associées à un identifiant d’appelant. Ces informations sont par exemple des chaînes de caractères indiquant un nom, un surnom, une maxime, un slogan ou toute autre information en lien avec un appelant identifié via un identifiant d’appelant. Plus concrètement, une information telle que le nom d’un produit ou d’un service fourni par une entreprise est par exemple stockée dans la base de données 106 en lien avec l’identifiant de l’entreprise en question. Cette base de données est par exemple opérée par l’opérateur de télécommunications de l’appelé ou bien par un consortium d’opérateur de télécommunications.
L’identifiant de l’appelant peut par exemple être une donnée contenue dans l’entête FROM et/ou PAI du message de signalisation. A noter que l’entête FROM n’est pas certifié par l’opérateur de télécommunications de l’appelant contrairement à l’entête PAI.
Selon un mode particulier de réalisation de l'invention, les informations obtenues depuis la base de données 106 peuvent être fonction de l’identifiant de l’appelant mais aussi d’un ou plusieurs entêtes contenant des informations certifiées par l’opérateur de l’appelant, par exemple un entête IDENTITY permettant l’authentification du numéro d’appelant selon le standard STIR/Shaken défini à l’IETF (RFC 7340 / 8224 / 8225 / 8226 / 8588) ou un entête de localisation de l’appelant PANI (Private Access Network Info) présent dans le message de signalisation. Cette entête de localisation peut contenir un identifiant de l’opérateur appelant et/ou une information de localisation de l’accès de l’appelant (par exemple le code postal ou code INSEE de l’accès fixe xDSL/Fibre/Câble de l’appelant ou de l’antenne utilisée par le terminal mobile de l’appelant).
L’espace de stockage numérique 107 est par exemple une base de données qui permet également le stockage d’informations associées à un identifiant d’appelant. Ces informations peuvent être fournies par la communauté des utilisateurs et ce quel que soit leur opérateur de télécommunications ou bien par des organismes certifiés tels que des associations de consommateurs. Ces informations sont par exemple des chaînes de caractères permettant de qualifier l’appelant telles que « télémarketing », « arnaque », « acceptable », etc.
Selon un mode particulier de réalisation de l'invention, l’identifiant de l’appelant correspond à son numéro de téléphone.
Selon un mode particulier de réalisation de l'invention, l’identifiant de l’appelant correspond à son adresse de messagerie.
L’environnement de mise en œuvre de l'invention peut comprendre une troisième base de données opérée par le service CNIP/CNAP (non représentée dans la ). Cette base de données est par exemple comprise dans le serveur 103 (TAS) ou bien séparée du serveur 103 et située dans le réseau de l’opérateur de télécommunications de l’appelé.
La illustre un dispositif SR mettant en œuvre l’invention selon un mode particulier de réalisation. Le dispositif SR a l'architecture classique d'un ordinateur, et comprend notamment une mémoire MEM1, une unité de traitement UT1, équipée par exemple d'un processeur PROC1, et pilotée par le programme d'ordinateur PG1 stocké en mémoire MEM1. Le programme d'ordinateur PG1 comprend des instructions pour mettre en œuvre les étapes du procédé d’enrichissement tel que décrit ultérieurement à l’appui de la , lorsque le programme est exécuté par le processeur PROC1.
A l'initialisation, les instructions de code du programme d'ordinateur PG1 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC1. Le processeur PROC1 de l'unité de traitement UT1 met notamment en œuvre les étapes du procédé d’enrichissement selon l'un quelconque des modes particuliers de réalisation décrits en relation avec les figures 1 et 4, selon les instructions du programme d'ordinateur PG1.
Le dispositif SR comprend un module de communication RECV1 configuré pour recevoir des communications avec un réseau IP selon une technologie par exemple de Type Ethernet ou optique. Ce module de communication est utilisé pour recevoir un message de signalisation d’une communication en provenance d’un terminal appelant. Le dispositif SR comprend en outre un module SND1 apte à émettre un message de signalisation d’une communication à destination d’un terminal appelé. Le dispositif SR comprend également un module INS apte à insérer dans un premier entête du message de signalisation, une donnée obtenue en fonction d’un identifiant de l’appelant contenu dans le message de signalisation. De plus, le dispositif SR comprend un module ATTR apte à attribuer à un paramètre d’un deuxième entête du message de signalisation une valeur d’enrichissement.
Selon un mode particulier de réalisation de l'invention, le module INS est également apte à insérer dans un paramètre du premier entête du message de signalisation un identifiant de service, par exemple pour distinguer la provenance de données insérées dans le premier entête suite à la consultation de l’espace de stockage numérique 106 et/ou de l’espace de stockage numérique 107.
Selon un mode particulier de réalisation de l'invention, les modules SND1 et RECV1 sont un seul et même module de communication.
La illustre un dispositif a-SBC mettant en œuvre l’invention selon un mode particulier de réalisation. Le dispositif a-SBC a l'architecture classique d'un ordinateur, et comprend notamment une mémoire MEM2, une unité de traitement UT2, équipée par exemple d'un processeur PROC2, et pilotée par le programme d'ordinateur PG2 stocké en mémoire MEM2. Le programme d'ordinateur PG2 comprend des instructions pour mettre en œuvre les étapes du procédé de traitement tel que décrit ultérieurement à l’appui de la , lorsque le programme est exécuté par le processeur PROC2.
A l'initialisation, les instructions de code du programme d'ordinateur PG2 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC2. Le processeur PROC2 de l'unité de traitement UT2 met notamment en œuvre les étapes du procédé de traitement selon l'un quelconque des modes particuliers de réalisation décrits en relation avec les figures 1 et 4, selon les instructions du programme d'ordinateur PG2.
A l'initialisation, les instructions de code du programme d'ordinateur PG2 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC2. Le processeur PROC2 de l'unité de traitement UT2 met notamment en œuvre les étapes du procédé de traitement selon l'un quelconque des modes particuliers de réalisation décrits en relation avec les figures 1 et 4, selon les instructions du programme d'ordinateur PG2.
Le dispositif a-SBC comprend un module de communication RECV2 configuré pour recevoir des communications avec un réseau IP selon une technologie par exemple de Type Ethernet ou optique. Ce module de communication est utilisé pour recevoir un message de signalisation d’une communication en provenance d’un terminal appelant via par exemple un dispositif d’enrichissement tel que décrit à l’appui de la . Le dispositif a-SBC comprend en outre un module SND2 apte à émettre un message de signalisation d’une communication à destination d’un terminal appelé disposant de moyens pour restituer une information concernant l’appelant. Le dispositif a-SBC comprend également un module OBT apte à obtenir le contenu (par exemple une chaîne de caractères) d’un paramètre d’un deuxième entête du message de signalisation. En fonction de la valeur obtenue, par exemple si le contenu est vide ou comprend une valeur d’enrichissement insérée par un dispositif d’enrichissement, le module de modification MOD peut modifier le paramètre du second entête en fonction de la valeur d’un premier entête dudit message de signalisation.
Selon un mode particulier de réalisation de l'invention, les modules SND2 et RECV2 sont un seul et même module de communication.
Selon un mode particulier de réalisation de l'invention, le module MOD peut lorsqu’un paramètre du premier entête du message de signalisation comprend un identifiant de service, modifier le paramètre du deuxième entête avec une valeur du premier entête en fonction de la valeur d’un troisième entête du message de signalisation.
La illustre des étapes des procédés d’enrichissement et de traitement selon un mode particulier de réalisation de l’invention et décrit le cas particulier d’une communication SIP en lien avec l’environnement de la .
L’établissement d’une communication est par exemple mis en œuvre par le terminal 101 de la correspondant au terminal 410 de la .
La demande de communication est envoyée à l’étape 400 par le terminal appelant 410 via le réseau de l’opérateur appelant sous la forme d’un message SIP INVITE selon le protocole SIP. Le message SIP INVITE est ensuite reçu par le réseau de l’opérateur appelant et comprend notamment :
  • dans un champ, appelé « FROM » ou « PAI », un identifiant de l’émetteur de la demande de communication comme par exemple un numéro de téléphone ou une adresse de messagerie ;
  • dans un champ d’adresse destinataire de la demande de communication, appelé « To » et RURI (pour Request URI), un identifiant du destinataire (416) comme par exemple un numéro de téléphone ou une adresse de messagerie.
Lors de l’étape 401, la demande de communication est prise en charge par l’opérateur de l’appelé via son réseau NGN et plus particulièrement via le « session router » 411. Cet équipement met en œuvre le procédé d’enrichissement et est par exemple un équipement d’entrée de signalisation du réseau fixe/mobile de l’opérateur de l’appelé.
Suite à la réception du message de signalisation, le « session router » envoie une requête à un espace de stockage numérique 414 tel qu’une base de données (étape 402). Cette requête comprend au moins un identifiant de l’appelant présent dans le message de signalisation reçu. L’identifiant est par exemple contenu dans le champ SIP FROM et/ou dans le champ SIP PAI.
L’espace de stockage numérique 414 peut contenir des informations concernant l’appelant, par exemple, fournies par l’appelant lui-même ou bien par un opérateur de télécommunication. Cet espace de stockage numérique 414 permet par exemple de stocker, en association avec un identifiant d’une entreprise ou d’un particulier, une ou plusieurs chaînes de caractères comprenant le nom de l’entreprise ou du particulier, son slogan ou toute autre donnée que l’entreprise ou le particulier souhaite voir restituer (affichée et/ou vocalisée) sur le terminal de l’appelé. Lors de l’étape 403 la requête est reçue par l’espace de stockage numérique et une donnée est obtenue en fonction de l’identifiant de l’appelant et potentiellement en fonction d’autres entêtes présents dans le message de signalisation tels que l’entête PANI (Private Access Network Information), l’identifiant appelant certifié par l’opérateur de télécommunications de l’appelant PAI, un paramètre d’authentification de type STIR/Shaken présent dans l’entête SIP IDENTITY, etc.
Avantageusement, l’utilisation de ces entêtes en plus de l’identifiant de l’appelant permet de sécuriser le service, en particulier lorsque l’identifiant de l’appelant est une identité appelante non certifiée par le réseau de l’appelant.
Lors de l’étape 404, la donnée obtenue est ensuite transmise, en réponse à la requête puis reçue par le « session router » à l’étape 405.
Si la donnée obtenue n’est pas vide, alors celle-ci est insérée, par exemple, dans un entête SIP propriétaire du message de signalisation par le « session router » (étape 405).
L’entête SIP propriétaire est un premier entête au sens de l’invention.
Lors de l’étape 405, le « session router » insère ou attribue également au contenu du paramètre SIP DISPLAY de l’entête FROM et/ou PAI une valeur d’enrichissement telle qu’une chaine de caractères indiquant que le procédé d’enrichissement a enrichi le message de signalisation. Par exemple, la chaine de caractères peut contenir le nom de l’entête SIP propriétaire. A noter que si ce paramètre SIP DISPLAY contient une valeur initiale dans le message de signalisation reçu par le « session router », celle-ci est remplacée par la valeur d’enrichissement.
Le champ FROM et/ou PAI contenant le paramètre SIP DISPLAY est un deuxième entête au sens de l’invention.
Selon un mode particulier de réalisation de l'invention, le « session router » peut également insérer dans l’entête SIP propriétaire du message de signalisation un identifiant du service (par exemple le nom du service) qui opère l’espace de stockage numérique depuis lequel la donnée associée à l’identifiant de l’appelant a été obtenue.
Selon un mode particulier de réalisation de l'invention, le « session router » peut consulter plusieurs espaces de stockage numérique de plusieurs services (414, 415) afin d’obtenir plusieurs données en lien avec l’identifiant de l’appelant (étapes 422, 425). A noter que dans le cas où plusieurs données sont obtenues par le « session router » alors le procédé d’enrichissement peut sélectionner la donnée à insérer dans l’entête propriétaire en fonction de la provenance de la donnée, par exemple en fonction du service qui opère l’espace de stockage numérique. Bien entendu, le « session router » peut également insérer dans l’entête propriétaire une donnée qui comprend tout ou partie des données obtenues depuis les espaces de stockage numérique.
Selon un mode particulier de réalisation de l'invention, si l’entête SIP propriétaire n’est pas présent dans le message de signalisation, alors le « session router » ajoute l’entête SIP propriétaire au message de signalisation.
Selon un mode particulier de réalisation de l'invention, la donnée obtenue peut être insérée dans un entête SIP existant (défini dans les standards) ou dans un paramètre propriétaire d’un entête SIP existant du message de signalisation.
Lors de l’étape 406, le message de signalisation est envoyé par le « session router » et est reçu à l’étape 407 par le serveur 412. Ce serveur est par exemple un serveur d’application téléphonique ou TAS (pour « Telephony Application Server » en anglais). De manière connue, ce serveur est apte à traiter les services téléphoniques de l’appelé. Plus précisément ce serveur peut fournir les services CLIP et CNIP/CNAP de l’appelé. Ainsi, ce serveur modifie le message de signalisation en fonction du statut des services CLIP et CNIP/CNAP (actif /non actif) de l’appelé. A noter que lorsque le service CNIP est activé alors cela indique que le service CLIP l’est également.
De manière connue, lorsque le service CLIP de l’appelé est activé, alors le contenu de l’entête FROM et/ou PAI n’est pas modifié. Dans le cas où l’appelé ne dispose pas du service CLIP activé, alors le paramètre SIP URI de l’entête FROM et/ou PAI, qui comprend un identifiant de l’appelant dont le format est par exemple du type « sip :numtel@fai.fr » dans lequel le champ « numtel » (également appelé userpart) correspond à un identifiant de l’appelant et « fai » correspond à un identifiant de l’opérateur de télécommunications de l’appelant, est modifié.
Concrètement, la partie « userpart » du paramètre SIP URI de l’entête FROM est alors supprimée par le serveur d’application téléphonique 412 et seule la valeur @fai.fr est transmise à l’appelé via l’entête FROM et/ou PAI.
Lorsque les services CLIP et CNIP/CNAP de l’appelé sont actifs, que l’entête SIP Privacy du message de signalisation comprend la valeur « None » et que l’entête FROM ne contient pas la valeur sip :anonymous@anonymous.invalid, c’est-à-dire que l’appel n’est pas un appel de type anonyme, alors le serveur d’application téléphonique 412 consulte la base de données du service CNIP/CNAP (non représenté) avec en paramètre l’identifiant de l’appelant (par exemple le numéro de téléphone contenu dans l’entête FROM ou PAI).
Si l’identifiant de l’appelant est présent dans la base de données du service CNIP/CNAP, alors une information associée à l’identifiant de l’appelant est envoyée en retour au serveur d’application téléphonique 412 puis insérée par celui-ci dans le paramètre SIP DISPLAY de l’entête FROM et/ou PAI. L’information obtenue depuis la base de données du service CNIP/CNAP est par exemple le nom de l’appelant (cas où l’appelant est également client de l’opérateur de l’appelé). Dans le cas contraire, si l’identifiant de l’appelant n’est pas présent dans la base de données du service CNIP/CNAP, alors le paramètre SIP DISPLAY de l’entête FROM et/ou PAI est modifié pour correspondre à une chaîne de caractère vide.
Dans le cas où le service CNIP/CNAP de l’appelé n’est pas activé alors la base de données CNIP/CNAP n’est pas consultée et le contenu du paramètre SIP DISPLAY de l’entête FROM et/ou PAI n’est pas modifié et contient la valeur d’enrichissement positionnée par le « session router » lors de l’étape 405.
Le message de signalisation est ensuite envoyé (étape 408) par le serveur d’application téléphonique puis reçu lors de l’étape 409 par le serveur 413. Le serveur 413 est par exemple un serveur de type a-SBC qui met en œuvre le procédé de traitement. Lors de la réception du message de signalisation, celui-ci détermine comment le paramètre SIP DISPLAY de l’entête FROM et/ou PAI doit être traité avant de transmettre le message de signalisation de l’appel au terminal fixe ou mobile de l’appelé. Cette détermination est réalisée en fonction du contenu des entêtes du message de signalisation. On rappelle que c’est le contenu du paramètre SIP DISPLAY de l’entête FROM et/ou PAI selon la règlementation du pays de l’appelé qui est restitué sur le terminal de l’appelé lors de l’établissement d’une communication. On rappelle également que le terminal de l’appelé peut disposer de moyens pour restituer le contenu du paramètre SIP DISPLAY en plus du numéro de l’appelant. Plusieurs cas sont donc possibles.
Si le paramètre SIP DISPLAY de l’entête FROM et/ou PAI ne contient pas la valeur d’enrichissement attribuée par le dispositif d’enrichissement lors de l’étape 405 et ne contient pas une chaîne de caractères vide, alors cela signifie que le service CNIP/CNAP de l’appelé est activé et qu’une information associée à l’identifiant de l’appelant a été trouvée. Dans ce cas le procédé de traitement peut ne pas modifier le message de signalisation.
Si la chaîne de caractère contenue dans le paramètre SIP DISPLAY de l’entête FROM et/ou PAI est vide, alors cela signifie que le service CNIP/CNAP de l’appelé est activé mais qu’aucune information associée à l’identifiant de l’appelant n’a été trouvée dans la base de données du service CNIP/CNAP. Le procédé de traitement vérifie alors que le contenu de l’entête propriétaire (chaîne de caractères) est vide. Si c’est le cas alors le procédé de traitement ne modifie pas le message de signalisation. Dans le cas contraire le procédé de traitement modifie le paramètre SIP DISPLAY du champ FROM et/ou PAI afin d’y inclure toute ou partie du contenu de l’entête propriétaire. Le message de signalisation est ensuite envoyé à destination du terminal de l’appelé (416).
Si la chaîne de caractère contenue dans le paramètre SIP DISPLAY de l’entête FROM et/ou PAI contient la valeur d’enrichissement attribuée par le dispositif d’enrichissement lors de l’étape 405, alors cela signifie que le service CNIP/CNAP de l’appelé n’est pas activé. Le procédé de traitement vérifie que le contenu de l’entête propriétaire (chaîne de caractères) est vide et c’est le cas alors le procédé de traitement modifie le paramètre SIP DISPLAY du champ FROM et/ou PAI avec une chaîne de caractères vide de sorte à ne pas afficher sur le terminal appelé une information technique. Dans le cas contraire le procédé de traitement modifie le paramètre SIP DISPLAY du champ FROM et/ou PAI afin d’y inclure toute ou partie du contenu de l’entête propriétaire. Le message de signalisation est ensuite envoyé à destination du terminal de l’appelé (416).
Avantageusement, ce procédé permet au serveur a-SBC de ne pas avoir besoin d’être connecté à un ou plusieurs autres équipements de l’opérateur de télécommunications de l’appelé afin de fournir à l’appelé la meilleure information de qualification de l’appelant possible en fonction de l’état (actif/ non actif) du service CNIP/CNAP de l’appelé.
Selon un mode particulier de réalisation de l'invention, le procédé de traitement peut lorsque le contenu de l’entête propriétaire comprend un identifiant de service (par exemple le nom du service), modifier le contenu du paramètre SIP DISPLAY de l’entête FROM et/ou PAI en fonction du contenu (par exemple de la chaîne de caractères) du paramètre SIP URI de l’entête FROM et/ou PAI. Concrètement, lorsque la partie « userpart » du paramètre SIP URI de l’entête FROM et/ou PAI correspond à une chaîne de caractères vide alors le contenu du paramètre SIP DISPLAY de l’entête FROM et/ou PAI est supprimé par le procédé de traitement. Dans le cas contraire, le procédé insère toute ou partie du contenu de l’entête propriétaire au niveau du paramètre SIP DISPLAY du champ FROM et/ou PAI.
Avantageusement, un tel procédé permet au serveur a-SBC d’insérer ou non l’information de qualification de l’appelant fournie par le dispositif d’enrichissement en fonction par exemple de l’état du service CLIP (activé/désactivé). En effet, la règlementation de certains pays impose de proposer à l’appelé la possibilité d’activer/désactiver la restitution de l’information de qualification de l’appelant. Ainsi, un tel procédé se base sur une logique applicative déjà existante, celle du service CLIP, et permet d’éviter des coûts et des délais de développements supplémentaires.
Ainsi, le serveur a-SBC (413) détermine selon le contenu du paramètre SIP DISPLAY de l’entête FROM et/ou PAI reçu et potentiellement du contenu du « userpart » de l’entête FROM et/ou PAI s’il doit insérer le contenu d’un entête SIP propriétaire dans le paramètre SIP DISPLAY de l’entête FROM et/ou PAI du message de signalisation émis (étape 409b) à destination du terminal fixe ou mobile de l’appelé.
Selon un mode particulier de réalisation de l'invention, le procédé de traitement peut supprimer le premier entête avant de transmettre le message de signalisation à destination du terminal fixe ou mobile de l’appelé.
Selon un mode particulier de réalisation de l'invention, le dispositif d’enrichissement peut être localisé dans n’importe quel équipement réseau de l’opérateur appelant ou de transit (par exemple un serveur IBCF pour Interconnect Border Control Function en anglais) ou de l’opérateur de l’appelé traitant le message de signalisation avant le serveur TAS de l’opérateur de l’appelé. Ainsi, le dispositif d’enrichissement peut être :
- pour une architecture de type IMS, un serveur NBI (Network Border Infrastrusture), I-CSCF (Interrogating Call State Control Function), S-CSCF (Serving Call Session Control Function) ou un serveur d’application (AS).
- pour une architecture de type NGN, un serveur NBI, SR (Session Router) ou un serveur d’application.
- pour une architecture circuit fixe, un CAA arrivée (Commutateur à Autonomie d’Acheminement) ou une plate-forme de réseau Intelligent utilisant le protocole INAP (Intelligent Network Application Part), PBX (RNIS).
- pour une architecture circuit mobile, un serveur GMSC (Gateway Mobile Switch Center), VMSC (Visited Mobile Switch Center), une plate-forme de réseau intelligent utilisant le protocole CAMEL (Customized Application for Mobile Enhanced Logic) ou INAP.
Selon un mode particulier de réalisation de l'invention, le dispositif de traitement peut être localisé dans n’importe quel équipement réseau de l’opérateur de l’appelé traitant le message de signalisation après le serveur TAS de l’opérateur de l’appelé. Ainsi, le dispositif de traitement peut être :
- pour une architecture de type IMS, un serveur S-CSCF, P-CSCF, A-SBC, une passerelle domestique SIP, un terminal appelé SIP ou un serveur d’application ;
Pour une architecture de type NGN, un serveur A-SBC, une passerelle domestique SIP, un terminal appelé SIP ou un serveur d’application ;
- pour une architecture circuit fixe, un CAA arrivée (Commutateur à Autonomie d’Acheminement) ou une plate-forme de réseau Intelligent utilisant le protocole INAP, PBX (RNIS) ;
- pour une architecture circuit mobile, un serveur GMSC (Gateway Mobile Switch Center), VMSC (Visited Mobile Switch Center), une plate-forme de réseau intelligent utilisant le protocole CAMEL ou INAP.
Selon un mode particulier de réalisation de l'invention, le dispositif d’enrichissement peut être localisé dans le TAS mais dans ce cas le procédé d’enrichissement doit être exécuté avant l’exécution des logiques des services CNIP/CNAP/CLIP et le procédé de traitement exécuté après l’exécution des logiques des services CNIP/CNAP/CLIP.
Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l’homme de l’art sans pour autant sortir du cadre de l’invention.
Par exemple, le procédé d’enrichissement peut être réparti sur deux serveurs distincts. Le premier serveur (par exemple le « session router ») peut recevoir le message de signalisation puis réaliser l’étape d’attribution d’une valeur d’enrichissement à un paramètre d’un deuxième entête du message de signalisation tel que le paramètre SIP DISPLAY de l’entête FROM avant d’émettre le message de signalisation, par exemple, à destination d’un deuxième serveur de type TAS apte à exécuter les services CNIP/CNAP/CLIP. Une fois les services CNIP/CNAP/CLIP exécutés, le serveur TAS émet le message à destination d’un troisième serveur (par exemple le serveur a-SBC) qui réalise de manière conditionnelle et optimale en fonction du contenu du paramètre du deuxième entête du message de signalisation l’étape d’insertion dans un premier entête du message de signalisation d’au moins une donnée obtenue en fonction d’une identité de l’appelant contenue dans le message de signalisation reçu. En effet, il n’est par exemple pas utile de consulter la/les bases de données de qualification du numéro appelant si le paramètre SIP DISPLAY de l’entête FROM et/ou PAI contient une données fournie par le service CNIP. Bien entendu, le troisième serveur peut également exécuter par la suite le procédé de traitement tel que décrit précédemment.
De même, les procédés d’enrichissement et de traitement peuvent utiliser un premier entête existant et standardisé ou un paramètre propriétaire d’un premier entête existant et standardisé pour transporter la donnée obtenue en fonction de ladite au moins une identité reçue.

Claims (8)

  1. procédé d’enrichissement d’au moins un message de signalisation d’une communication émis par un premier terminal d’un premier utilisateur à destination d’un second terminal d’un second utilisateur, ledit procédé étant mis en œuvre par un dispositif d’enrichissement et caractérisé en ce qu’il comprend :
    - une étape de réception (401) dudit au moins un message de signalisation comprenant au moins une identité dudit premier utilisateur ;
    - une étape d’insertion (405) dans un premier entête dudit au moins un message de signalisation d’au moins une donnée obtenue en fonction de ladite au moins une identité reçue ;
    - une étape d’attribution (405) d’une valeur d’enrichissement à un paramètre d’un deuxième entête dudit au moins un message de signalisation ;
    - une étape d’émission (406) dudit message de signalisation vers ledit au moins un second terminal.
  2. Procédé selon la revendication 1 dans lequel un identifiant de service est en outre inséré dans ledit premier entête.
  3. Procédé de traitement d’au moins un message de signalisation d’une communication émis par un premier terminal d’un premier utilisateur à destination d’un second terminal d’un second utilisateur, ledit procédé étant mis en œuvre par un dispositif de traitement et caractérisé en ce qu’il comprend :
    - une étape de réception (409) dudit au moins un message de signalisation ;
    - une étape d’obtention (409) du contenu d’un paramètre d’un deuxième entête dudit au moins un message de signalisation comprenant une chaîne de caractères ;
    et lorsque ladite chaîne de caractères est vide ou correspond à une valeur d’enrichissement insérée par un dispositif d’enrichissement
    -une étape de modification (409) dudit paramètre dudit deuxième entête en fonction de la valeur d’un premier entête dudit message de signalisation ;
    - une étape d’émission (409b) dudit message de signalisation vers ledit au moins un second terminal.
  4. Procédé selon la revendication 3 dans lequel ledit paramètre dudit deuxième entête est en outre modifié en fonction de la valeur d’un troisième entête dudit message de signalisation.
  5. Procédé selon la revendication 4 dans lequel ledit paramètre dudit deuxième entête est modifié en fonction de la valeur d’un troisième entête dudit message de signalisation lorsque ledit premier entête dudit message de signalisation comprend un identifiant de service.
  6. Dispositif d’enrichissement d’au moins un message de signalisation d’une communication émis par un premier terminal d’un premier utilisateur à destination d’un second terminal d’un second utilisateur, ledit dispositif étant caractérisé en ce qu’il comprend :
    - un module de réception (RECV1) dudit au moins un message de signalisation comprenant au moins une identité dudit premier utilisateur ;
    - un module d’insertion (INS) dans un premier entête dudit au moins un message de signalisation d’au moins une donnée obtenue en fonction de ladite au moins une identité reçue ;
    - un module d’attribution (ATTR) d’une valeur d’enrichissement à un paramètre d’un deuxième entête dudit au moins un message de signalisation ;
    - un module d’émission (SND1) dudit message de signalisation vers ledit au moins un second terminal.
  7. Dispositif de traitement d’au moins un message de signalisation d’une communication émis par un premier terminal d’un premier utilisateur à destination d’un second terminal d’un second utilisateur, ledit traitement étant caractérisé en ce qu’il comprend :
    - un module de réception (RECV2) dudit au moins un message de signalisation ;
    - un module d’obtention (OBT) du contenu d’un paramètre d’un deuxième entête dudit au moins un message de signalisation sous forme d’une chaîne de caractères ;
    - un module de modification (MOD) dudit paramètre dudit deuxième entête en fonction de la valeur d’un premier entête dudit message de signalisation ;
    - un module d’émission (SND2) dudit message de signalisation vers ledit au moins un second terminal.
  8. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 2 ou 3 à 5, lorsque le programme est exécuté par un processeur.
FR2103531A 2021-04-07 2021-04-07 Procédés et dispositifs d’enrichissement et de traitement d’un message de signalisation Pending FR3121808A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR2103531A FR3121808A1 (fr) 2021-04-07 2021-04-07 Procédés et dispositifs d’enrichissement et de traitement d’un message de signalisation

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2103531 2021-04-07
FR2103531A FR3121808A1 (fr) 2021-04-07 2021-04-07 Procédés et dispositifs d’enrichissement et de traitement d’un message de signalisation

Publications (1)

Publication Number Publication Date
FR3121808A1 true FR3121808A1 (fr) 2022-10-14

Family

ID=76523062

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2103531A Pending FR3121808A1 (fr) 2021-04-07 2021-04-07 Procédés et dispositifs d’enrichissement et de traitement d’un message de signalisation

Country Status (1)

Country Link
FR (1) FR3121808A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105812596B (zh) * 2014-12-31 2019-08-27 中国移动通信集团公司 一种ims网络中主叫号码显示方法、相关装置及系统
US20200252503A1 (en) * 2019-02-04 2020-08-06 Comcast Cable Communications, Llc Systems and methods for processing calls

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105812596B (zh) * 2014-12-31 2019-08-27 中国移动通信集团公司 一种ims网络中主叫号码显示方法、相关装置及系统
US20200252503A1 (en) * 2019-02-04 2020-08-06 Comcast Cable Communications, Llc Systems and methods for processing calls

Similar Documents

Publication Publication Date Title
EP3417591B1 (fr) Procédé et serveur de sélection d'un serveur d'entrée d'un réseau de communication ims
WO2013057437A1 (fr) Procede d'echange d'informations relatives a des services de communication enrichie
EP2080345B1 (fr) Procede de gestion d'identites publiques dans un reseau de transmission d'informations, serveur de gestion d'enregistrements d'identites publiques, equipement de gestion d'une identite publique de groupe et programmes d'ordinateur correspondants
EP3754956B1 (fr) Méthode, dispositif et programme d'ordinateur pour déterminer l'usurpation de l'identifiant de l'appelant
WO2015150674A1 (fr) Procede de detection d'une usurpation d'identite appartenant a un domaine
EP3466042B1 (fr) Procédé de qualification de l'identité d'un terminal appelant
FR3121808A1 (fr) Procédés et dispositifs d’enrichissement et de traitement d’un message de signalisation
EP3469785A1 (fr) Procédé d'enrichissement d'une signalisation d'une communication et dispositif
EP1974534B1 (fr) Procédé et dispositif de gestion des communications personnelles d'au moins un utilisateur
WO2012085429A2 (fr) Procédé de localisation et d'identification d'un abonné connecté à un réseau émulant le rtc/rnis
WO2021260306A1 (fr) Procédé et dispositif d'enrichissement d'un message de signalisation d'une communication
FR3123529A1 (fr) Procédé de traitement d’un appel téléphonique dans un réseau de communication, procédé d’émission, procédé de réception d’un tel appel, dispositifs, système et programmes d’ordinateur correspondants.
EP3337208B1 (fr) Procédé et dispositif de transmission d'un message
EP3391615A1 (fr) Procede de communication entre un terminal appelant et une pluralite de terminaux appeles
WO2021260307A1 (fr) Procédé et dispositif de transformation d'un message de signalisation d'une communication
WO2015128561A1 (fr) Procede et dispositif de decouverte des capacites de communication relatives a un utilisateur d'un terminal
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
EP4258137A1 (fr) Procédé de distribution de fichier entre systèmes 3gpp mcdata interconnectés
FR2985135A1 (fr) Procede de propagation des associations entre adresses de contact et identites privees dans un reseau ip.
FR2895863A1 (fr) Procede et dispositif de gestion des communications personnelles d'au moins un utilisateur
EP2248333A1 (fr) Procede de gestion d'une session de communication au niveau d'une passerelle domestique
FR2895862A1 (fr) Procede et dispositif de gestion des communications personnelles d'au moins un utilisateur
FR2909501A1 (fr) Procede et systeme de telecommunication permettant a au moins deux utilisateurs distinct d'acceder a un meme ensemble d'informations
FR2887727A1 (fr) Procede de personnalisation de la carte de visite d'un appele selon l'identite d'un appelant
FR2972092A1 (fr) Procede de gestion d'identites publiques par un utilisateur d'un reseau ims

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20221014

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4