FR2886797A1 - Procede de communication entre un point de commande de services d'un reseau intelligent et un serveur externe, point de commande, serveur externe, systeme et programmes d'ordinateur associes - Google Patents

Abstract

Procédé de communication entre un PCS (5) d'un réseau de communication intelligent (1 ) et un serveur externe (10) d'une unité de fourniture de services (12) comportant des terminaux utilisateurs (TB, TC) du réseau, comprenant les étapes suivantes, suite à la réception par le PCS d'une requête de traduction d'un identifiant générique fourni par un premier terminal utilisateur (TA) du réseau (1):- transmission par le PCS au serveur externe, d'un premier message « INVITE» (I1) indiquant l'identifiant générique ;- transmission du serveur externe (10) au PCS (5) d'un second message « INVITE» (I2) indiquant un identifiant d'un terminal utilisateur (TB) de l'unité résultant d'une traduction effectuée par le serveur externe ;- réception par le PCS du second message « INVITE » et détermination d'une commande destinée au réseau pour établir une communication entre lesdits terminaux utilisateurs (TA, TB) ;lesdits messages « INVITE » étant conformes au protocole SIP.

Description

PROCEDE DE COMMUNICATION ENTRE UN POINT DE COMMANDE DE

SERVICES D'UN RESEAU INTELLIGENT ET UN SERVEUR EXTERNE, POINT DE COMMANDE, SERVEUR EXTERNE, SYSTEME ET PROGRAMMES D'ORDINATEUR ASSOCIES La présente invention concerne le domaine des réseaux de télécommunications de type Réseaux Intelligents (RI).

L'architecture RI vise à permettre une plus grande facilité d'introduction de nouveaux services dans les réseaux de télécommunications. Les services fournis par les réseaux RI sont par exemple les numéros de libre appel nommés en France numéros verts (numéros spécifiques permettant d'inverser la taxation, l'usager recevant les appels les prenant en charge), les numéros 0800 (numéros avec des taxations spéciales) etc. Les réseaux RI sont décrits dans A network architecture concept for the 1990s , de R.J.

Haas, R.W. Humes, International Switching Symposium 87, Phoenix, et ont été normalisés par l'Union Internationale des Télécommunications (UIT-T).

L'architecture RI a été initialement mise en oeuvre sur des réseaux téléphoniques commutés (RTC) comprenant des commutateurs reliés entre eux par des artères de transmission. Son principe, où la logique de service est déportée sur un serveur spécifique (dit "serveur d'application") indépendant de l'entité qui réalise le routage des appels, est destiné à être appliqué à tous les réseaux de communications, notamment les réseaux NGN ( Next Generation Network ) dans lesquels, contrairement aux réseaux RTC, les signaux de signalisation d'appel suivent un chemin différent des signaux de parole.

L'architecture fonctionnelle du réseau mettant en oeuvre une architecture RI peut être répartie schématiquement en plusieurs types de fonctions: les fonctions de transport classique temps réel du réseau de télécommunications mises en oeuvre notamment dans le cas d'un réseau RTC par l'intermédiaire des commutateurs du réseau organisés de façon hiérarchique et des terminaux utilisateurs; les fonctions temps réel nouvelles du RI, mises en oeuvre d'une part par des adaptations sur certains des commutateurs qui sont alors nommés Commutateurs 30 d'Accès aux Services (CAS) ou Service Switching Point (SSP) en anglais, et d'autre part par de nouvelles ressources nommées périphériques intelligents; - les fonctions de commande du RI comprenant la logique de service située dans un serveur (ou point) de commande du service (PCS) ou Service Control Point (SCP) en anglais, et les bases de données; les fonctions de gestion du RI comprenant la gestion de la logique et des données, de l'accès par les utilisateurs et de la création de services.

Les évolutions logicielles à mettre en oeuvre lors de l'introduction de nouveaux services sont ainsi concentrées principalement dans le PCS.

L'invention concerne plus particulièrement les réseaux intelligents dans lequel le PCS abritant la logique de commandes RI est interfacé avec au moins un serveur externe adapté pour définir le destinataire effectif d'un appel. Un tel serveur externe est généralement interfacé avec une plate-forme de fourniture de services (par exemple le service après-vente d'un constructeur) comportant plusieurs interlocuteurs possibles, tels que des téléconseillers, des menus vocaux etc. Lorsqu'un appelant A compose sur son téléphone un numéro générique de service intelligent par exemple un numéro générique de type de libre appel ou numéro 0800, etc. correspondant par exemple au service après-vente du constructeur, le PCS identifie le serveur externe interfacé à la plate-forme de service désignée par ce numéro générique et lui transmet le numéro.

Le serveur externe le traduit en un numéro d'abonné d'un terminal utilisateur utilisé par un des interlocuteurs de la plate-forme, en fonction du numéro composé par l'appelant et éventuellement de critères divers tels que l'origine de l'appel, l'heure, la date, la charge des divers interlocuteurs potentiels de la plate-forme. Le numéro ainsi déterminé du terminal destinataire effectif de l'appel initié par A est alors fourni par le serveur externe au PCS pour que ce dernier commande l'établissement de l'appel entre l'appelant et le destinataire désigné par le serveur externe.

Ces serveurs externes sont nommés ci-après serveurs externes de routage.

Un inconvénient rencontré est qu'il existe de nombreux protocoles d'échange différents entre PCS et serveurs externes de routage. Ces protocoles sont en général des protocoles propriétaires choisis en fonction de la technologie des centres d'appels auxquels sont généralement interfacés les serveurs externes de routage.

Or cette hétérogénéité est un obstacle important au développement d'un nouveau service RI faisant appel aux serveurs externes. En effet, l'implémentation d'une nouvelle fonctionnalité dans les échanges entre PCS et serveurs externes de routage doit se décliner en autant de versions que de protocoles différents.

On connaît par ailleurs le protocole SIP (en anglais session initiation protocol ) qui est un protocole d'ouverture de session utilisé pour établir, modifier et terminer, dans un réseau IP ( Internet Protocol ), une session de communication multimédia, classiquement un appel téléphonique ou encore une communication de visiophonie, un échange de texte... La RFC 3261 publiée en juin 2002 par l'Internet Engineering Task Force (IETF) définit le protocole SIP.

Plus précisément, le protocole SIP permet à deux interlocuteurs A' et B', appelés User Agent (UA) de se découvrir et de s'entendre sur les caractéristiques de la session de communication multimédia qu'ils entendent ouvrir, indépendamment des protocoles de transport mis en oeuvre dans la session elle-même, et indépendamment du type de session finalement établie, la session de communication multimédia étant ensuite établie entre A' et B'.

Le protocole SIP est donc mis en oeuvre au sein d'un réseau IP dans des échanges entre les deux UA A' et B', préalablement à l'ouverture d'une session de communication de données multimédias telle qu'un appel téléphonique entre ces deux UA, puis, le cas échéant, au cours de la communication pour modifier le type de session une fois la session établie, puis pour clôturer la session de communication.

Généralement, comme représenté en figure 1, l'interlocuteur A' souhaitant ouvrir une session de communication avec l'interlocuteur B', le terminal de l'utilisateur A' envoie une requête d'invitation, nommée INVITE , au destinataire B' pour lui faire part de son souhait de communiquer et par conséquent d'ouvrir une session de communication. Cette requête INVITE fournit en outre au destinataire B' un certain nombre d'informations comprenant notamment un identifiant unique de transaction, l'adresse IP du destinataire B', l'adresse IP de l'appelant A' et des données sur le type de session de communication que l'appelant A' souhaite établir avec le destinataire B'.

Dans certains cas, avant de parvenir au destinataire B', la requête INVITE émise par l'appelant A est transmise à un ou plusieurs intermédiaires (généralement des serveurs proxy).

Suite à l'envoi de cette requête INVITE , lorsque la requête est d'abord reçue par un intermédiaire qui la fait suivre à destination du destinataire final B', l'appelant A' reçoit en outre de la part de cet intermédiaire un message (message 100Trying ) l'informant que l'intermédiaire a bien reçu la requête et l'a transmise au destinataire B'.

Lorsque le terminal du destinataire B' reçoit la requête d'invitation et la notifie à l'utilisateur B', il émet à destination de l'appelant A' un message destiné à informer ce dernier de cette notification. Un tel message est nommé 180Ringing .

Si l'interlocuteur B' décide de répondre positivement à la requête d'ouverture de session de communication, son terminal envoie à l'interlocuteur A' un message nommé 200 OK qui indique le type de session que l'interlocuteur B' souhaite établir avec l'interlocuteur A' (s'il avait décidé de répondre par la négative, un message d'erreur aurait alors été envoyé à la place du message 200 OK et aucune session de communication n'aurait été établie par la suite). Puis l'interlocuteur A' envoie un message d'acquittement ( ACK ) à l'interlocuteur B'. L'établissement effectif de la session a alors lieu conformément aux caractéristiques convenues indiquées dans le message 200 OK , les terminaux ouvrent alors les ports multimédias, activent les codeurs/décodeurs et des paquets de données multimédias sont alors échangés entre les interlocuteurs A' et B'.

A la fin des échanges, un message BYE est envoyé par le dispositif de l'utilisateur, par exemple l'utilisateur B', qui a provoqué la fin de la communication multimédia. L'autre utilisateur, dans ce cas l'utilisateur A', répond en envoyant un message 200OK .

Avantageusement, l'invention vise à proposer une solution pour qu'un PCS et un serveur externe de routage d'un RI puissent communiquer, qui soit aisée à mettre en oeuvre et qui donc facilite l'uniformisation des interfaces entre PCS et serveurs externes de routage.

Plus précisément, l'invention propose, suivant un premier aspect, un procédé de communication entre un serveur de commande de service d'un réseau de communication et un serveur externe, ledit serveur externe étant relié par une liaison de communication à une unité de fourniture de services comportant plusieurs terminaux utilisateurs du réseau de communication. Ledit procédé comprend les étapes suivantes: a) transmettre, sur réception d'une requête de service d'un premier terminal utilisateur, depuis le serveur de commande de service à destination du serveur externe, un premier message d'ouverture de session, conforme à un protocole d'ouverture de session, indiquant l'identifiant du premier terminal utilisateur en tant que terminal émetteur; b) transmettre depuis le serveur externe à destination du serveur de commande de service, un deuxième message d'ouverture de session conforme audit protocole indiquant l'identifiant du premier terminal utilisateur en tant que terminal émetteur et l'identifiant d'un terminal utilisateur de l'unité en tant que terminal récepteur; c) détecter un lien entre le premier message d'ouverture de session et le deuxième message d'ouverture de session, ledit lien découlant de la présence de l'identifiant du premier terminal utilisateur dans les deux messages; d) déterminer en fonction du deuxième message d'ouverture de session au moins une commande de services, destinée au réseau de communication, pour l'établissement d'une communication entre le premier terminal utilisateur et le terminal utilisateur de l'unité.

Ainsi l'invention propose une solution avantageuse pour échanger des informations entre un PCS et un serveur externe, basée sur un protocole standard, le protocole SIP, dédié à l'établissement de sessions multimédia sur l'Internet, à des fins non prévues par ce protocole, à savoir l'établissement d'une session de communication entre un terminal d'utilisateur appelant et un terminal d'utilisateur destiné à fournir un service, via un PCS et un serveur externe de routage, à travers un réseau intelligent. L'invention favorise ainsi une uniformisation des interfaces entre PCS et serveurs externes et facilite la mise en place de nouveaux services dans les réseaux intelligents.

La requête à un service est une requête pour la traduction d'un identifiant générique. L'identifiant générique est l'identifiant d'un service. Il n'est pas un identifiant d'un terminal utilisateur du réseau. Il est représentatif d'un service apte à être fourni par une pluralité de terminaux utilisateurs faisant partie d'une même entité de fourniture de services.

Le protocole SIP est mis en oeuvre entre le PCS et le serveur externe de routage, non pas pour échanger des informations pour convenir d'une session de communication multimédia à établir entre le PCS et le serveur externe, mais pour échanger les informations visant à établir un appel entre un appelant A et un destinataire B, ce destinataire B étant déterminé par le serveur externe de routage au cours de ces échanges en fonction d'un numéro générique de service fourni par l'appelant A au PCS. Au cours de l'appel, le destinataire B peut varier, i.e. l'appelant A peut être mis en relation avec différents interlocuteurs successivement, afin de rendre le service souhaité.

Suivant un second aspect, l'invention propose un serveur de commande de services d'un réseau de communication en liaison avec un serveur externe interfacé par une liaison de communication à une unité de fourniture de services comportant des terminaux utilisateurs du réseau de communication, comprenant des moyens pour mettre en oeuvre les étapes qui incombent au serveur de commande de services d'un procédé suivant le premier aspect de l'invention.

Suivant un troisième aspect, l'invention propose un serveur externe relié à un serveur de commande de services d'un réseau de communication interfacé par une liaison de communication à une unité de fourniture de services comportant des terminaux utilisateurs du réseau de communication, comprenant des moyens pour mettre en oeuvre les étapes, qui incombent au serveur externe, d'un procédé suivant le premier aspect de l'invention.

Suivant un quatrième aspect, l'invention propose un programme d'ordinateur à installer dans un serveur de commande de services d'un réseau de communication relié à un serveur externe interfacé par une liaison de communication à une unité de fourniture de services comportant des terminaux utilisateurs du réseau de communication. Ce programme d'ordinateur comprend des instructions pour mettre en oeuvre les étapes qui incombent au serveur de commande de services, d'un procédé suivant le premier aspect de l'invention lors d'une exécution du programme par des moyens de traitement dudit point de commande.

Suivant un cinquième aspect, l'invention propose un programme d'ordinateur à installer dans un serveur externe relié à un serveur de commande de services d'un réseau de communication interfacé par une liaison de communication à une unité de fourniture de services comportant des terminaux utilisateurs du réseau de communication. Ce programme d'ordinateur comprend des instructions pour mettre en oeuvre les étapes qui incombent au serveur externe, d'un procédé suivant le premier aspect de l'invention lors d'une exécution du programme par des moyens de traitement dudit serveur externe.

Suivant un sixième aspect, l'invention propose un système de communication comportant: - un serveur de commande de service, selon le premier aspect de l'invention, d'un réseau de communication; - un serveur externe selon le second aspect de l'invention, relié 30 au serveur de commande de service; au moins une unité de fourniture de services, reliée au serveur externe par une liaison de communication, comportant une pluralité de terminaux utilisateurs du réseau de communication.

D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels: - la figure 1 représente schématiquement des échanges mis en oeuvre dans l'art antérieur conformément au protocole SIP; - la figure 2 illustre un réseau intelligent 1 dans un mode de réalisation de l'invention; - la figure 3a illustre des échanges entre un PCS et un serveur externe dans un mode de réalisation de l'invention; - la figure 3b illustre des échanges entre un PCS et un serveur externe dans un mode de réalisation de l'invention.

Sur la figure 2 est représenté un réseau RTC 1 présentant une architecture RI. Le réseau 1 comporte des commutateurs organisés de façon hiérarchique. Les commutateurs d'abonnés (CAA) sont reliés aux terminaux utilisateurs T des utilisateurs du réseau 1. Les CAA sont eux-mêmes reliés entre eux par des commutateurs de transit (CT). De façon connue, les communications entre CAA et CT ont lieu conformément au protocole ISUP ( ISDN User Part ).

Trois commutateurs du réseau 1 ont été représentés sur la figure 2: les commutateurs CAA 2 et 3 et le commutateur de transit (CT) 4 qui comporte une fonction CAS, relié à chacun des CAA 2, 3.

Le réseau 1 comporte en outre un serveur de commande de services RI (PCS) 5. Le PCS 5 comporte un module d'interprétation 5.1 et un module de commande de services 5.2.

Dans le mode de réalisation considéré, le commutateur de transit 4 est en outre un Commutateur d'Accès au Service RI (CAS). Le CAS 4 est ainsi relié au PCS 5. II est adapté pour reconnaître les numéros de services RI (il stocke les listes de tels numéros en mémoire) et pour communiquer avec le PCS 5, par exemple selon le protocole connu INAP ( Intelligent Network Application Protocol ). Il est également adapté pour mettre en oeuvre des ressources de communication définies en fonction de commandes qui lui sont envoyées par le module de commande de service 5.2 du PCS 5.

Le CAS 4 constitue un point de référence pour les services mis en oeuvre en faisant appel au PCS 5. L'ensemble des communications sont établies par établissements successifs de tronçons de circuits de communication, une extrémité d'un tronçon étant un terminal utilisateur, l'autre extrémité étant le CAS 4.

Le PCS 5 est relié à des serveurs externes de routage. Deux de ces serveurs de routages 10, 11 ont été représentés sur la figure 2. Les serveurs externes de routage 10 et 11 sont reliés respectivement au PCS 5 par des liaisons de communication 110, 111 faisant partie d'un réseau Internet, au sein duquel le PCS 5 et le serveur externe 10 sont identifiés par des adresses IP respectives.

Le serveur externe de routage 10 est relié à des centres d'appels 12,13 par l'intermédiaire de liaisons bidirectionnelles 112, 113. Le centre d'appel 12 est par exemple une plate-forme de renseignements relatifs aux prestations proposées par une entreprise E, par exemple une compagnie d'assurances. Le centre d'appel 12 comporte par exemple trois terminaux utilisateurs TB, TC, TD associés à des numéros de téléphone respectifs. Les terminaux TB et TC sont utilisés respectivement par les utilisateurs B, C qui sont des téléconseillers. Le terminal TD est adapté pour dérouler un menu vocal. Il correspond donc à un téléconseiller virtuel C. La fonction du centre d'appel 12 est de fournir des renseignements aux personnes qui composent un numéro générique de service intelligent qui lui est associé, par exemple un numéro de libre appel 0800 xxx xxx, nommé ci-après 0800x.

Les terminaux utilisateurs TB, TC, TD sont dans le cas considéré reliés au CAA 3. Dans d'autres modes de réalisation, ils ne sont pas rattachés au même CAA.

Le serveur externe de routage 10 est adapté pour connaître en temps quasiréel, par l'intermédiaire de l'interface 112, l'état du centre d'appel 12. En particulier, il dispose de données représentatives de la disponibilité des différents terminaux utilisateurs TB, TC et TD. Il est aussi adapté pour transmettre au PCS des informations exploitées ensuite par le PCS pour établir des tickets de taxation utilisés pour la facturation des communications.

L'utilisateur A du terminal utilisateur TA relié au CAA 2 souhaite obtenir des informations sur des prestations de l'entreprise E et compose le numéro de libre appel correspondant 0800x.

Ce numéro 0800x est transmis par le CAA 2 au CAS 4. Les circuits de communication entre le terminal utilisateur TA et le CAS 4 sont réservés pour l'établissement d'une communication à établir entre l'appelant TA et un destinataire à définir.

Le CAS 4 reconnaît que le numéro composé par l'utilisateur A du terminal A est un numéro de service RI. En conséquence, le CAS 4 envoie à destination du PCS 5 une requête lui fournissant le numéro 0800x et lui demandant de lui fournir un numéro de terminal utilisateur du réseau 1, qui sera le destinataire de l'appel initié par l'utilisateur A. Le PCS 5 sélectionne en fonction du numéro 0800x fourni un serveur externe compétent. Dans le cas présent, le numéro 0800x étant relatif à l'entreprise E dont l'état est supervisé par le serveur externe de routage 10, le PCS 5 sélectionne le serveur externe de routage 10. Puis un échange a lieu entre le PCS 5 et le serveur externe 10, au cours duquel le PCS 5 fournit le numéro 0800x au serveur externe 10 pour traduction par ce dernier en un numéro d'abonné associé à un terminal utilisateur du centre d'appel 12 et dans lequel le serveur externe 10 délivre au PCS le numéro d'abonné issu de la traduction.

Selon l'invention, les échanges se font dans le cadre du protocole SIP conformément aux dispositions qui suivent.

Ces échanges sont représentés en figure 3a.

Selon l'invention, lors de cet échange, le PCS 5 va représenter vis-à-vis du serveur externe 10, tour à tour l'initiateur de l'appel A et le destinataire de cet appel.

Dans une première étape, le PCS 5 charge le serveur externe 10 d'effectuer la traduction du n 0800x.

Pour cela, le PCS 5 envoie un message INVITE , nommé 11, comportant les champs Request URI , FROM , TO , Via renseignés de la façon suivante: - l'adresse IP du serveur externe 10, auquel le message 11 est destiné, est indiquée dans le champ Request URI ; le numéro de téléphone de l'appelant A est indiqué dans le champ FROM ; le numéro 0800x est indiqué dans le champ TO ; le champ Via contient l'adresse IP du PCS 5.

Lorsque le serveur externe 10 reçoit ce message 11 en provenance du PCS 5, il envoie au PCS 5 un message 100Trying accusant réception du message Il reçu.

Puis le serveur externe 10 détermine tout d'abord, à l'aide de tables mémorisées en mémoire et en fonction du numéro générique 0800x que le destinataire à désigner fait partie des terminaux utilisateurs du centre d'appels 12. La traduction va donc consister en la désignation d'un destinataire au sein de ce centre d'appels 12.

Avantageusement, la traduction est effectuée en fonction du numéro générique 0800x et en outre en fonction d'un ou plusieurs critères supplémentaires parmi la prise en compte de l'état de disponibilité des terminaux utilisateurs du centre d'appels 12, le numéro de l'appelant A indiqué par le message Il reçu, la date et de l'heure, de gestion de priorités etc. Le numéro d'abonné issu de la traduction correspond à celui associé au terminal utilisateur TB du téléconseiller B. Une fois la traduction effectuée, le serveur externe 10 envoie à son tour un message INVITE , nommé 12, au PCS 5.

Ce message 12 comporte les champs Request URI , FROM , TO , Via renseignés de la façon suivante: l'adresse IP du PCS 5 auquel le message 12 est destiné, est indiquée dans le champ Request URI ; -le numéro de téléphone du terminal utilisateur TA de l'appelant A est indiqué dans le champ FROM ; - le numéro de téléphone du terminal utilisateur TB issu de la traduction effectuée par le serveur externe 10 est indiqué dans le champ TO ; le champ Via contient l'adresse IP du serveur externe 10.

Ainsi le PCS 5 dans un rôle de représentant du terminal TA envoie une invitation à communiquer au PCS 5 dans un rôle de représentant du terminal TB, via le serveur externe 10, qui effectue la traduction et fait suivre l'invitation au PCS 5 dans son rôle de représentant de B. Des messages d'acquittement conformes au protocole SIP sont ensuite échangés entre le PCS 5 et le serveur externe 10.

Lorsque le PCS 5 reçoit le message 12, le module d'interprétation 5.1 du PCS 5 identifie que ce message 12 fait suite au message 11 envoyé par le PCS 5. II détecte un lien entre les deux messages 11 et 12, l'identifiant du terminal utilisateur TA étant présent dans les deux messages. Il présente alors une requête de fourniture de commande au dispositif de logique de commandes 5.2 du PCS 5, fournissant le numéro de téléphone du terminal utilisateur TA de l'appelant A et le numéro de téléphone du terminal utilisateur TB. Cette requête est établie en fonction du message Il envoyé et du message 12 reçu en réponse.

Le module de logique de commandes 5.2 transmet ensuite au CAS 4 des commandes de services qui sont ensuite propagées aux équipements du réseau RTC 1 (ici au CAA 3) afin de mettre en oeuvre des circuits de communication depuis le CAS 4 jusqu'au terminal utilisateur TB dans le prolongement de ceux déjà établis entre le terminal TA et le CAS 4, pour établir la communication entre l'appelant A et le destinataire B. Suivant les cas, ces circuits de communication peuvent être mis en oeuvre par l'intermédiaire du CT 4 et éventuellement d'autres CT, et de un ou plusieurs CAA. Dans le cas considéré, les circuits de communication entre le CT 4 et le terminal utilisateur TB sont établis par l'intermédiaire du CT 4 et du CAA 3.

Une fois la communication établie entre l'utilisateur A et le téléconseiller B, il est alors convenu entre ce dernier et l'utilisateur A de transférer la communication du téléconseiller B au téléconseiller C associé au terminal utilisateur TC du centre d'appels 12, qui est particulièrement bien adapté pour traiter certaines des questions de l'utilisateur A. Le téléconseiller B par l'intermédiaire du terminal utilisateur TB et de la liaison bidirectionnelle 112 transmet au serveur externe 10 une requête de transfert de la communication du terminal utilisateur TB vers le terminal utilisateur TC.

Comme représenté en figure 3b, le serveur externe 10 envoie alors un message ReINVITE , nommé R3, au PCS 5, indiquant le numéro de téléphone du terminal TA. Suite à la réception de ce message R3 par le PCS 5, le module d'interprétation 5.1 du PCS 5 identifie que le message R3 concerne l'appel précédemment établi suite aux messages 11 et 12 échangés précédemment entre le PCS 5 et le serveur externe 10. II détecte un lien entre les messages I1, 12 et R3, l'identifiant du terminal utilisateur TA étant présent dans les deux messages. II détermine alors en fonction de ces informations le contenu d'une requête de fourniture de commande qu'il adresse au module de logique de commandes 5.2 du PCS 5. Cette requête fournit le numéro de téléphone du terminal utilisateur TA de l'appelant A et demande que soit émise une commande de mise en attente de l'utilisateur A et une commande de libération des circuits de communication entre le CAS 4 et le terminal utilisateur TB du téléconseiller B. Suite à la réception de cette requête en provenance du module d'interprétation 5.1 du PCS 5, le module de logique de commandes 5. 2 émet à destination du CAS 4 la commande de mise en attente et la commande de libération de circuits de communication requises.

Un message d'attente piloté par le PCS 5 est diffusé à destination du terminal TA.

Les circuits de communication entre le CAS 4 et le terminal utilisateur du téléconseiller B sont libérés.

Puis le serveur externe 10 transmet au PCS 5 un message INVITE , 30 nommé 14.

Le message 14 comporte les champs Request URI , FROM , TO , Via renseignés de la façon suivante: l'adresse IP du PCS 5 auquel le message 14 est destiné est indiquée dans le champ Request URI ; -le numéro de téléphone du terminal utilisateur TA de l'appelant A est indiqué dans le champ FROM - le numéro de téléphone du terminal utilisateur TC est indiqué dans le champ TO ; le champ Via contient l'adresse IP du serveur externe 10 Le module d'interprétation 5.1, à la réception du message 14, identifie que ce message 14 fait suite aux messages 11, 12 et R3 échangés entre le PCS 5 et le serveur externe 10. II détecte un lienentre les différents messages 11, 12, R3 et 14, l'identifiant du terminal utilisateur TA étant présent dans les deux messages. II présente alors une requête de fourniture de commande au dispositif de logique de commandes 5.2 du PCS 5, fournissant le numéro de téléphone du terminal utilisateur TA de l'appelant A et le numéro de téléphone du terminal utilisateur TC, établie en fonction du message 14 envoyé et des précédents messages échangés concernant messages 11, 12 et R3 relatifs à la même communication et aux changements qui l'affectent.

Le module de logique de commandes 5.2 transmet ensuite au CAS 4 des commandes de services qui sont ensuite propagées aux équipements du réseau RTC 1 (ici au CAA 3) afin de prolonger les circuits de communication déjà établis entre le terminal TA et le CAS 4 en mettant en oeuvre des circuits de communication depuis le CAS 4 jusqu'au terminal utilisateur TC, pour établir la communication entre l'appelant A et le destinataire C. Dans le cas considéré, les circuits de communication entre le CT 4 et le terminal utilisateur TC sont établis par l'intermédiaire du CT 4 et du CAA 3.

Puis le serveur externe 10 envoie au PCS 5 un message ReINVITE , nommé R5 et indiquant le numéro de téléphone du terminal utilisateur TA.

A la réception de ce second message ReINVITE R5 et en fonction en outre des précédents messages échangés 11, 12, R3, 14 entre le PCS 5 et le serveur externe 10, le module d'interprétation 5.1 établit une requête de fourniture de commande et la présente au module de logique de commandes 5.2 du PCS.

Cette requête fournit le numéro de téléphone du terminal utilisateur TA de l'appelant A et demande que soit émise une commande de fin de mise en attente de l'utilisateur A. Suite à la réception de cette requête en provenance du module d'interprétation 5.1 du PCS 5, le module de logique de commandes 5.2 émet à destination du CAS 4 la commande de fin de mise en attente du terminal utilisateur TA.

En conséquence, le message d'attente n'est plus diffusé à destination du terminal TA et la mise en communication de l'utilisateur A avec le téléconseiller C a lieu, par l'intermédiaire de leur terminal utilisateur respectif TA et TC.

Le mode de transfert illustré par la figure 3b correspond à un reroutage de la communication du terminal utilisateur TB au terminal utilisateur TC, nommé re-routage en aveugle (car l'utilisateur B du terminal utilisateur TB est retiré de la communication sans avoir communiqué avec l'utilisateur TC par l'intermédiaire du réseau RTC 1).

Il existe d'autres modes de re-routage. Parmi ceux-ci, on peut citer par exemple le re-routage accompagné , dans lequel, lorsqu'il a lieu pendant une communication entre l'utilisateur A et le téléconseiller B, l'utilisateur A est mis en attente pendant qu'une communication est établie entre les téléconseillers TB et TC par l'intermédiaire de leurs terminaux utilisateurs respectifs à laquelle succède une communication entre l'utilisateur A et le téléconseiller TC.

Selon l'invention, des échanges entre le PCS 5 et le serveur externe 10 basés sur le protocole SIP sont mis en oeuvre, les messages reçus par le PCS 5 étant ensuite interprétés par le module d'interprétation 5.1 du PCS 5. Cette interprétation donne lieu à l'émission de requêtes de commande de services du module d'interprétation au module de commandes de services 5.2, qui émet en fonction de ces requêtes des commandes de services à destination des équipements de commutation du réseau RTC visant à l'établissement et/ou la libération de circuits de communication.

Dans un mode de réalisation avantageux de l'invention, il est créé une adresse IP du PCS 5 différente pour chaque terminal utilisateur dont le numéro d'abonné est fourni dans les messages échangés entre le PCS 5 et le serveur externe 10.

Ainsi dans le cas illustré par la figure 3a, il est créé une adresse IP PCS 5 indiquant le terminal TA, nommée ci-après ADIP(PCS)IA, qui prend par exemple une forme du type PCS_LibreAppel_ numéro de téléphone du terminal TA @francetelecom.com) où le champ numéro de téléphone du terminal TA contient le numéro de téléphone du terminal TA, par exemple composé de 8 chiffres, puis une adresse IP du PCS 5 indiquant le terminal TB, nommée ci-après ADIP(PCS) I B qui prend par exemple la forme PCS_LibreAppel_ numéro de téléphone du terminal TB @francetelecom. com.

Ces adresses sont créées suivant les cas par le PCS 5 ou par le serveur externe 10, conformément à un modèle général convenu entre eux préalablement. Elles sont créées au fur et à mesure de l'apparition, dans les messages échangés conformément au protocole SIP, d'informations concernant de nouveaux terminaux utilisateurs pour lesquels il n'existe encore aucune adresse IP du PCS indiquant ce terminal utilisateur. Dans les exemples d'adresses indiquées ci-dessus, le modèle général d'une adresse IP du PCS indiquant un terminal utilisateur quelconque TX, associé à un numéro de téléphone, est PCS_LibreAppel_ numéro de téléphone de TX @francetelecom.com.

Les équipements de transmission permettant la transmission des messages sur la liaison entre le PCS 5 et le serveur externe 10 sont adaptés (par exemple, par paramétrage d'un serveur de nom de domaine ou DNS) pour transmettre au PCS 5 chaque message dont le destinataire est désigné par une adresse conforme à ce modèle général.

En fait, dans un message échangé entre le PCS 5 et le serveur externe 10, le PCS représente le terminal utilisateur indiqué par une adresse IP du PCS 5.

Cette information est extraite des messages en provenance du serveur externe 10 et reçus par le PCS, puis exploitée par le module d'interprétation 5.1 en fonction en outre du contexte, c'est-à-dire notamment des messages antérieurs échangés entre le PCS et le serveur externe et relatifs à la même communication et aux modifications qu'elle a subies, pour déterminer sur quelle partie des circuits de communication des commandes de services vont devoir être émises et pour ainsi déterminer quelles requêtes de fournitures de commande de services le module d'interprétation 5.1 va devoir envoyer au module de commandes de services 5.2.

Ainsi dans le cas du message INVITE 11, le champ Via , indiquant l'entité qui a émis le message, c'est-à-dire le PCS, contient une adresse IP du PCS indiquant le terminal utilisateur TA, soit ADIP(PCS) 1A.

Dans le message INVITE 12 ci-dessus émis par le serveur externe 10 à destination du PCS 5, le champ Request URI contient une adresse IP du PCS indiquant le terminal utilisateur TB, soit ADIP(PCS) B. En fonction de cette adresse, du message INVITE 12 et du message antérieur 11 à rattacher au contexte de ce message 12, le module d'interprétation 5.1 est ainsi informé lorsqu'il reçoit le message 12, qu'il doit requérir des commandes de services relatives à l'établissement de circuits de communication entre le CT 4 et le terminal utilisateur TB.

Le message ReINVITE R3 est envoyée par le serveur externe 10 à l'adresse IP du PCS indiquant le terminal utilisateur TA, soit ADIP(PCS) 1A.

En fonction de cette adresse, du message ReINVITE R3 et des messages antérieurs 11 et 12 à rattacher au contexte de ce message, le module d'interprétation 5.1 est ainsi informé lorsqu'il reçoit le message R3, qu'il doit requérir des commandes de services relatives au maintien du tronçon de circuit de communication entre le terminal utilisateur TA et le CT 4 et à la diffusion d'un message d'attente destiné à l'utilisateur A Le message INVITE 14 est envoyé par le serveur externe 10 à l'adresse IP du PCS 5 indiquant le terminal utilisateur TC, soit AD1p(PCS) c.

En fonction de cette adresse, du message INVITE 14 et des messages antérieurs 11, 12 et R3 à rattacher au contexte de ce message, le module d'interprétation 5.1 est ainsi informé lorsqu'il reçoit le message 14, qu'il doit requérir des commandes de services relatives à l'établissement de circuits de communication entre le CT 4 et le terminal utilisateur TC.

Le message ReINVITE R5 est envoyée par le serveur externe 10 à l'adresse IP du PCS indiquant le terminal utilisateur TA, soit AD1p(PCS)1 A. En fonction de cette adresse, du message ReINVITE et des messages antérieurs 11, 12, R3 et 14, le module d'interprétation 5.1 est ainsi informé lorsqu'il reçoit le message R5, qu'il doit requérir des commandes de services pour stopper la diffusion du message d'attente destiné à l'utilisateur A Avantageusement dans le cas décrit en référence aux figures 2, 3a et 3b, les informations d'adressage relatives aux terminaux TA, TB, TC du réseau RTC présentes dans les messages basés sur le protocole SIP (messages INVITE 11, 12, 100TRYING ...) sont conformes aux normes UIT-T Q.1912.5 définissant les échanges entre le protocole SIP et le protocole ISUP.

Les échanges entre le PCS 5 et le serveur externe 10 sont ainsi mis en oeuvre pour définir les extrémités de communications sur lesquelles des commandes de services doivent porter. Les communications sont ensuite établies entre ces extrémités en mettant en oeuvre des circuits de communications du réseau RTC 1, qui sont indépendants du PCS 5 et du serveur externe 10.

Le réseau 1 décrit dans le mode de réalisation considéré ci-dessus est un réseau RTC. Toutefois, la mise en oeuvre de l'invention ne se limite nullement à ce type de réseau et peut par exemple être appliquée dans le cadre d'un réseau NGN.

Par ailleurs, l'identifiant du service demandé par l'appelant A décrit cidessus était un numéro de téléphone générique et les identifiants des terminaux utilisateurs étaient des numéros de téléphone d'un réseau RTC.

Dans un autre mode de réalisation, certains au moins de ces identifiants peuvent être alphanumériques. Certains peuvent dans un mode de réalisation prendre notamment la forme d'une adresse email composée d'un nom utilisateur suivi d'un nom de domaine. Par exemple, l'identifiant du service générique peut prendre la forme serviceX@centredappelY .

Ainsi l'invention propose un mode d'échange entre un serveur de commande de service et un serveur externe qui offre l'avantage d'être basé sur un protocole standard, et de ce fait permet une homogénéisation des interfaces entre PCS et serveurs externes et une simplification des développements nécessaires pour la mise en place de nouveaux services.

Claims (10)

REVENDICATIONS

1. Procédé de communication entre un serveur de commande de service (5) d'un réseau de communication (1) et un serveur externe (10), ledit serveur externe étant relié par une liaison de communication (112) à une unité de fourniture de services (12) comportant plusieurs terminaux utilisateurs (TB, TC) du réseau de communication, ledit procédé comprenant les étapes suivantes: a) transmettre, sur réception d'une requête de service d'un premier terminal utilisateur (TA), depuis le serveur de commande de service (5) à destination du serveur externe, un premier message d'ouverture de session (11), conforme à un protocole d'ouverture de session, indiquant un identifiant du premier terminal utilisateur (TA) en tant que terminal émetteur; b) transmettre depuis le serveur externe (10) à destination du serveur de commande de service (5), un deuxième message d'ouverture de session (12;14) conforme audit protocole indiquant l'identifiant du premier terminal utilisateur (TA) en tant que terminal émetteur et un identifiant d'un terminal utilisateur (TB;TC) de l'unité en tant que terminal récepteur; c) détecter un lien entre le premier message d'ouverture de session et le deuxième message d'ouverture de session, ledit lien découlant de la présence de l'identifiant du premier terminal utilisateur (TA) dans les deux messages; d) déterminer en fonction du deuxième message d'ouverture de session au moins une commande de services, destinée au réseau de communication, pour l'établissement d'une communication entre le premier terminal utilisateur (TA) et le terminal utilisateur (TB;TC) de l'unité.

2. Procédé selon la revendication 1, le serveur de communication de commande de services (5) comportant une architecture de réseau intelligent selon lequel: - la requête reçue par le serveur de commande de services est une requête pour la traduction d'un identifiant générique, indicatif d'un service, fourni par le premier terminal utilisateur (TA) du réseau (1) ; - le premier message d'ouverture de session est un message INVITE (Il) conforme au protocole SIP et indiquant l'identifiant générique; - le deuxième message d'ouverture de session est un message INVITE (12) conforme au protocole SIP; ledit procédé comprenant en outre l'étape suivante: suite à la réception par le serveur externe (10) dudit premier message (I1) en provenance du serveur de commande de services, déterminer que l'identifiant générique identifie l'unité de fourniture de services et traduire l'identifiant générique en l'identifiant du terminal utilisateur (TB) de l'unité en fonction d'au moins ledit identifiant générique;

3. Procédé selon la revendication 2, selon lequel la traduction est effectuée par le serveur externe (10) en fonction d'au moins ledit identifiant générique et de critères relatifs aux terminaux utilisateurs de l'unité qui lui sont communiqués par l'intermédiaire de la liaison de communication (112) avec l'unité de fourniture de services (12).

4. Procédé selon l'une quelconque des revendications 2 à 3, selon lequel, en réponse à une requête du terminal utilisateur de l'unité relative à un transfert de communication entre ledit terminal utilisateur de l'unité (TB) et un autre terminal utilisateur (TC) de l'unité (12), -transmettre depuis le serveur externe (10) au serveur de commandes de services (5) un message ReINVITE (R3) indiquant l'identifiant du premier terminal utilisateur (TA) ; et - recevoir au niveau du serveur de commande de services ledit message ReINVITE (R3) transmis par le serveur externe et déterminer en fonction dudit message ReINVITE au moins une commande de services destinée au réseau de communication pour la mise en attente du premier terminal utilisateur (TA) et la libération des circuits de communication vers le terminal utilisateur (TB) de l'unité.

5. Procédé selon l'une quelconque des revendications 2 à 4, selon lequel une adresse de destination d'un message INVITE reçu par le serveur de commande de services est une adresse du serveur de commande de services (5) qui indique un terminal utilisateur, et la commande de services destinée au réseau de communication est établie par le serveur de commande en fonction de ladite adresse pour mettre en oeuvre des circuits de communication entre ledit terminal utilisateur et un point de référence (4) du réseau préalablement déterminé et associé au point de commande.

6. Serveur de commande de services (5) d'un réseau de communication (1) relié à un serveur externe (10) interfacé par une liaison de communication (112) à une unité (12) de fourniture de services comportant des terminaux utilisateurs (TB, TC) du réseau de communication, comprenant des moyens pour mettre en oeuvre les étapes, qui incombent au serveur de commande de services, d'un procédé selon l'une quelconque des revendications précédentes.

7. Serveur externe (10) relié à un serveur de commande de services (5) d'un réseau de communication (1) et interfacé par une liaison de communication (112) à une unité (12) de fourniture de services comportant des terminaux utilisateurs (TB, TC) du réseau de communication, comprenant des moyens pour mettre en oeuvre les étapes, qui incombent audit serveur externe, d'un procédé selon l'une quelconque des revendications 1 à 5.

8. Programme d'ordinateur à installer dans un serveur de commande de services (5) d'un réseau de communication (1) relié à un serveur externe (10) interfacé par une liaison de communication (112) à une unité (12) de fourniture de services comportant des terminaux utilisateurs (TB, TC) du réseau de communication, comprenant des instructions pour mettre en oeuvre les étapes, qui incombent au serveur de commande de services, d'un procédé selon l'une quelconque des revendications 1 à 5 lors d'une exécution du programme par des moyens de traitement dudit serveur de commande.

9. Programme d'ordinateur à installer dans un serveur externe (10) relié à un serveur de commande de services (5) d'un réseau de communication (1) et interfacé par une liaison de communication (112) à une unité (12) de fourniture de services comportant des terminaux utilisateurs (TB, TC) du réseau de communication, comprenant des instructions pour mettre en oeuvre les étapes, qui incombent au serveur externe, d'un procédé selon l'une quelconque des revendications 1 à 5 lors d'une exécution du programme par des moyens de traitement dudit serveur externe.

10. Système de communication comportant - un serveur de commande de services (5) selon la revendication 6, d'un réseau de communication; -un serveur externe (10) selon la revendication 7, relié au serveur de commande de services (5) ; - au moins une unité de fourniture de services (12), reliée au serveur externe (10) par une liaison de communication (112), comportant une pluralité de terminaux utilisateurs (TB, TC) du réseau de communication.