CA2658253A1 - Retablissement d'appel dans un serveur d'appel d'installation de telecommunications privee - Google Patents

Retablissement d'appel dans un serveur d'appel d'installation de telecommunications privee Download PDF

Info

Publication number
CA2658253A1
CA2658253A1 CA002658253A CA2658253A CA2658253A1 CA 2658253 A1 CA2658253 A1 CA 2658253A1 CA 002658253 A CA002658253 A CA 002658253A CA 2658253 A CA2658253 A CA 2658253A CA 2658253 A1 CA2658253 A1 CA 2658253A1
Authority
CA
Canada
Prior art keywords
call
server
terminal
chain
context
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.)
Abandoned
Application number
CA002658253A
Other languages
English (en)
Inventor
Jean-Pierre Mercuriali
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.)
Aastra Matra Telecom SAS
Original Assignee
Aastra Matra Telecom
Jean-Pierre Mercuriali
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 Aastra Matra Telecom, Jean-Pierre Mercuriali filed Critical Aastra Matra Telecom
Publication of CA2658253A1 publication Critical patent/CA2658253A1/fr
Abandoned legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/006Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H04M7/0081Network operation, administration, maintenance, or provisioning
    • H04M7/0084Network monitoring; Error detection; Error recovery; Network testing
    • 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/1069Session establishment or de-establishment
    • 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
    • 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/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/08Indicating faults in circuits or apparatus
    • H04M3/12Marking faulty circuits "busy"; Enabling equipment to disengage itself from faulty circuits ; Using redundant circuits; Response of a circuit, apparatus or system to an error
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/42314Systems providing special services or facilities to subscribers in private branch exchanges
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q3/00Selecting arrangements
    • H04Q3/0016Arrangements providing connection between exchanges
    • H04Q3/0025Provisions for signalling

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Sub-Exchange Stations And Push- Button Telephones (AREA)

Abstract

Pour rétablir rapidement un appel préétabli entre des premier et deuxième terminaux (T1, T2) rattachés respectivement à des premier et deuxième serve urs d'appel (SAS1, SAP2), une première chaîne d'appel (MG1, MCA1) est créée en association au premier terminal et à un premier contexte de l'appel prémé morisé dans le premier serveur. Une demande de rétablissement d'appel inclua nt une référence de deuxième chaîne d'appel extraite du premier contexte est transmise depuis le premier vers le deuxième serveur. Dans le deuxième serv eur, une deuxième chaîne d'appel (MG2, MCA2) est recherchée en fonction de l a référence incluse dans la demande. Si la deuxième chaîne est trouvée en as sociation au deuxième terminal, un rétablissement de l'appel entre les premi er et deuxième terminaux à travers un chemin entre les première et deuxième chaînes d'appel est confirmé par le deuxième serveur au premier serveur.</SD OAB>

Description

Rétablissement d'appel dans un serveur d'appel d'installation de télécommunications privée La présente invention concerne un serveur d'appel pour gérer des appels dans une installation de télécommunications privée d'entreprise. Plus particulièrement elle a trait dans le serveur d'appel au rétablissement d'un appel précédemment établi en relation avec un terminal rattaché au serveur d'appel.

Dans l'installation de télécommunications privée, le serveur d'appel est relié à travers un réseau local à des passerelles desservant des terminaux d'usager locaux et des accès à des réseaux de télécommunications. Il attribue des adresses aux terminaux et passerelles et gère de nombreux appels entre des terminaux locaux et des terminaux distants.
Les passerelles échangent de la signalisation avec le serveur d'appel au cours des appels. Une chaîne d'appel est créée dans le serveur d'appel pour chaque appel auquel participe un terminal local.
Si un incident survient dans le fonctionnement du serveur d'appel entraînant une perte des chaînes d'appel en mémoire du serveur d'appel, soit le fonctionnement normal du serveur d'appel est rétabli très rapidement, soit en cas de panne prolongée, il est remplacé par un serveur d'appel de secours relié
au réseau local et ayant mémorisé les mêmes données statiques relatives aux caractéristiques des terminaux et à l'architecture de l'installation. Dans tous les cas, les chaînes d'appel sont effacées ce qui conduit à la rupture des chemins pour les appels précédemment établis avant l'incident et une
2 libération des terminaux appelants et appelés dans l'installation.
En outre l'enregistrement de données relatives à
la gestion d'une chaîne d'appel au cours d'un appel sur le disque dur du serveur d'appel est long et peut retarder certaines phases au cours du déroulement d'un appel. D'une manière analogue, le transfert de données de disque dur à disque dur entre des serveurs d'appel et de secours est long et peut retarder le rétablissement de la signalisation des appels par le serveur d'appel de secours.

L'invention vise à remédier aux inconvénients précités et particulièrement à rétablir rapidement des appels précédemment établis dans l'installation lorsqu'un serveur d'appel devient subitement défaillant.

A cette fin, un procédé pour rétablir un appel précédemment établi entre un premier terminal rattaché à un premier serveur d'appel et un deuxième terminal rattaché à un deuxième serveur d'appel, est caractérisé en ce qu'il comprend les étapes de :
créer une première chaîne d'appel associée au premier terminal et à un premier contexte de l'appel préalablement mémorisé dans le premier serveur d'appel, transmettre une demande de rétablissement d'appel incluant une référence de deuxième chaîne d'appel extraite du premier contexte depuis le premier serveur d'appel vers le deuxième serveur d'appel, rechercher dans le deuxième serveur d'appel une deuxième chaîne d'appel en fonction de la référence
3 de deuxième chaîne d'appel incluse dans la demande de rétablissement d'appel, et si la deuxième chaîne d'appel est trouvée en association au deuxième terminal, confirmer un rétablissement de l'appel entre les premier et deuxième terminaux à travers un chemin entre les première et deuxième chaînes d'appel, par le deuxième serveur d'appel au premier serveur d'appel.
Les premier et deuxième terminaux peuvent être respectivement un terminal appelant et un terminal appelé par le terminal appelant, ou inversement le terminal appelé et le terminal appelant.
Des données de signalisation dynamiques de chaque appel en cours dans un contexte d'appel mémorisée sur le disque dur du premier serveur d'appel sont réduites au strict nécessaire au rétablissement de la signalisation de l'appel par le premier serveur. Le rétablissement de l'appel est ainsi très rapide. Les données de signalisation dynamiques contenues dans la demande de rétablissement d'appel peuvent être l'adresse du premier terminal, l'adresse du deuxième terminal et la référence de la deuxième chaîne d'appel extraits du premier contexte, et la référence de la première chaîne d'appel créée dans le premier serveur d'appel.
Par exemple le basculement d'un serveur d'appel principal défaillant vers un serveur d'appel de secours et le rétablissement de l'appel par le serveur d'appel de secours sont très rapides.
En général, si un serveur d'appel principal dans une installation de télécommunications privée incluant le premier terminal devient défaillant et si la défaillance de ce serveur d'appel principal est très rapidement inhibée, le rétablissement de l'appel
4 est réalisé dans le serveur d'appel principal en tant que premier serveur d'appel. Cependant si la réparation de la défaillance du serveur d'appel principal doit être longue, le premier serveur d'appel peut être un serveur de secours de l'installation de télécommunications privée adapté à
remplacer le serveur d'appel principal devenu défaillant et auquel est également rattaché le premier terminal.
Selon une autre réalisation, le premier serveur d'appel et le deuxième serveur d'appel sont réunis en un unique serveur d'appel qui peut être un serveur d'appel principal ou un serveur d'appel de secours d'une installation de télécommunications privée commune aux premier et deuxième terminaux.

L'invention a aussi pour objet un système pour rétablir un appel précédemment établi entre un premier terminal rattaché à un premier serveur d'appel et un deuxième terminal rattaché à un deuxième serveur d'appel. Le système est caractérisé
en ce qu'il comprend :
un moyen dans le premier serveur d'appel pour créer une première chaîne d'appel associée au premier terminal et à un premier contexte de l'appel préalablement mémorisé dans le premier serveur d'appel, un moyen dans le premier serveur d'appel pour transmettre une demande de rétablissement d'appel incluant une référence de deuxième chaîne d'appel extraite du premier contexte vers le deuxième serveur d'appel, un moyen dans le deuxième serveur pour rechercher une deuxième chaîne d'appel en fonction de la référence de deuxième chaîne d'appel incluse dans la demande de rétablissement d'appel, et si la deuxième chaîne d'appel est trouvée en association au deuxième terminal, un moyen dans le
5 deuxième serveur pour confirmer un rétablissement de l'appel entre les premier et deuxième terminaux à
travers un chemin entre les première et deuxième chaînes d'appel, par le deuxième serveur d'appel au premier serveur d'appel.
L'invention concerne également des serveurs d'appel.
Selon une première réalisation, un serveur d'appel adapté à rétablir un appel précédemment établi entre un premier terminal qui lui est rattaché
et un deuxième terminal rattaché à un deuxième serveur d'appel, peut comprendre selon l'invention :
un moyen pour créer une première chaîne d'appel associée au premier terminal et à un premier contexte du premier appel préalablement mémorisé dans le serveur d'appel, et un moyen pour transmettre une demande de rétablissement d'appel incluant une référence de deuxième chaîne d'appel extraite du premier contexte vers le deuxième serveur d'appel, afin que le deuxième serveur recherche une deuxième chaîne d'appel en fonction de la référence de deuxième chaîne d'appel incluse dans la demande de rétablissement d'appel, et si la deuxième chaîne d'appel est trouvée en association au deuxième terminal, confirme un rétablissement de l'appel entre les premier et deuxième terminaux à travers un chemin entre les première et deuxième chaînes d'appel, audit serveur d'appel.
6 L'invention se rapporte aussi à un programme d'ordinateur apte à être mis en ceuvre dans le serveur d'appel selon la première réalisation. Le programme est caractérisé en ce qu'il comprend des instructions qui, lorsque le programme est chargé et exécuté dans ledit serveur d'appel selon la première réalisation, réalisent les étapes suivantes :
créer une première chaîne d'appel associée au premier terminal et à un premier contexte du premier appel préalablement mémorisé dans le serveur d'appel, et transmettre une demande de rétablissement d'appel incluant une référence de deuxième chaîne d'appel extrait du premier contexte vers le deuxième serveur d'appel, afin que le deuxième serveur recherche une deuxième chaîne d'appel en fonction de la référence de deuxième chaîne d'appel inclus dans la demande de rétablissement d'appel, et si la deuxième chaîne d'appel est trouvée en association au deuxième terminal, confirme un rétablissement de l'appel entre les premier et deuxième terminaux à travers un chemin entre les première et deuxième chaînes d'appel, audit serveur d'appel.
Selon une deuxième réalisation pouvant être combinée avec la première réalisation, un serveur d'appel pour rétablir un appel précédemment établi entre un premier terminal rattaché à un premier serveur d'appel et un deuxième terminal qui lui est rattaché, peut comprendre selon l'invention :
un moyen pour rechercher une deuxième chaîne d'appel en fonction d'une référence de deuxième chaîne d'appel incluse dans une demande de rétablissement d'appel transmise par le premier serveur d'appel et extrait d'un premier contexte de
7 l'appel préalablement mémorisé dans le premier serveur d'appel ayant créé une première chaîne d'appel associée au premier terminal, et si la deuxième chaîne d'appel est trouvée en association au deuxième terminal, un moyen pour confirmer un rétablissement de l'appel entre les premier et deuxième terminaux à travers un chemin entre les première et deuxième chaînes d'appel au premier serveur d'appel.
L'invention se rapporte aussi à un programme d'ordinateur apte à être mis en ceuvre dans le serveur d'appel selon la deuxième réalisation. Le programme est caractérisé en ce qu'il comprend des instructions qui, lorsque le programme est chargé et exécuté dans ledit serveur d'appel selon la deuxième réalisation, réalisent les étapes suivantes :
rechercher une deuxième chaîne d'appel en fonction d'une référence de deuxième chaîne d'appel inclus dans une demande de rétablissement d'appel transmise par le premier serveur d'appel et extrait d'un premier contexte de l'appel préalablement mémorisé dans le premier serveur d'appel ayant créé
une première chaîne d'appel associée au premier terminal, et si la deuxième chaîne d'appel est trouvée en association au deuxième terminal, confirmer un rétablissement de l'appel entre les premier et deuxième terminaux à travers un chemin entre les première et deuxième chaînes d'appel au premier serveur d'appel.

D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations de l'invention données à titre
8 d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels :
- la figure 1 est un bloc-diagramme schématique d'une installation de télécommunications privée comprenant un serveur d'appel principal et un serveur d'appel de secours selon l'invention ;
- la figure 2 est un bloc-diagramme de deux installations de télécommunications privée ayant des terminaux communiquant entre eux ; et - la figure 3 est un algorithme de procédé de procédé de rétablissement d'appel selon l'invention, relativement aux installations de télécommunications privées de la figure dont l'une inclut un serveur d'appel principal devenu défaillant.
En référence à la figure 1, une installation de télécommunications privée IT comprend un serveur d'appel principal SAP, un serveur d'appel de secours SAS, un réseau local d'entreprise RL et des passerelles PA.
Le serveur d'appel principal SAP comprend notamment un module d'appel simple MAS, un module d'observation de trafic MOT selon l'invention et une première partie comprenant un adaptateur de réseau AD1 et assignée à des chaînes d'appel sortant CH1 et une deuxième partie comprenant un adaptateur de réseau AD2 et assignée à des chaînes d'appel entrant CH2. Afin de ne pas surcharger la figure 1, seulement une chaîne d'appel sortant CH1 et une chaîne d'appel entrant CH2 sont représentées.
Le module d'appel simple MAS crée une chaîne d'appel sortant CH1 lors de l'établissement d'un appel sortant depuis un terminal appelant T1 rattaché
au serveur SAP et crée une chaîne d'appel entrant CH2 lors de l'établissement d'un appel entrant vers un
9 terminal appelé T2 rattaché au serveur SAP. Chaque chaîne CH1, CH2 comprend un module logiciel de gestion MG1, MG2 lié à l'adaptateur de réseau AD1, AD2 et un module logiciel de contexte d'appel MCA1, MCA2 lié au module de gestion.
Le serveur d'appel SAP est implémenté par exemple dans un ordinateur ou une plateforme dédiée.
Il peut jouer un rôle de portier ("gatekeeper" en anglais) satisfaisant le protocole de signalisation H.323 ou SIP (Session Initiation Protocol). Il communique dans l'installation par l'intermédiaire de messages de signalisation. Mais le serveur d'appel SAP ne traite pas des paquets de données audio et/ou vidéo échangés entre deux terminaux éventuellement par l'intermédiaire de leurs passerelles respectives au cours d'un appel établi entre eux. Le flux des paquets de données est régi par exemple selon le protocole de transport en temps réel de flux de données de bout en bout RTP (en anglais "Real Time Transport Protocol").
Le serveur d'appel de secours SAS est relié au serveur d'appel principal SAP à travers le réseau local RL et n'est pas représenté en détail dans la figure 1 puisqu'il inclut des composants matériels et logiciels analogues à ceux précités du serveur d'appel principal SAP.
Le réseau local RL fonctionne en mode paquet selon le protocole de transfert TCP/IP (en anglais "Transmission Control Protocol/Internet Protocol") sur lequel repose le protocole de flux de données RTP. Le réseau local RL est par exemple pour partie du type filaire LAN (en anglais "Local Area Network") et/ou pour partie du type sans fil WLAN (en anglais "Wireless Local Area Network"). Il connecte les adaptateurs de réseau AD1 et AD2 des serveurs SAP et
10 PCT/FR2007/051624 SAS à plusieurs passerelles multimédias PA dont seulement deux sont représentées à la figure 1. Les adaptateurs retransmettent des paquets de signalisation pour le traitement des appels dans les 5 modules de gestion et en outre assurent d'autres services tels une recherche d'annuaire et une messagerie vocale par exemple.
Les passerelles PA comportent des interfaces de communication adaptées pour desservir des terminaux 10 d'usager hétérogènes appartenant à l'entreprise possédant le réseau local RL, par des lignes intérieures à l'installation de télécommunications privée. Ces terminaux sont par exemple des terminaux téléphoniques analogiques ou numériques classiques T1, T2, des ordinateurs personnels, des télécopieurs, des terminaux radio numériques de faible portée du type DECT (en anglais "digital Enhanced Cordless Telecommunications) ou selon une norme IEEE 802.lxx et satisfaisant le label de certification WiFi (Wireless Fidelity). Certaines passerelles PA sont reliées, à travers des lignes extérieures à
l'installation de télécommunications privée, notamment à des réseaux de télécommunications "publics" tels que l'internet pour des communications de voix selon le protocole IP (en anglais "Internet Protocol") notamment par des lignes du type ADSL (en anglais "Asynchronous Digital Subscriber Line"), et/ou des accès à divers débits d'un Réseau Numérique à Intégration de Services RNIS.
Chaque passerelle PA interconnecte les terminaux locaux au réseau local et assure des raccordements intermédiaires pour diriger des appels sortants de terminaux appelants locaux vers des terminaux appelés locaux ou distants via le réseau local RL et le serveur d'appel SAP et des appels entrants de
11 terminaux appelants locaux ou distants vers des terminaux appelés locaux via le serveur d'appel SAP
et le réseau local RL. La passerelle gère et adapte les ressources physiques entre ses ports reliés notamment aux terminaux et aux réseaux externes en fonction d'une signalisation échangée avec le serveur d'appel qu'elle adapte aux signalisations propres des terminaux et accès de réseau qu'elle dessert. La passerelle est analogue à un commutateur privé du type PABX sans intelligence pour des applications de service particulièrement liées à la signalisation relative à l'établissement et la gestion des appels et dévolue au serveur d'appel.
D'autres terminaux TIP compatibles avec le protocole de transfert TCP/IP et offrant des fonctions notamment téléphoniques analogues à celles des terminaux précités sont reliés directement au réseau local RL.

Le serveur d'appel principal SAP comporte une base de données statiques qui contient des adresses qu'il a attribué, de préférence dynamiquement, à
toutes les passerelles PA, aux terminaux d'usager locaux et aux divers accès de réseau précitées de l'installation de télécommunications privée IT, notamment par des correspondances entre des numéros de téléphone de terminaux classiques et des adresses IP. La base de données statiques inclut également des profils des usagers des terminaux locaux et des caractéristiques des terminaux locaux ainsi que des caractéristiques sur l'architecture de l'installation privée IT. Ces données statiques sont simultanément enregistrées dans une base de données du serveur d'appel de secours SAS.
12 Toutes les communications pour lesquelles des terminaux reliés au réseau local d'entreprise RL
interviennent, sont contrôlées par le module d'appel simple MAS dans le serveur d'appel principal SAP. Le serveur d'appel principal SAP contrôle de nombreuses fonctions liées à l'adressage comme la présentation de l'adresse du terminal appelant; à des traitements particuliers des appels requis par les usagers locaux comme des renvois d'appel vers un autre terminal, des rappels automatiques, des doubles appels, un filtrage des appels, des messageries vocales, etc.; à la facturation; et à la gestion de la signalisation en mode message entre les terminaux via les passerelles et des commutateurs et routeurs dans des réseaux externes au réseau local RL.
Le trafic relatif à des messages de signalisation d'appel en mode paquet transite suivant des chemins d'appel respectifs depuis des premières chaînes d'appel CH1 dans le serveur SAP vers des deuxièmes chaînes d'appel dans le serveur SAP et/ou dans un autre serveur d'appel pour des appels sortant du serveur SAP, et depuis des premières chaînes d'appel dans le serveur SAP et/ou dans un autre serveur d'appel vers des deuxièmes chaîne d'appel CH2 dans le serveur SAP pour des appels entrant dans le serveur SAP. Ce trafic de signalisation d'appel est observé en coupure dans les modules de gestion MG1 et MG2 par le module MAS de manière à introduire, modifier et retirer des paquets de signalisation destinés aux passerelles et aux terminaux en communication. Les passerelles communiquent des paquets de données le plus souvent audio, mais aussi vidéo, pendant des appels établis, ainsi que des messages de signalisation en mode paquet. Les messages de signalisation sont relatifs à tout
13 événement caractéristique prédéterminé intervenu au cours d'un appel aux modules de gestion, comme une prise de ligne ou de canal (décrochage), une tonalité, une invitation notamment à composer une adresse telle qu'un numéro téléphonique, une commande liée à une commutation ou une attente, une libération de ligne ou de canal (raccrochage), etc. Les paquets de données, notamment relatifs à de la phonie pour des accès classiques à des réseaux externes téléphoniques numériques ou analogiques, sont échangés au cours d'appels établis entre des terminaux de manière transparente entre passerelles à
travers le réseau local RL et le serveur d'appel.

Dès que l'établissement d'un appel d'un terminal appelé local ou distant T2 est demandé (décrochage) par un terminal appelant local T1, le module d'appel simple MAS crée une chaîne d'appel sortant CH1 associée à l'adresse du terminal appelant local T1 pour seulement cet appel. Dans le serveur d'appel principal SAP auquel le terminal appelant est rattaché, la chaîne d'appel sortant CH1 comprend un module logiciel de gestion MG1 et un module logiciel de contexte d'appel MCA1. Lors de l'établissement de l'appel entre les terminaux appelant et appelé, le module de gestion MG1 surveille les manceuvres du terminal appelant T1 en analysant les paquets de signalisation relatifs au terminal appelant et transmis par la passerelle PA1, en supposant que le terminal appelant T1 est raccordé à celle-ci, et les manceuvres du terminal appelé local ou distant en analysant les paquets de signalisation transmis par la passerelle desservant le terminal appelé et relatifs au terminal appelé. Le module de gestion MG1 élabore des signaux de signalisation, comme des
14 signaux de tonalité ou de service, à transmettre vers les terminaux en fonction notamment des signaux de signalisation qu'il reçoit.
Le module de contexte d'appel MCA1 commande sur le disque dur du serveur d'appel principal SAP1 la mémorisation d'un contexte courant de l'appel comprenant des données strictement suffisantes pour identifier l'appel et le cas échéant utile à rétablir un chemin d'appel créée au cours de l'appel en cas de défaillance du serveur principal SAP, comme décrit plus loin. Dans une table de mémoire du module MCA1 attribuée au terminal appelant T1, le contexte courant de l'appel comprend des paramètres de chemin d'appel comme l'adresse du terminal appelant T1, l'adresse du terminal appelé T2 et deux références de chaîne d'appel telles des numéros de port pour définir un chemin d'appel jusqu'à la prochaine chaîne d'appel de terminal appelé pour atteindre le terminal appelé T2. Par exemple les adresses des terminaux T1 et T2 peuvent être des numéros téléphoniques. Ladite prochaine chaîne d'appel de terminal appelé est incluse dans un serveur d'appel qui peut être le même serveur que le serveur principal SAP auquel le terminal appelant est rattaché si les terminaux appelant et appelé sont liés localement à ce serveur d'appel. Selon une autre possibilité, le serveur d'appel incluant la prochaine chaîne d'appel de terminal appelé peut être un serveur d'appel principal qui est distant du serveur principal SAP et à travers lequel transite l'appel par exemple lorsque l'entreprise possède des serveurs d'appel principaux mis en cascade dans des sites distincts de l'entreprise et l'appel demandé transite à travers un ou plusieurs serveurs d'appel avant d'atteindre le serveur d'appel principal auquel le terminal appelé
distant est rattaché.
Les références de chaîne d'appel sont notamment le numéro du port de la chaîne d'appel CH1 (MG1, 5 MCA1) dans le serveur SAP et le numéro du port de prochaine chaîne d'appel de terminal appelé pour que le serveur SAP échange des paquets de signalisation relatifs à l'appel avec un module logiciel de contexte d'appel qu'a crée le module de gestion de la 10 prochaine chaîne d'appel au début de l'établissement dudit appel sortant.
Le contexte courant de l'appel comprend encore des paramètres tels un indicateur du type de connexion entre les terminaux T1 et T2 pour indiquer
15 une connexion active ou en garde par l'un des terminaux par exemple, un compte de taxes comptées depuis le début de l'appel, des identificateurs de ressources tels que des numéros d'intervalles de temps occupés par l'appel dans un signal multiplex à
division du temps interne au serveur SAP, et éventuellement un identificateur de terminal lorsque l'usager du terminal T1 dispose de plusieurs terminaux dans l'installation de télécommunications privée.
Chaque fois qu'un appel est rompu pour une quelconque cause, la chaîne d'appel et le contexte de cet appel sont effacés dans le serveur SAP.

De même et inversement, dès que l'établissement d'un appel d'un terminal appelé local T2 est demandé
par un terminal appelant local ou distant T1, le module d'appel simple MAS crée une chaîne d'appel entrant CH2 associée au terminal appelé pour seulement cet appel et incluant un module logiciel de gestion MG2 et un module logiciel de contexte d'appel
16 MCA2 dans le serveur d'appel principal SAP auquel le terminal appelé local T2 est rattaché. Un contexte de l'appel associé au terminal appelé T2 comprend des paramètres de chemin d'appel comme l'adresse du terminal appelé T2, l'adresse du terminal appelant T1 et deux références de chaîne d'appel telles le numéro de port de la chaîne d'appel associée au terminal appelé et le numéro de port de la dernière chaîne d'appel pour atteindre le terminal appelant T1. Ce contexte courant de l'appel est enregistré dans une table de mémoire du module MCA2 attribuée au terminal appelé T2. Le contexte d'appel associé au terminal appelé T2 comprend également un indicateur du type de connexion, des identificateurs de ressources internes au serveur de rattachement du terminal T2 et éventuellement un identificateur de terminal.
Des paquets de signalisation et des paquets de données relatifs à l'appel entre les terminaux T1 et T2 sont échangés entre les ports dont les numéros sont inclus dans les contextes associés aux terminaux T1 et T2, à travers un chemin reliant les serveurs de rattachement des terminaux.

En se référant à la figure 2 pour la description du procédé de rétablissement d'appel selon l'invention, on suppose qu'un terminal appelant T1 dans une installation de télécommunications privée IT1 est rattaché à une chaîne d'appel de terminal appelant dans un serveur d'appel de secours SAS1 à
travers une passerelle PAl et un réseau local RL1 après que le serveur d'appel principal SAP1 de l'installation IT1 soit devenu défaillant. Les données du contexte de l'appel entre le terminal appelant T1 et un terminal appelé T2, à l'exception du numéro de port de la chaîne d'appel dans le
17 serveur défaillant qui est inutile dans le serveur d'appel de secours, ont été transférées du serveur d'appel principal SAP1 dans le serveur d'appel de secours SAS1. Le terminal appelé T2 est rattaché à
travers une passerelle PA2 et un réseau local RL2 à
une chaîne d'appel de terminal appelé qui a été créée par le module d'appel simple MAS2 dans un serveur d'appel principal SAP2 lors de l'établissement de l'appel.
Selon la réalisation illustrée à la figure 2, les serveurs d'appel SAP1 et SAP2 sont distincts.

Les terminaux T1 et T2 étant en communication antérieurement à la défaillance du serveur d'appel principal SAP1 de l'installation IT1, le module de contexte d'appel MCA2 de la chaîne d'appel associée au terminal appelé T2 dans le serveur SAP2 a mémorisé
un contexte d'appel CT2. Le contexte CT2 inclut en outre l'adresse du terminal appelé T2, l'adresse du terminal appelant T1, le numéro de port de la chaîne d'appel CH2 (MG2, MCA2) dans le serveur SAP2 et le numéro de port de la chaîne d'appel CH1 (MG1, MCA1) dans le serveur d'appel principal défaillant SAP1 auquel le terminal appelant T1 est rattaché pour atteindre le serveur défaillant.
Le procédé de rétablissement d'appel comprend des étapes El à E9 montrées à la figure 3, afin que le serveur d'appel de secours SAS1 se substituant au serveur d'appel principal défaillant SAP1 reprenne la supervision d'appels simples dans l'installation IT1.
Le chemin notamment pour des données de phonie entre les terminaux T1 et T2 est rompu. Cependant les terminaux T1 et T2 ignorent la rupture de ce chemin, comme indiqué à travers une liaison de réseau LR en trait pointillé à la figure 2. Les terminaux T1 et T2
18 sont transparents au rétablissement d'appel si les terminaux demeurent à l'état où ils étaient juste avant la défaillance du serveur SAP1, c'est-à-dire si aucun des usagers des terminaux T1 et T2 n'effectue une action modifiant l'appel telle un raccrochage, une mise en garde ou un transfert d'appel par exemple. Comme on le verra ci-après, les contextes associés aux terminaux servent alors à masquer la défaillance du serveur d'appel principal de manière à
rétablir un chemin entre les terminaux. Les appels en garde et les appels complexes comme un double appel et les appels d'opératrice sont libérés et ne sont donc pas repris par le serveur d'appel de secours SAS1.
A la suite de la défaillance du serveur SAP1 et du remplacement du serveur défaillant SAP1 par le serveur d'appel de secours SAS1, le module d'observation de trafic MOT1 dans le serveur SAS1 lit en mémoire tous les contextes d'appel relatifs à des appels précédemment établis avant la défaillance et notamment le contexte d'appel CT1 relatif à l'appel du terminal appelant T1 et associé à l'adresse du terminal appelant, à l'étape El. Le module d'observation de trafic MOT1 crée un module de gestion logiciel MG1 relatif à l'appel du terminal appelant T1 à l'étape E2. Au moyen du module de gestion logiciel MG1, le serveur de secours SAS1 communique localement par paquets de signalisation avec le terminal appelant T1 à travers le réseau local RL1 et la passerelle PA1, à l'étape E3. Puis le module de gestion MG1 crée un module logiciel de contexte d'appel MCA1 relatif à l'appel du terminal appelant T1, à l'étape E4. Une chaîne d'appel (MG1, MCA1) associée au contexte d'appel CT1 et donc au terminal appelant T1 est ainsi recréée dans le
19 serveur de secours SAS1 et présente dans le serveur d'appel de secours SAS1 un numéro de port, en tant que référence de chaîne d'appel, qui est introduit dans le contexte d'appel CT1 hérité du serveur défaillant à la place du numéro de port de la chaîne d'appel correspondante supprimée dans le serveur défaillant SAP1. Si le terminal T1 participant à un appel et rattaché au serveur d'appel défaillant SAP1 décide de rompre l'appel avant que le serveur d'appel de secours SAS1 rétablisse l'appel, la rupture d'appel ne sera considérée qu'après création de la chaîne d'appel associée au terminal dans le serveur SAS1.
Le chemin d'appel précédemment établi pour les terminaux T1 et T2 entre la chaîne d'appel dans le serveur d'appel principal devenu défaillant et la chaîne d'appel dans le serveur d'appel principal SAP2 est perdu et le serveur de secours SAS1 doit recréer un autre chemin d'appel vers le serveur SAP2 pour les terminaux T1 et T2. A l'étape E5 dans le serveur SAS1, le module de gestion MG1 commande une simulation de prise de ligne ou canal (décrochage) par le terminal T1 dans le module de contexte MCA1, c'est-à-dire une demande d'établissement d'appel par le terminal T1, en transmettant via l'adaptateur AD1 un message de demande de rétablissement d'appel SIG1 au serveur SAP2 dont l'adresse est déduite de l'adresse du terminal T2 extraite du contexte actualisé CT1 associé au terminal T1 et lu à l'étape El. Le message SIG1 contient l'adresse du terminal appelant T1, l'adresse du terminal appelé T2, le numéro de port de la chaîne d'appel récemment créée (MG1, MCA1) dans le serveur de secours et le numéro de port de la chaîne d'appel de terminal appelé (MG2, MCA2), ces adresses de terminal et numéro de port étant extraits du contexte actualisé M. Le module de contexte MCA1 dans le serveur d'appel de secours SAS1 déclenche ainsi un autre appel vers le module de contexte d'appel MCA2 désigné par le numéro de port 5 de chaîne d'appel de terminal appelé inclus dans le message SIG1. Le déclenchement de cet autre appel est destiné à recréer entre les serveurs SAS1 et SAP2 un chemin de données relatif à l'appel des terminaux T1 et T2.
10 Dans le serveur SAP2 à l'étape E6, le module d'observation de trafic M0T2 analyse le message de demande de rétablissement d'appel SIG1 afin de rechercher en mémoire un contexte d'appel entre les terminaux T1 et T2. Pour cela, le module M0T2 compare 15 le numéro de port de chaîne d'appel associé au terminal appelé et extrait du message SIG1 à tous les numéros de port, en tant que références de chaîne d'appel en mémoire du serveur SAP2. Si deux numéros de port de chaîne d'appel sont identiques, le numéro
20 de port extrait du message SIG1 est normalement celui de la chaîne d'appel (MG2, MCA2) associée au terminal appelé T2. Si l'indicateur du type de connexion lu dans le contexte CT2 de la chaîne d'appel (MG2, MCA2) retrouvée précédemment et associée au terminal appelé
T2 est compatible avec un rétablissement d'appel, par exemple si l'indicateur n'indique pas de mise en garde par le terminal T2, le module de contexte MCA2 compare alors l'adresse de terminal appelant ADT1 lue dans le contexte mémorisé CT2 associé à la deuxième chaîne d'appel (MG2, MCA2) désignée par le numéro de port extrait et donc associé au terminal T2, à
l'adresse du terminal appelant T1 extraite du message SIG1, à l'étape E7. Si les adresses ADT1 comparées sont identiques, ceci signifie que l'appel entre les terminaux T1 et T2 est retrouvé dans le serveur SAP2.
21 Le module de contexte MCA2 remplace dans le contexte mémorisé CT2 le numéro de port de la chaîne d'appel antérieurement associé au terminal appelant T1 dans le serveur principal défaillant par le numéro de port de la chaîne d'appel récemment créée (MG1, MCA1) extrait du message reçu SIG1, à l'étape E8. La nouvelle association des ports des chaînes d'appel (MG1, MCA1) et (MG2, MCA2) dans le contexte CT2 recrée un chemin de données entre le serveur SAP2 auquel le terminal appelé T2 est rattaché et le serveur SAS1 auquel le terminal appelant T1 est rattaché.
En revanche, le module d'observation de trafic M0T2 ignore le rétablissement d'appel demandé par le message SIG1, commande dans le module MAS2 une libération de l'appel avec le terminal appelant T2 et un effacement en mémoire des modules MG2 et MCA2 à
une étape de refus de rétablissement d'appel ERR pour au moins l'un des cas suivants :
si à l'étape E6, le module M0T2 ne connaît pas de numéro de port dans le message de rétablissement d'appel SIG1 associé à l'une des chaînes d'appel déjà
créées dans le serveur SAP2;
si à l'étape E7, l'indicateur du type de connexion lu dans le contexte CT2 de la chaîne d'appel (MG2, MCA2) retrouvée précédemment et associée au terminal appelé T2 est incompatible avec un rétablissement d'appel, ou si les adresses de terminal appelant comparées sont différentes.
Après l'étape E8, le module de gestion MG2 confirme le rétablissement de l'appel entre les terminaux T1 et T2 à travers le chemin d'appel ainsi créé entre les chaînes d'appel (MG1, MCA1) et (MG2, MCA2) en transmettant via l'adaptateur AD2 un message SIG2 au module de gestion MG1 dans le serveur SAP1, à
22 l'étape E9. Suite à cette confirmation, le module MCA1 enregistre définitivement les ports de ce chemin dans le contexte d'appel CT1 pour l'appel des terminaux T1 et T2. Les modules de gestion MG1 et MG2 renouent le dialogue entre les terminaux T1 et T2 en aboutant au chemin créé entre les serveurs SAS1 et SAP2 le chemin entre le serveur SAS1 et le terminal T1 dans l'installation IT1 et le chemin entre le serveur SAP2 et le terminal T2 dans l'installation IT2. Les modules d'appel simple MAS1 et MAS2 reprennent la surveillance de l'appel rétabli dans les serveurs SAS1 et SAP2 notamment dans l'attente d'une libération d'appel (raccrochage) par l'un des terminaux T1 et T2.
En pratique le rétablissement d'un appel est de l'ordre de 10 millisecondes, ce qui nécessite une durée de 50 secondes environ pour un serveur traitant 5000 appels à rétablir, durée sensiblement égale à la durée moyenne d'un appel.
On notera que si le serveur d'appel principal SAP2 auquel le terminal appelé T2 est rattaché
devient défaillant et est remplacé par un serveur de secours SAS2 de l'installation IT2, tout se passe pour l'exécution des étapes de rétablissement d'appel El à E9 décrites précédemment comme si le serveur de secours SAS2 était le serveur SAS1 dans la figure 1 et le serveur d'appel principal non défaillant SAP1 auquel le terminal appelé T1 est rattaché était le serveur SAP2 dans la figure 1. Par conséquent le procédé de l'invention est indépendant des caractères appelant et appelé des terminaux T1 et T2.

En variante de la réalisation de la figure 2, le serveur d'appel principal défaillant SAP1 et le
23 serveur d'appel principal SAP2 ont leurs fonctionnalités réunies dans un unique serveur d'appel SAP1 dans une installation de télécommunications privée IT commune aux terminaux T1 et T2, comme montré à la figure 1. Dans cette variante, le rétablissement de l'appel entre les terminaux T1 et T2 rattachés au serveur d'appel de secours SAS1 remplaçant le serveur d'appel défaillant SAP1 comprend des étapes analogues aux étapes El à E9 entre une chaîne d'appel (MG1, MCA1) créée en association au terminal appelant T1 et une chaîne d'appel (MG2, MCA2) qui est créée en association au terminal appelé T2 d'une manière analogue aux étapes El à E4. Le chemin de données pour le rétablissement d'appel entre les terminaux T1 et T2 est alors directement créé entre les chaînes d'appel créées (MG1, MCA1) et (MG2, MCA2) dans le serveur de secours.

Selon encore une autre variante, il est supposé
que le serveur d'appel principal SAP1 de l'installation IT1 devienne défaillant brièvement, par exemple suite à une microcoupure engendrant un effondrement des chaînes d'appel, puis une reprise du fonctionnement du serveur SAP1, sans recourir à un serveur de secours. Dans cette autre variante, le serveur SAP1 est considéré comme confondu avec le serveur de secours SAS1 dans l'exécution des étapes de rétablissement d'appel El à E9.
Si le premier serveur d'appel SAP1 et le deuxième serveur d'appel SAP2 sont réunis en un unique serveur d'appel qui devient brièvement défaillant, des étapes analogues aux étapes El à E4 et relatives à la création d'une deuxième chaîne d'appel (MG2, MCA2) à associer au terminal T2 peuvent
24 être exécutées si la deuxième partie de l'unique serveur d'appel incluant des deuxièmes chaînes d'appel devient aussi défaillante. Dans ce cas, le procédé de rétablissement d'appel entre les terminaux T1 et T2 inclus dans une installation de télécommunications commune comprend une étape de créer la deuxième chaîne d'appel (MG2, MCA2) associée au deuxième terminal T2 et à un deuxième contexte CT2 de l'appel préalablement mémorisé dans l'unique serveur d'appel.

L'invention décrite ici concerne un procédé et un serveur d'appel. Selon une implémentation, les étapes du procédé de l'invention sont déterminées par les instructions d'un programme d'ordinateur incorporé dans le serveur d'appel. Le programme comporte des instructions de programme qui, lorsque ledit programme est exécuté dans le serveur d'appel dont le fonctionnement est alors commandé par l'exécution du programme, réalisent les étapes du procédé selon l'invention.
En conséquence, l'invention s'applique également à un programme d'ordinateur, notamment un programme d'ordinateur enregistré sur ou dans un support d'informations lisible par un ordinateur ou tout dispositif de traitements de données, adapté à mettre en ceuvre l'invention. Ce programme peut 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 pour implémenter le procédé selon l'invention.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme, comme une mémoire, un disque dur ou une clé USB, ou un circuit intégré dans lequel le programme est incorporé.

Claims (11)

REVENDICATIONS
1 - Procédé pour rétablir un appel précédemment établi entre un premier terminal (T1) rattaché à un premier serveur d'appel (SAS1) et un deuxième terminal (T2) rattaché à un deuxième serveur d'appel (SAP2), caractérisé en ce qu'il comprend les étapes de :
créer (E2, E4) une première chaîne d'appel (MG1, MCA1) associée au premier terminal (T1) et à un premier contexte (CT1) de l'appel préalablement mémorisé dans le premier serveur d'appel (SAS1), transmettre (E5) une demande de rétablissement d'appel (SIG1) incluant une référence de deuxième chaîne d'appel extraite du premier contexte (CT1) depuis le premier serveur d'appel vers le deuxième serveur d'appel, rechercher (E6, E7, E8) dans le deuxième serveur d'appel une deuxième chaîne d'appel (MG2, MCA2) en fonction de la référence de deuxième chaîne d'appel incluse dans la demande de rétablissement d'appel, et si la deuxième chaîne d'appel est trouvée en association au deuxième terminal (T2), confirmer (E9) un rétablissement de l'appel entre les premier et deuxième terminaux à travers un chemin entre les première et deuxième chaînes d'appel, par le deuxième serveur d'appel au premier serveur d'appel.
2 - Procédé conforme à la revendication 1, selon lequel la demande de rétablissement d'appel (SIG1) contient l'adresse du premier terminal (T1), l'adresse du deuxième terminal (T2), et la référence de la deuxième chaîne d'appel (MG2, MCA2) extraits du premier contexte (CT1), et la référence de la première chaîne d'appel (MG1, MCA1) créée dans le premier serveur d'appel.
3 - Procédé conforme à la revendication 2, selon lequel l'étape de rechercher comprend dans le deuxième serveur :
une comparaison (E6) de la référence de deuxième chaîne extraite de la demande de rétablissement d'appel (SIG1) à des références de chaîne d'appel mémorisées dans le deuxième serveur d'appel (SAP2), si deux références de chaîne d'appel sont identiques, une comparaison (E7) de l'adresse (ADT1) du premier terminal (T1) lue dans un deuxième contexte (CT2) associé à la deuxième chaîne d'appel (MG2, MCA2) désignée par la référence extraite, à
l'adresse du premier terminal extraite de la demande de rétablissement d'appel, et si les adresses comparées sont identiques, un remplacement (E6) d'une référence de première chaîne d'appel antérieurement associée au premier terminal par la référence de la première chaîne d'appel créée (MG1, MCA1) extraite de la demande de rétablissement d'appel.
4 - Procédé conforme à l'une quelconque des revendications 1 à 3, selon lequel le premier serveur d'appel (SAS1) est un serveur de secours adapté à
remplacer un serveur d'appel (SAP1) devenu défaillant et auquel est rattaché le premier terminal (T1) lors de l'appel précédemment établi.

- Procédé conforme à l'une quelconque des revendications 1 à 4, selon lequel le premier serveur d'appel et le deuxième serveur d'appel sont réunis en un unique serveur d'appel (SAP).
28
6 - Procédé conforme à la revendication 5, comprenant une étape de créer une deuxième chaîne d'appel (MG2, MCA2) associée au deuxième terminal (T2) et à un deuxième contexte (CT2) de l'appel préalablement mémorisé dans l'unique serveur d'appel.
7 - Système pour rétablir un appel précédemment établi entre un premier terminal (T1) rattaché à un premier serveur d'appel (SAS1) et un deuxième terminal (T2) rattaché à un deuxième serveur d'appel (SAP2), caractérisé en ce qu'il comprend :
un moyen (MOT1) dans le premier serveur d'appel (SAS1) pour créer une première chaîne d'appel (MG1, MCA1) associée au premier terminal (T1) et à un premier contexte (CT1) de l'appel préalablement mémorisé dans le premier serveur d'appel, un moyen (MCA1, AD1) dans le premier serveur d'appel (SAS1) pour transmettre une demande de rétablissement d'appel (SIG1) incluant une référence de deuxième chaîne d'appel extraite du premier contexte (CT1) vers le deuxième serveur d'appel, un moyen (MOT2) dans le deuxième serveur pour rechercher une deuxième chaîne d'appel (MG2, MCA2) en fonction de la référence de deuxième chaîne d'appel incluse dans la demande de rétablissement d'appel, et si la deuxième chaîne d'appel est trouvée en association au deuxième terminal (T2), un moyen (MG2, AD2) dans le deuxième serveur pour confirmer un rétablissement de l'appel entre les premier et deuxième terminaux à travers un chemin entre les première et deuxième chaînes d'appel, par le deuxième serveur d'appel au premier serveur d'appel.
8 - Serveur d'appel adapté à rétablir un appel précédemment établi entre un premier terminal (T1) qui lui est rattaché et un deuxième terminal (T2) rattaché à un deuxième serveur d'appel (SAP2), caractérisé en ce qu'il comprend :
un moyen (MOT1) pour créer une première chaîne d'appel (MG1, MCA1) associée au premier terminal (T1) et à un premier contexte (CT1) du premier appel préalablement mémorisé dans le serveur d'appel, et un moyen (MCA1, AD1) pour transmettre une demande de rétablissement d'appel (SIG1) incluant une référence de deuxième chaîne d'appel extraite du premier contexte (CT1) vers le deuxième serveur d'appel, afin que le deuxième serveur recherche une deuxième chaîne d'appel (MG2, MCA2) en fonction de la référence de deuxième chaîne d'appel incluse dans la demande de rétablissement d'appel, et si la deuxième chaîne d'appel est trouvée en association au deuxième terminal (T2), confirme un rétablissement de l'appel entre les premier et deuxième terminaux à travers un chemin entre les première et deuxième chaînes d'appel, audit serveur d'appel.
9 - Serveur d'appel pour rétablir un appel précédemment établi entre un premier terminal (T1) rattaché à un premier serveur d'appel (SAS1) et un deuxième terminal (T2) qui lui est rattaché, caractérisé en ce qu'il comprend :
un moyen (MOT2) pour rechercher une deuxième chaîne d'appel (MG2, MCA2) en fonction d'une référence de deuxième chaîne d'appel incluse dans une demande de rétablissement d'appel transmise par le premier serveur d'appel (SAS1) et extraite d'un premier contexte (CT1) de l'appel préalablement mémorisé dans le premier serveur d'appel ayant créé
une première chaîne d'appel (MG1, MCA1) associée au premier terminal (T1), et si la deuxième chaîne d'appel est trouvée en association au deuxième terminal (T2), un moyen (MG2, AD2) pour confirmer un rétablissement de l'appel entre les premier et deuxième terminaux à
travers un chemin entre les première et deuxième chaînes d'appel au premier serveur d'appel.
- Programme d'ordinateur apte à être mis en oeuvre dans un serveur d'appel adapté à rétablir un appel précédemment établi entre un premier terminal (T1) qui lui est rattaché et un deuxième terminal (T2) rattaché à un deuxième serveur d'appel (SAP2),, ledit programme étant caractérisé en ce qu'il comprend des instructions qui, lorsque le programme est chargé et exécuté dans ledit serveur d'appel, réalisent les étapes suivantes :
créer (E2, E4) une première chaîne d'appel (MG1, MCA1) associée au premier terminal (T1) et à un premier contexte (CT1) du premier appel préalablement mémorisé dans le serveur d'appel, et transmettre (E5) une demande de rétablissement d'appel (SIG1) incluant une référence de deuxième chaîne d'appel extraite du premier contexte (CT1) vers le deuxième serveur d'appel, afin que le deuxième serveur recherche une deuxième chaîne d'appel (MG2, MCA2) en fonction de la référence de deuxième chaîne d'appel incluse dans la demande de rétablissement d'appel, et si la deuxième chaîne d'appel est trouvée en association au deuxième terminal (T2), confirme un rétablissement de l'appel entre les premier et deuxième terminaux à travers un chemin entre les première et deuxième chaînes d'appel, audit serveur d'appel.
11 - Programme d'ordinateur apte à être mis en oeuvre dans un serveur d'appel adapté à rétablir un appel précédemment établi entre un premier terminal (T1) rattaché à un premier serveur d'appel (SAS1) et un deuxième terminal (T2) qui lui est rattaché, ledit programme étant caractérisé en ce qu'il comprend des instructions qui, lorsque le programme est chargé et exécuté dans ledit serveur d'appel, réalisent les étapes suivantes :
rechercher (E6, E7, E8) une deuxième chaîne d'appel (MG2, MCA2) en fonction d'une référence de deuxième chaîne d'appel incluse dans une demande de rétablissement d'appel transmise par le premier serveur d'appel (SAS1) et extrait d'un premier contexte (CT1) de l'appel préalablement mémorisé dans le premier serveur d'appel ayant créé une première chaîne d'appel (MG1, MCA1) associée au premier terminal (T1), et si la deuxième chaîne d'appel est trouvée en association au deuxième terminal (T2), confirmer (E9) un rétablissement de l'appel entre les premier et deuxième terminaux à travers un chemin entre les première et deuxième chaînes d'appel au premier serveur d'appel.
CA002658253A 2006-07-13 2007-07-10 Retablissement d'appel dans un serveur d'appel d'installation de telecommunications privee Abandoned CA2658253A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0606411 2006-07-13
FR0606411A FR2903835B1 (fr) 2006-07-13 2006-07-13 Retablissement d'appel dans un serveur d'appel d'installation de telecommunications privee
PCT/FR2007/051624 WO2008007010A2 (fr) 2006-07-13 2007-07-10 Retablissement d'appel dans un serveur d'appel d'installation de telecommunications privee

Publications (1)

Publication Number Publication Date
CA2658253A1 true CA2658253A1 (fr) 2008-01-17

Family

ID=37716112

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002658253A Abandoned CA2658253A1 (fr) 2006-07-13 2007-07-10 Retablissement d'appel dans un serveur d'appel d'installation de telecommunications privee

Country Status (5)

Country Link
US (1) US20100014654A1 (fr)
EP (1) EP2050262A2 (fr)
CA (1) CA2658253A1 (fr)
FR (1) FR2903835B1 (fr)
WO (1) WO2008007010A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8914850B1 (en) * 2011-10-14 2014-12-16 West Corporation Context aware transactions performed on integrated service platforms

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6292551B1 (en) * 1998-02-04 2001-09-18 Avaya Technology Corp. Call reestablishment system
EP1292158B1 (fr) * 2001-09-06 2010-07-21 Hewlett-Packard Company Procédé de rétablissement d'appel et commutateurs adaptés
US7228145B2 (en) * 2003-05-21 2007-06-05 Avaya Technology Corp. Dropped call continuation
US7587031B1 (en) * 2005-12-22 2009-09-08 Nortel Networks Limited Forced hold call handling in a VoP environment

Also Published As

Publication number Publication date
FR2903835B1 (fr) 2008-10-17
EP2050262A2 (fr) 2009-04-22
WO2008007010A3 (fr) 2008-03-13
WO2008007010A2 (fr) 2008-01-17
FR2903835A1 (fr) 2008-01-18
US20100014654A1 (en) 2010-01-21

Similar Documents

Publication Publication Date Title
US7870265B2 (en) System and method for managing communications sessions in a network
MX2007004127A (es) Sistema y metodos para una red remota superviviente.
EP1519516A2 (fr) Procédé d&#39;établissement d&#39;un transfert de données entre deux dispositifs de communication et dispositif associé
FR2680621A1 (fr) Procede et installation de visiophonie.
EP0840489A1 (fr) Compatibilité entre un service téléphonique avec serveur et un service RNIS d&#39;identification de demandeur
US8634534B1 (en) Call recovery
EP2606626B1 (fr) Traitement de transfert de communication en mode sip
EP2371106A1 (fr) Procede de notification et passerelle d&#39;acces a un reseau de voix sur ip
CN101159719B (zh) 实现故障条件下通话的VoIP模拟网关及内部交换方法
CA2658253A1 (fr) Retablissement d&#39;appel dans un serveur d&#39;appel d&#39;installation de telecommunications privee
CA2531404A1 (fr) Methode et appareil pour fournir des annonces reseau au sujet de derangements de service
US20040052350A1 (en) System and method for delivering enhanced voice and data services in parallel with an incumbent phone company
EP1349400A1 (fr) Fourniture de services pour terminaux privés distants
EP1879368A1 (fr) Enregistrement de communications dans un réseau de télécommunications
EP1676420B1 (fr) Améliorations concernant systèmes tolérants aux défaillances
WO2003105497B1 (fr) Procede et systeme permettant d&#39;utiliser efficacement des circuits de transmission vocale pour acceder a une ressource de service dans le rtpc
EP1113632B1 (fr) Procédé et dispositif pour la restitution des signaux de parole transmis au début d&#39;une communication téléphonique par l&#39;échange de paquets
EP1676412B1 (fr) Procédé pour etablir un liaison directe de coordination entre un premier et un secnd centres de commande d&#39;execution de services
EP3785486A1 (fr) Procédé et système de détection d&#39;interruption de com-munications et de rétablissement automatique des communications
EP1427136B1 (fr) Dispositif de contrôle d&#39;admission de niveau réseau pour un réseau de communications à protocole de niveau sous-IP
WO2023047068A1 (fr) Procede de controle d&#39;un acces a un service applicatif mis en œuvre dans un reseau de telecommunications, procede de traitement d&#39;un message de controle d&#39;un acces audit service applicatif, dispositifs, equipement de controle, equipement client, systeme et programmes d&#39;ordinateur correspondants
EP1139219A1 (fr) Controle d&#39;acces aux services de télécommunication
EP1936934A1 (fr) Procédé de diffusion d&#39;un flux depuis une plate-forme de service, produit programme d&#39;ordinateur et plate-forme de service correspondants
WO2003071776A1 (fr) Systeme et procede de cooperation d&#39;une plateforme de service telephonique avec une plateforme de service de type internet
FR2860936A1 (fr) Procede et systeme de controle de communication multi-terminaux

Legal Events

Date Code Title Description
EEER Examination request
FZDE Discontinued

Effective date: 20131227