Guide Produit MiVoice 5000 R8.0
17 – Architecture MiVoice 5000 Cluster
et Multisite
BPS0141HFRAA01
SEPTEMBRE 2022
EDITION 2
REVISION INFORMATION
ed1 : 03/05/2022 – création
ed1 : 07/09/2022 – correction paragraphe 17.2.5
The information conveyed in this document is confidential and proprietary to Mitel® and is intended solely for Mitel
employees and members of Mitel’s reseller channel who specifically have a need to know this information. If you are not a
Mitel employee or a Mitel authorized PARTNER, you are not the intended recipient of this information. Please delete or
return any related material. Mitel will enforce its right to protect its confidential and proprietary information and failure to
comply with the foregoing may result in legal action against you or your company.
Table of Contents
Revision Information ............................................................................................................... 2
17
Architecture MiVoice 5000 Cluster et Multisite............................................................... 4
17.1
Préambule .......................................................................................................................... 4
17.1.1
Le Multisite et le Cluster ............................................................................................... 5
17.1.2
Avantage de la mise en réseau MiVoice 5000 .............................................................. 7
17.1.3
Mise en réseau MOVACS............................................................................................. 9
17.1.4
Serveur de Numérotation SDN ................................................................................... 10
17.1.5
Service de localisation géographique sur réseau IP ................................................... 11
17.1.6
Gestion de la congestion-débordement ...................................................................... 12
17.2
Architecture Multisite......................................................................................................... 13
17.2.1
Principes d’un multisite MOVACS............................................................................... 13
17.2.2
Services Multisites MiVoice 5000 ............................................................................... 16
17.2.3
Mise en réseau IP....................................................................................................... 18
17.2.4
Interfonctionnement de versions hétérogènes ............................................................ 20
17.3
Architecture Cluster .......................................................................................................... 22
17.3.1
Principe général ......................................................................................................... 22
17.3.2
Ingénierie d’un MiVoice 5000 Cluster ......................................................................... 24
17.3.3
MiVoice 5000 Cluster ................................................................................................. 26
17.3.4
Services MiVoice 5000 Cluster ................................................................................... 27
17.3.5
Mode autonome ......................................................................................................... 29
17.4
Architecture XXL ............................................................................................................... 32
17.4.1
Principe général ......................................................................................................... 32
17.4.2
Services XXL .............................................................................................................. 34
17.4.3
Mode survivabilité – Backup du Cluster Server........................................................... 36
17.5
Services réseau communs ................................................................................................ 41
17.5.1
Services vocaux ......................................................................................................... 41
17.5.2
Gestion des appels d’urgence .................................................................................... 46
17.5.2.1
17.5.2.2
17.5.2.3
17.5.2.4
Accès trunk SIP centralisés .....................................................................................................47
Accès opérateur TDM centralisés ............................................................................................49
Accès opérateur TDM décentralisés ........................................................................................ 50
Particularités ............................................................................................................................51
3/51
17 ARCHITECTURE MIVOICE 5000 CLUSTER ET MULTISITE
17.1 PRÉAMBULE
Depuis la version R6.1, la solution MiVoice 5000 dispose d’un nouveau mode de mise en réseau avec
transparence de service ayant des capacités accrues pouvant regrouper jusqu’à 230 équipements MiVoice
5000 : passerelles ou Call Manager. Cette architecture est appelée « MiVoice 5000 Cluster » qui complète
l’architecture « multisite » d’une capacité de 99 équipements MiVoice 5000 passerelles ou Call Manager.
Depuis, la version R6.5, la solution MiVoice 5000 s’est enrichie en introduisant une nouvelle souplesse en
matière de gestion du parc existant en mode cluster, consistant à la mise en place d’une procédure progressive
pour mettre à niveau un cluster en plusieurs étapes, avec la prise en charge de la connexion entre le cluster
Server et les nœuds.
Cette nouvelle fonctionnalité a été rendue possible par l’introduction depuis la version MiVoice 5000 Manager
R3.5 d’une méthode de mise à jour logicielle (unique et améliorée pour le MiVoice 5000) permettant la mise à
jour des nœuds en plusieurs étapes avec le Manager
Depuis la version R7.0, la solution MiVoice 5000 permet la prise en compte des Mitel EX Controller en tant que
passerelle.
4/51
17.1.1 LE MULTISITE ET LE CLUSTER
Architecture Multisite
La mise en réseau multisite consiste à connecter plusieurs Call Manager ou passerelles Mitel 5000 Gateways
disposant tous, du même logiciel MiVoice 5000 et à proposer une transparence de service de communication
d’entreprises.
Chacun de ces équipements peut gérer un ensemble d’accès réseau et d’abonnés et dispose de ses propres
capacités de traitement pour ses abonnés. Les licences sont à déverrouiller localement.
Bien que constitué par un ensemble de sites, le mode multisite dispose des avantages de mobilité, tel que le
Free Seating ou la facilité de déménagement sans changer de numéro. Le secours entre iPbx est possible avec
la fonction Dual Homing.
Le réseau multisite MiVoice 5000 peut être composé des iPbx de la gamme MiVoice 5000 R8.0, R7.2, R7.1,
R7.0, et R6.5: les gateways Mitel 5000 XS, XL, XD, Mitel 500, Mitel EX Controller et le Call Manager IP MiVoice
5000 Server.
L’interfonctionnement de différentes versions s’applique généralement sur les fonctionnalités de la version de
plus bas niveau dans le mode multisite. Pour plus de détails, voir le paragraphe ci-après « Interconnexion de
versions hétérogènes ».
5/51
Architecture MiVoice 5000 Cluster
La mise en réseau MiVoice 5000 Cluster consiste en un serveur maitre de Cluster : MiVoice 5000 Cluster
Server qui centralise l’ensemble des abonnés, jusqu’à 20 000, ainsi que l’ensemble des licences avec une
configuration centralisée des fonctionnalités communes au Cluster.
MiVoice 5000 Cluster Server est en réseau avec un ensemble de nœuds jusqu’à 230 : MiVoice 5000 Server,
Mitel EX Controller, Mitel 5000 Compact, Mitel 5000 Gateways et Mitel 500. Ces nœuds peuvent raccorder des
abonnés analogiques ou numériques ainsi que des accès opérateur.
Les nœuds peuvent toujours secourir des abonnés en Dual Homing mais en fonctionnement normal l’ensemble
des abonnés IP, SIP, analogiques et numériques sont gérés depuis le Cluster Server.
L’ensemble des équipements d’un Cluster sont administrés par MiVoice 5000 Manager
Depuis la version MiVoice 5000 R6.5, l’obligation existant jusqu’à la version R6.4 (incluse) d’avoir la
même version logicielle dans un Cluster a été levée en introduisant une mise à niveau à leur propre rythme,
c'est-à-dire pas à pas, afin d'apporter une plus grande flexibilité de mise à niveau aux clusters MiVoice 5000.
Un MiVoice 5000 Cluster : Cluster Server et nœuds, est vu comme un site unique dans la logique MOVACS. Il
peut donc faire partie d'un réseau multisite. On parle alors d’architecture XXL.
Depuis la version MiVoice 5000 R7.0, le nouveau produit Mitel EX Controller est pris en compte dans la
solution
Architecture XXL
Une architecture XXL présente la même topologie de mise en réseau qu’un multisite, avec la particularité
d’inclure des MiVoice 5000 Clusters en plus des MiVoice 5000 Servers ou des passerelles Mitel 5000
Gateways et Mitel 500 dans un même réseau MOVACS, cet ensemble étant administré par un MiVoice 5000
Manager.
Cette architecture permet de répondre à des dimensionnements plus grands en nombre d’équipements ;
jusqu’à 2000 et en nombre d’abonnés ; jusqu’à 300 000, ainsi que de répondre à des besoins fonctionnels et
opérationnels pour la migration d’’une architecture multisite vers une architecture MiVoice 5000 Cluster.
6/51
17.1.2 AVANTAGE DE LA MISE EN RESEAU MIVOICE 5000
Du point de vue terminologie, il y a lieu de distinguer une simple mise en réseau d'iPbx d’une configuration
MiVoice 5000 homogène multisite ou Cluster
Cette dernière permet d'offrir aux utilisateurs une numérotation et des facilités qui sont celles d'un serveur
d’appel unique alors que la simple mise en réseau classique telle que celle réalisée depuis des années par les
systèmes de téléphonie privés, n'offre pas ces avantages.
Les solutions MiVoice 5000 offrent les deux possibilités par leur architecture ouverte de dernières générations.
Pour les utilisateurs finaux, la mise en réseaux MiVoice 5000 comporte de nombreux atouts comme :
 L’optimisation des coûts :




Les communications intersites sont routées via les liens privés,

L’utilisation des mécanismes de Least Cost Routing afin d’avoir un appel local à la place d’un
appel longue distance,

L’optimisation des liens opérateurs (accès centralisés, partage de charge)

La centralisation de serveurs comme la messagerie vocale et/ou vidéo, des services d’accueil
téléphonique comme les postes opérateurs,

La facturation et analyse de trafic commune.
Un même niveau de service pour tous les sites :

Un réseau homogène voix, vidéo, partage d’application

Plan de numérotation homogène,

Service de collaboration téléphonique : filtrage, supervision, messages écrits, distribution vers
différents groupements, appel par le nom…,

Ergonomie et fonctionnalités traditionnelles communes : transferts, renvois, rappels…,

Mobilité des utilisateurs et localisation de l’abonné automatique (login-logout de l’usager,
roaming DECT) et gestion des numéros d’urgence,

Une fonction de numéro unique quelques soit les postes utilisés

Agents centre de contacts distribués,

Résilience : duplication MiVoice 5000, Dual Homing

Réseau sécurisé : confidentialité, cryptage SRTP de communication, authentification,
traçabilité.
Un service homogène : un seul point d’entrée pour un client,
Une gestion d’entreprise simplifiée : sur chacun des sites, les utilisateurs peuvent accéder aux
mêmes facultés téléphoniques facilitant la flexibilité des usagers.
Centralisation des accès aux réseaux
Un des attraits du déploiement d’une architecture MiVoice 5000 en réseau, concerne la centralisation des
accès opérateurs (réseau public, Trunk SIP). Cela permet d’optimiser les frais de raccordement et l’utilisation
de ces accès ainsi que les investissements consentis (abonnement opérateur, Licences Trunk SIP ou carte de
raccordement).
Il est toutefois possible de conserver des accès opérateur distribués, soit pour des raisons de sécurisation, soit
pour des raisons économiques (mécanismes de Least Cost Routing).
7/51
Centralisation des ressources IT
Afin d'éviter la multiplication des serveurs physiques et favoriser la cohérence d'exploitation d'un réseau
MiVoice 5000, il est possible de centraliser les applications et services de la solution MiVoice 5000 ainsi que
son écosystème sur des serveurs centraux pour adresser l’ensemble des usagers du réseau.
Services internes MiVoice 5000 :
 Services annuaire LDAP : la centralisation du service annuaire offre la possibilité d’appel par le nom à
partir de la même base pour l’ensemble des usagers. Cette centralisation s’accompagne également de
la possibilité de sécurisation du service annuaire.
 Serveur De Numérotation (SDN): Gestion du plan de numérotation global et homogène à partir de la
base LDAP centralisée,
 Serveur de traduction téléphonique (STT): centralisation du reroutage en cas de débordement et pour
le service de Least Cost Routing (LCR),
 Serveur de distribution des appels vers les opérateurs,
 Serveur de Call Admission Control (CAC) : prévient des congestions du réseau et gère la localisation
des usagers dans le cadre des appels d’urgences et d’autres services voix.
 Serveur de tickets d'appels et buffer de tickets d'appels.
Serveurs applicatifs et écosystème :
Il est également possible de centraliser les serveurs externes d’applications associées comme :
 Serveur Vocal Interactif Mitel 5000 Contact Center SVI
 Centre de contacts Mitel 5000 Contact Center
 Messagerie unifiée UCP
 Serveur d’alarme AS7900 : diffusion de messages d’alarme sur terminal DECT,
 Facturation et observation de trafic (centralisation des tickets de taxation) : VTPro
 Serveur d’Administration et de supervision du réseau : MiVoice 5000 Manager
 Offre tierce applicative partenaire s’intégrant sur les interfaces ouvertes de MiVoice 5000
 MiCollab pont de conférence ou solution CTI, Softphone
Centralisation des postes opérateurs
Les postes opérateurs peuvent être centralisés et organisés en services.
Un service opérateur est un groupe d'opérateurs traitant le même trafic. Il peut toutefois être intéressant de
répartir les services opérateurs sur différents sites pour des raisons de sécurisation ou de traitement au plus
près des accès opérateur.
Il est également possible de constituer des groupes (à base soc/ser) sur le réseau MiVoice 5000 avec des
accueils dédiés par groupe quelle que soit la localisation des usagers.
La numérotation homogène
La mise en réseau MiVoice 5000 multisite ou Cluster permet de s'affranchir de la dispersion géographique et
de retrouver les mêmes services en tout point du réseau et en particulier un plan de numérotation unique et
homogène.
8/51
17.1.3 MISE EN RÉSEAU MOVACS
La mise en réseau MOVACS des équipements de la gamme MiVoice 5000 a pour but d’offrir un même service
à tous les utilisateurs du réseau et peut concerner des équipements homogènes ou hétérogènes (de versions
différentes).
Le protocole de mise en réseaux s’appelle MOVACS (Multiswitch Original Virtual Addressing Communication
System).
Atouts de MOVACS
Le protocole MOVACS offre une extrême souplesse d'exploitation, notamment en cas de grande mobilité des
usagers. Par définition, le réseau MiVoice 5000 ne connaît pas la localisation de tous les abonnés, et diffuse
des messages sur le réseau Mitel afin de localiser le site où se trouve l'usager appelé. En effet chaque
plateforme/ iPbx connaît seulement les abonnés déclarés localement.
Le système MOVACS facilité ainsi les fonctions de mobilité tel le Free Seating ou l’association.
MOVACS apporte également beaucoup de sécurité avec des fonctions de secours tel le Dual Homing ou de
routage secondaire par Abonné vital.
Par exemple, dans le cas où l'appel local ne peut aboutir pour une raison quelconque (lien inter-site saturé ou
rompu), le système essaie d'établir l'appel par les moyens de débordement autorisés par la catégorie de
l'appelant.
Ces fonctionnalités sont traitées dans le chapitre « Services téléphoniques MiVoice 5000 » et elles sont
également abordées d’un point de vue architecture dans ce chapitre.
Transport de MOVACS via IP
La mise en réseau sur IP native sur MiVoice 5000 (port IP sur la carte-mère des passerelles ou des serveurs
hébergeant le logiciel MiVoice 5000) permet à l’entreprise de s’appuyer sur son réseau WAN/LAN pour faire
passer ses communications voix et vidéo.
Les différents flux qui peuvent être mis en œuvre dans un réseau IP sont :
 Signalisation inter-équipement MiVoice 5000 sur IP,
 Différentes signalisations de services (tickets de taxe, annuaire, centre de gestion,…) ou applicatives
(couplage téléphonie informatique, CSTA, requête annuaire, gestion de présence…),
 Communication voix, vidéo et chat.
Le déploiement de la voix sur IP nécessite de s’assurer de la capacité de l’infrastructure IP existante ou future à
supporter les prérequis et règles de déploiement de la voix sur IP décrites dans le chapitre « Qualité de
service ».
9/51
17.1.4 SERVEUR DE NUMÉROTATION SDN
Le serveur de numérotation SDN est un service MiVoice 5000 apportant beaucoup de souplesse dans la
gestion du plan de numérotation SDA d’un grand réseau. Ce serveur logiciel intégré dans le logiciel MiVoice
5000 nécessite la mise en place du logiciel MiVoice 5000 Manager pour sa configuration. Il n’est pas soumis à
licences logicielles.
Le SDN permet de rendre totalement indépendant le numéro SDA vis-à-vis du numéro interne et d’apporter
plus de flexibilité dans la gestion du numéro de société (ou NDI) ; en effet de plus en plus de clients souhaitent
avoir une souplesse complète dans l’élaboration de leur plan de numérotation et dans la gestion du NDI/NDS.
Le SDN est particulièrement recommandé dans des architectures avec accès opérateurs centralisés et
plusieurs tranches SDA qui se recoupent.
L’annuaire OpenLDAP MiVoice 5000 est utilisé pour réaliser l’ensemble des transformations liées aux numéros
appelants et appelés. Il va ainsi stocker les informations de numéro interne, numéro SDA, et de numéro de
société (NDI) et va être sollicité par le SDN pour chaque opération faisant appel à une transformation de
numéro ou une résolution de numéro.
Pour plus de détails sur l’utilisation du SDN consulter le chapitre « Plan de numérotation » du Guide Produit.
10/51
17.1.5 SERVICE DE LOCALISATION GEOGRAPHIQUE SUR RESEAU IP
Le service de localisation géographique MiVoice 5000 – inclus dans le logiciel MiVoice 5000 et paramétrable
via l’interface MiVoice 5000 Web Admin – dispose d’une connaissance topologique de l’architecture IP en
place, qui permet de répondre aux différents besoins suivants :
 Contrôle d’Admission d’Appels ou serveur CAC
 Localisation des appels d’urgence
 Attribution des ressources téléphoniques
Contrôle d'Admission d'Appels (CAC)
Le serveur CAC – Call Admission Control – aussi appelé Contrôle d'Admission d'Appels téléphoniques
permet de prévenir les congestions dues à un nombre trop important d'appels, sur le réseau WAN en
particulier.
Ce mécanisme de contrôle permet de refuser l’établissement de nouveaux appels IP de façon à garantir la
qualité des appels déjà établis sur les liens dont la bande passante est limitée ; ce en évitant les situations de
saturation (contrôle basé sur un débit théorique disponible pour la ToIP).
Ce mécanisme permet également de choisir de manière dynamique le meilleur codec possible à base appel en
fonction de la bande passante disponible.
En cas de refus pour cause de saturation (manque de bande passante), il est possible de trouver un chemin de
débordement. Le débordement est décrit dans le paragraphe suivant.
Le serveur CAC prend sa décision en fonction des :
 Données statiques connues du serveur CAC sur la bande passante WAN sur chaque lien concerné ;
 Données dynamiques sur le nombre de communications déjà établies sur ce lien ainsi que les lois de
codage appliquées et applicables (donc quelle fraction de la bande passante).
Pour répondre à ce besoin, le serveur CAC doit connaître la topologie du réseau IP, c’est-à-dire le découpage
en classe CAC – ensemble de sous réseaux – de l’architecture MOVACS ainsi que les restrictions de débits
existantes entre ces classes CAC.
Une classe CAC correspond à un ensemble de sous-réseaux (regroupant des terminaux IP/SIP et/ou des
équipements MiVoice 5000).
Ci-dessous un exemple de découpage CAC :
11/51
Localisation géographique des appels d’urgence
Pour des architectures centralisées avec un accès opérateur centralisé, il est nécessaire de router les appels
d’urgence vers les services d’urgence les plus proches de la localisation de l’appelant.
La localisation des appels d’urgence est basée sur le découpage de l’infrastructure ToIP en sous-réseaux IP.
Ce découpage doit permettre d’associer à chaque site/lieu géographique un sous-réseau spécifique.
Un paragraphe spécifique détaille ce service dans la suite du document.
Attribution de ressources téléphoniques
Le service de localisation géographique permet également de réaliser des optimisations de bande passante en
attribuant les ressources d’accès opérateur au plus proche des terminaux en fonction de leur localisation.
Depuis la version MiVoice 5000 R6.1, la gestion des ressources vocales (guides vocaux, musique de garde et
conférence à 3) est améliorée grâce au service de localisation géographique, aussi bien pour les configurations
MiVoice 5000 Cluster que pour les configurations MiVoice 5000 multisites.
Les bénéfices de cette amélioration portent sur l’optimisation de la bande passante ainsi que sur le
dimensionnement des ressources vocales.
Cette fonction est détaillée dans la suite du document dans le paragraphe « Services vocaux ».
17.1.6 GESTION DE LA CONGESTION-DEBORDEMENT
La mise en réseau MOVACS bénéficie des mécanismes de redondance matérielle de l’infrastructure déployée
(lien WAN dupliqué, , maillage du réseau) ainsi que des mécanismes logiciels dans le cas d’un transport via IP
(signalisation OSPF, RIP …).
De plus, le logiciel MiVoice 5000 contribue également à la sécurisation du réseau en proposant des facultés
complémentaires de gestion de la congestion : mécanismes de débordement.
12/51
17.2 ARCHITECTURE MULTISITE
17.2.1 PRINCIPES D’UN MULTISITE MOVACS
Avec le mode multisite MOVACS, le logiciel MiVoice 5000 peut atteindre une capacité totale de plus de
300.000 abonnés distribués sur près de 99 sites Mitel. Au sein de ce réseau, les usagers disposent d’une
application de Call Manager unique et virtuel.
Topologie du mode Multisite
Les plateformes MiVoice 5000 sont irriguées par la signalisation MOVACS. D’autres signalisations, pour les
différents services (Annuaires, tickets,…) sont également véhiculées dans le réseau.
En mode multisite, une liaison virtuelle de signalisation point à point est établie entre chaque équipement
MiVoice 5000. Cette configuration en réseau maillé est beaucoup plus sécurisée et fiable car chaque système a
connaissance de l’ensemble du réseau. La panne d’un des éléments ne remet pas en cause l’ensemble du
réseau MiVoice 5000. Néanmoins le nombre de liens virtuels peut rapidement devenir laborieux à gérer car
égal à : (n*(n-1)/2), où n représente le nombre de systèmes MiVoice 5000.
Afin de simplifier le maillage de signalisation, une architecture en mode multi-centre est alors préconisée audelà de 15 systèmes actifs.
A la différence de la signalisation, le chemin de voix dans un multisite MOVACS est direct lorsque la mise en
réseaux est IP. Chaque mécanisme a ses particularités et ses règles de déploiements décrits ci-dessous.
13/51
Architecture multi-centre
Afin de limiter le nombre de liens et la diffusion de séries d’unicasts, il est possible de créer des centres. Cette
faculté est intéressante dès que le nombre de système MiVoice 5000 dépasse 15 éléments.
Un ensemble d’équipements MiVoice 5000 est rassemblé dans un centre et l’un d’entre eux est programmé en
tant que serveur de signalisation : passerelle inter-centre. Cette passerelle transmet les unicasts MOVACS
émis par un équipement du centre vers les autres serveurs de signalisation distants. La passerelle inter centre
sert ainsi de relais de signalisation, cette passerelle est secourable.
Il est également possible de déclarer 62 centres, on parle alors d’architecture multi-centre. Chaque centre
peut contenir 15 éléments actifs (1 élément actif est un Mitel 5000 Gateways, un Mitel 500 ou un MiVoice 5000
Server). Une architecture multi-centre est préconisée dans le cadre d’architecture WAN mixant plusieurs
éléments actifs sur chacun des sites ou que le nombre d’éléments actifs dépasse 15.
Gestion des abonnés
De base dans une architecture multisite chaque site/système MiVoice 5000 a la capacité de gérer un ensemble
d’abonnés déclarés dans ce système, certains services (BVI, guides vocaux) seront alors accessibles depuis
ce système. Il est aussi possible de centraliser l’ensemble des abonnés et ne conserver les iPbx locaux que
pour les accès opérateurs et pour le secours.
14/51
Ressources vocales / Accès opérateurs
Chaque système MiVoice 5000 a la capacité d’héberger des ressources vocales (conférence à 3, guides
vocaux, annonces et musiques d’attente) ainsi que des accès opérateur trunk SIP et/ou RNIS sur les
passerelles seulement.
Ces ressources vocales et accès opérateur peuvent être centralisés ou distribués dans une architecture
multisite.
Les différentes possibilités sont décrites dans le paragraphe ci-dessous « services vocaux »
Versions hétérogènes
Afin de proposer une homogénéité de service, au sein d’un multisite, il est nécessaire que les Mitel 5000
Gateways disposent du même palier logiciel. Néanmoins pour des périodes de transition, il est possible de
réaliser des mises en réseau hétérogènes en termes de niveau de version. Pour plus de détails se reporter au
paragraphe « Interfonctionnement de versions hétérogènes ».
15/51
17.2.2 SERVICES MULTISITES MIVOICE 5000
Certaines fonctions particulières en réseaux multisites sont détaillées ci-dessous, pour plus de détails sur les
fonctionnalités téléphoniques MiVoice 5000 se reporter au chapitre « Services téléphoniques MiVoice 5000 ».
Abonné TDM distant (Virtual TDM)
La centralisation des abonnements permet en mode nominal de gérer l’abonné au niveau du Call Manager
MiVoice 5000, en compléments des terminaux IP, SIP, DECT-IP, DECT TDM, les utilisateurs de postes
numériques et analogiques peuvent être déclarés sur un MiVoice 5000 Server via la fonction Virtual TDM.
Cette centralisation peut également être effectuée à travers le portail MiVoice 5000 Web Admin sur un Mitel
5000 Gateways (limité à 500 abonnés VTDM et IP) pour faciliter la gestion des abonnés dans le cas d’une
PME, et apporter des facilités multisite y compris pour les postes TDM. Ci-dessous deux exemples de
centralisation :
Les postes numériques et analogiques bénéficient ainsi des solutions de redondance de MiVoice 5000 Server :
solution MiVoice 5000 duplex ou solution de sécurisation par virtualisation VMware.
De plus, il est possible de secourir ces postes TDM via la fonction de Dual Homing. Le site de backup des
postes numériques et analogiques est le site où ils sont raccordés physiquement.
C'est-à-dire:
 Site principal = Call Manager (abonnement avec Virtual TDM).
 Site secondaire = Passerelle de type Mitel 5000 Gateways avec l’équipement physique pour les postes
MiVoice 5300 Digital Phone, 6750, M7xx et analogique.
A savoir : La fonctionnalité est disponible pour les postes analogiques à partir de la version R6.1 mais reste
indisponible pour les terminaux ISDN et le Poste Operateur de type i2070.
A noter : en configuration multicentres la fonction « Virtual TDM » est ouverte avec la restriction suivante : le
site hébergeant l’abonnement Virtual TDM et le site hébergeant l’équipement TDM doivent être dans le même
centre. Cette restriction est levée si l’abonnement bénéficie de la fonction dual homing. Depuis la version R6.2,
il n’y a plus de restriction, les 2 sites peuvent être dans 2 centres différents.
16/51
Free Seating
Le Free Seating (ou login/logout) est la fonction permettant à un usager de se déplacer d’un poste vers un
autre, quel que soit son type, parmi ceux supportant la fonction (cf. chapitre 10 « Caractéristiques et
dimensionnements » du guide produit) et de retrouver son profil (droits, renvois, touches programmées, et
autres paramètres enregistrés dans le système).
Dans un multisite, pour faciliter le Free Seating entre terminaux numériques et IP, il est recommandé de
centraliser l’ensemble des abonnements sur un Call Manager et d’utiliser la fonction Virtual TDM.
En effet, la fonction Virtual TDM permet d’élargir la fonction de Free Seating aux postes numériques d’un
multisite. Il est possible de se déplacer et de retrouver ses services en se logeant sur un poste numérique
TDM, même si celui-ci est connecté sur un autre site du multisite.
Les postes analogiques, bien que centralisés avec le Virtual TDM, n’offre pas le login/logout manuel, mais
nécessitent l’intervention de l’administrateur.
Postes associés
La fonction d’association dans un multisite MiVoice 5000 nécessite que tous les postes concernés soient
rattachés au même système MiVoice 5000 : MiVoice 5000 Server ou Mitel 5000 Gateways. De base,
l’association d’un poste DECT IP rattaché à un MiVoice 5000 Server et un terminal TDM sur une gateway n’est
pas possible.
Grâce à la fonction Virtual TDM il est possible de centraliser le terminal TDM avec le DECT IP sur le même Call
Manager MiVoice 5000 ou Mitel 5000 Gateways et donc l’association est possible.
Dans le cas du Virtual TDM, l’association nécessite que la signalisation MOVACS soit établie entre les
différents iPbx concernés. Typiquement dans le cas de rupture de ce lien, le terminal TDM ne sera plus
joignable et aucune création/modification/suppression ne sera active sur cet équipement tant que la
signalisation ne sera pas établie.
Groupements
Avec la fonction Virtual TDM, il est possible dans un multisite de créer un groupement incluant des terminaux
numériques et analogiques répartis physiquement sur plusieurs passerelles différentes.
La tête de groupement et les abonnés doivent être définis sur le même site. Et les équipements physiques des
abonnés peuvent être connectés sur des sites distants.
Dual Homing
La fonction de secours Dual Homing permet au terminaux IP et Virtual TDM en cas de défaillance du réseau IP
ou du site principal sur lequel ils sont déclarés de se connecter à un site de backup du multisite et retrouver
toutes les caractéristiques de son abonnement.
En termes de bonne pratique, le site de backup doit être au plus proche du terminal IP secouru. Pour les
terminaux bénéficiant du Virtual TDM ce sera toujours le site auquel ils sont raccordés physiquement.
En mode association, avec Dual Homing, le secours ne peut se réaliser que sur une seule gateway, pour tous
les postes de l’association. Seuls les postes pouvant se connecter à la gateway de backup pourront retrouver le
service :
 Site principal = Call manager
 Site backup = une et une seule passerelle
17/51
17.2.3 MISE EN RÉSEAU IP
La mise en réseau via IP en mode ne nécessite pas de lien permanent dédié aux communications voix et
permet de mutualiser le réseau WAN/MAN et la bande passante avec d’autres applications que la téléphonie.
Comme décrit précédemment, la topologie du réseau multisite est de type maillé : chaque système MiVoice
5000 a connaissance de l’ensemble des éléments actifs du réseau. L’administrateur, pour chaque ajout d’un
nouveau système dans le multisite, doit configurer l’ensemble des adresses IP des autres systèmes dans celuici et programmer également ce nouveau lien dans tous les autres systèmes. Une architecture en mode multi
centre est alors préconisée au-delà de 15 systèmes actifs pour alléger le réseau.
Dans un réseau IP, le flux voix ne suit pas le chemin de signalisation mais il est direct entre les deux terminaux
en communication.
Le synoptique suivant représente une mise en réseau de 3 Mitel 5000 Gateways via IP et le transport voix sur
IP. Pour une communication entre deux terminaux IP, la voix est directe, elle emprunte l’infrastructure mise en
place par les routeurs, les switches.
Si dans une architecture Voix sur IP il y a des terminaux TDM, il est alors nécessaire de déployer sur les cartes
mères des Mitel 5000 Gateways les cartes filles EIP. Le chemin voix dans ce cas transite via les cartes EIP des
passerelles Mitel 5000 Gateways tel que représenté ci-dessous.
Les règles d’ingénierie pour le déploiement d’un multisite MOVACS IP en termes de trafic et bande passante
sont communes avec une mise en réseaux en mode Cluster. Ces règles sont décrites dans le chapitre
« Qualité de service ».
18/51
Ingénierie bande passante MOVACS
Le débit et les bursts de la signalisation MOVACS en réseau IP dépendent du nombre d’abonnés sur le réseau,
des facultés téléphoniques configurées (e.g. présence de groupe d’intercom multisites, accueils multisites) et
du comportement des utilisateurs (e.g. nombreuses interceptions intersites).
Si le transport des messages n'est pas assuré, de manière fiable, dans un délai compatible avec le temps réel
de la téléphonie, les traitements sur chaque site deviennent inhomogènes et les systèmes MiVoice 5000
peuvent alors avoir un comportement aléatoire et imprévisible.
En conséquence, Mitel recommande un débit « de sécurité » de 64 kb/s réservé aux messages de
signalisation. En effet, même si le débit utile peut être faible, ce débit de « sécurité » est impératif pour, d'une
part garantir le traitement en temps réel des messages (c’est à dire la vitesse de transfert), et d'autre part
garantir l'émission (et la réception !) des bursts instantanés.
Plus précisément, on peut prendre en compte les débits suivants pour la signalisation :
 80 Kbits/s : pour des réseaux de plus de 1000 abonnés,
 60 Kbits/s pour des réseaux comprenant entre 500 et 1000 abonnés,
 40 Kbits/s : pour des réseaux comprenant entre 100 et 500 abonnés,
 25 Kbits/s : pour des réseaux de moins de 100 abonnés.
Ces bandes passantes n’incluent pas les flux d’applicatifs comme MiVoice 5000 Manager pour faire de la mise
à jour logicielle ou des sauvegardes ou les flux des PC utilisateurs en tant qu’agent centre d’appels ou
superviseur centre d’appels. Pour dimensionner l’ensemble de la bande passante se reporter au chapitre
« Qualité de service ».
Bande passante Virtual TDM
La bande passante nécessaire pour la signalisation entre Call Manager et Gateway pour assurer la fonction
Virtual TDM est de 0.2kbit/sec par terminal analogique ou numérique plus une marge globale de 1.5kbits/sec.
19/51
17.2.4 INTERFONCTIONNEMENT DE VERSIONS HÉTÉROGÈNES
Interfonctionnement en multisite R8.0, R7.2, R7.1, R7.0 et R6.5:
Il est possible d’avoir des réseaux multisites (MOVACS) hétérogènes R8.0, R7.2, R7.1, R7.0 et R6.5, avec des
restrictions de services dans le réseau.
Il est possible de réaliser un interfonctionnement entre la version logicielle N et N-4. Dans ce cas certaines
fonctionnalités ne sont plus disponibles comme les nouvelles fonctions qui feraient appel à des services
multisites. L’interfonctionnement s’applique sur les fonctionnalités de la version de plus bas niveau dans le
multisite.
Par exemple, sur un site en version N inter-fonctionnant avec un site en version N-1, les fonctions de la version
N ne sont pas offertes sur les sites en version N-1. Certaines fonctions de la version N peuvent être offertes sur
les sites en version N.
Dans le cas d'un réseau hétérogène R8.0 avec une version inférieure, seules les fonctions de la version
inférieure sont toutes disponibles sur tous les sites. Certaines fonctions de la version R8.0 peuvent être
disponibles sur les sites de versions R8.0.
Cas particuliers infrastructures :
 MiVoice 5000 Manager doit être toujours dans la version associée au MiVoice 5000 de plus haute
version. Le MiVoice 5000 Manager en version R8.0 gère les sites à partir de R6.5.
 L’annuaire LDAP MiVoice 5000 doit toujours être sur le site de plus haut niveaux ou dans un MiVoice
5000 Manager. Lorsque l’annuaire LDAP MiVoice 5000 est stocké sur MiVoice 5000 Manager il peut y
avoir des réplications sur R7.2, R7.1, R7.0 et R6.5
 TMA : le TMA de MiVoice 5000 Manager peut gérer différentes versions sur les terminaux du multisite
selon la version du site sur lequel ils sont connectés.
 Calendriers : 250 calendriers depuis R6.5
 Étiquettes : la taille des étiquettes dans MiVoice 5000 Web Admin est compatible avec les versions
plus anciennes (pour les groupes d’interception, les société/services techniques). Cela concerne le
champ « groupe d’interception » et celui libellé « Compagnie / Département »
20/51
Cas particuliers fonctions téléphoniques :
 Squat : la fonction squat n’est pas disponible dans un multisite hétérogène (elle est cependant
disponible si l’abonnement et le terminal squattés sont déclarés sur des Mitel 5000 Gateways et/ou
MiVoice 5000 Servers de même version logicielle quel que soit le SP).
 Dual Homing : A partir de la version R6.5, le site de backup ne doit plus être obligatoirement dans la
même version que le site de déclaration.
 Free Seating : le Free Seating est disponible entre versions hétérogènes en prenant compte de
contraintes et restrictions dépendant de la version du site de déclaration de l’abonnement et de la
version du site sur lequel se logue l’utilisateur.
Cas particulier d’un terminal (abonnement déclaré sur un site d’une version N-1) qui utilise/invoque la
fonctionnalité « Free Seating » en se loguant sur un site d’une version supérieure (N, N+1,…) :
Le poste (abonnement) se loguant sur un site d’une version supérieure, le terminal charge (si besoin) le
firmware correspondant à la version, puis reboote pour sa prise en compte.
Cas particulier d’un terminal (abonnement déclaré sur un site d’une version N) qui utilise/invoque la
fonctionnalité « Free Seating » en se loguant sur un site d’une version inférieure (N-1,). Il est nécessaire
que le type de poste soit connu dans la version du site. Le poste ne peut alors utiliser que les fonctions
existantes dans cette version du site.
Restrictions :
Les postes 6873i requièrent d’être connectés sur un IPbX dont la version logicielle est au moins/au
minimum la version R6.2.
Les postes de la gamme 69xxi requièrent d’être connectés sur un IPbX dont la version logicielle est au
moins/au minimum la version R6.4.
21/51
17.3 ARCHITECTURE CLUSTER
17.3.1 PRINCIPE GÉNÉRAL
Topologie du mode MiVoice 5000 Cluster
La mise en réseau MiVoice 5000 Cluster, disponible à partir de la version R6.1, consiste en un serveur MiVoice
5000 Cluster Server maitre et un ensemble de nœuds esclaves : MiVoice 5000 Server, Mitel 5000 Compact,
Mitel 5000 Gateways et Mitel 500.
MiVoice 5000 Cluster Server regroupe l’ensemble des abonnements (IP, SIP, numérique, analogique) ainsi que
l’ensemble des licences avec une configuration centralisée et des fonctionnalités communes sur tout le Cluster.
La topologie du réseau MiVoice 5000 Cluster est en étoile, chaque nœud est supervisé par le Cluster Server.
Ainsi l’ajout d’un nœud dans l’architecture n’engendre pas une reconfiguration de l’ensemble du réseau comme
dans le mode multisite, seul un lien IP est créé entre le Cluster Server et le nœud et l’ensemble de la
configuration est poussé par le serveur maitre vers le nœud.
Les nœuds peuvent raccorder des abonnés analogiques ou numériques, gérés en central par le Cluster Server,
ainsi que des accès opérateur. Les abonnés TDM analogiques et numériques ne sont jamais déclarés dans un
nœud mais sont toujours centralisés dans le Cluster Server avec la fonction Virtual TDM.
22/51
Traitement d’appels
Les nœuds fournissent les ressources matérielles pour connecter divers équipements TDM (terminaux,
trunks...). L’usage des différentes ressources TDM (trunk TDM, conf à 3, etc.) est effectuée à base localisation
géographique du terminal (usage du serveur CAC et sous-réseaux IP).
Le traitement d’appels des trunks TDM est entièrement réalisé au niveau des nœuds. Le traitement d’appels
des trunks SIP est effectué là où le trunk est déclaré : ci-dessous dans le Cluster server.
Le traitement d’appels des abonnés TDM (analogiques et numériques) est réalisé dans le Cluster Server. Le
pilotage hardware du poste reste dans le nœud. Le Virtual TDM est toujours utilisé. Dans un Cluster, le
transport voix entre 2 postes traditionnels ou avec un accès opérateur traditionnel sur le même nœud est
commuté localement au sein de ce nœud.
Un appel entre un terminal TDM et un terminal IP ou des terminaux TDM et/ou accès opérateur sur des nœuds
distincts exploite des ressources VoIP sur les nœuds et le transport se fait en IP.
23/51
17.3.2 INGÉNIERIE D’UN MIVOICE 5000 CLUSTER
Prérequis
Les nœuds d’un MiVoice 5000 Cluster peuvent être dans le même LAN que MiVoice 5000 Cluster Server ou
distant via le WAN.
L’ensemble des éléments d’un Cluster doivent être dans la même langue et dans le même « time zone ».
Depuis la version MiVoice 50000 R6.5, il est maintenant possible de faire une mise à niveau à leur propre
rythme, c'est-à-dire pas à pas, afin d'apporter une plus grande flexibilité de mise à niveau aux clusters MiVoice
5000.
Dans les versions précédentes, la mise à niveau du cluster vers une nouvelle version concernait toujours la
mise à niveau du cluster dans son ensemble.
Exemple : Il est possible d'upgrader un Cluster Server en plusieurs étapes :
 Upgrade du MiVoice 5000 Manager en version R8.0
 Upgrade seul du MiVoice 5000 Cluster Server en version supérieure
 Upgrade progressif des nœuds par lot de R6.5 vers version supérieure
Les nœuds peuvent être mis à jour un par, donnant une flexibilité maximale sur le terrain.
Cette nouveauté permet de s’affranchir de contraintes existant depuis l’introduction du cluster, qui étaient :
 Tous les iPBX du cluster doivent avoir la même version (même IP (Initial Pack) ou même SP (Service
Pack))
 Lorsque la version du serveur de cluster et d'un nœud n'est pas la même, la connexion de nœud est
refusée par le serveur de cluster. Dans ce cas, le nœud est isolé en mode autonome.
Remarque :
Cette nouvelle fonctionnalité permettant la gestion de plusieurs versions dans un cluster est une solution
temporaire. Elle permet à l'administrateur de définir une période de mise à niveau du cluster et ne constitue pas
uniquement une solution pour mettre à niveau le Cluster Server afin d'accéder à de nouvelles fonctionnalités.
Restriction :
Pour migrer un meuble de type Compact Flash (type AX series), il est nécessaire d’utiliser la procédure de
migration avec changement de la Compact Flash quel que soit son type (2Go et 4Go).
Administration
Un serveur MiVoice 5000 Manager ainsi que le service SDN sont obligatoires dans une architecture Cluster.
Les différents services réseau DHCP, FTP, TFTP, NTP, etc. peuvent être centraux ou locaux.
L'accès à distance au Cluster Server ou à un nœud n'est possible que depuis MiVoice 5000 Manager. En
d'autres termes, l'accès PPP n'est plus disponible sur les nœuds du Cluster ; le modem HSCX n’est pas
disponible en mode Cluster.
24/51
Redondance
Dans une architecture Cluster il est possible de dupliquer le Cluster Server de manière local ou géographique
(LAN ou WAN). Cette duplication est identique au mode multisite et décrite dans le chapitre « MiVoice 5000
Server » du guide produit.
Lorsque le serveur MiVoice 5000 est configuré en tant que nœud, il ne peut être redondé (duplication MiVoice
5000 Server).
Il est possible d’exploiter les capacités double attachement des Mitel 5000 Gateways & des MiVoice 5000
Servers en tant que nœuds. De plus, lorsque le dialogue entre le nœud et MiVoice 5000 Cluster Server est
coupé, le nœud passe dans le mode autonome décrit plus bas.
Une configuration redondante est également possible pour le centre de gestion MiVoice 5000 Manager.
Plan de numérotation
L’implémentation du SDN (serveur de numérotation) est obligatoire dans un MiVoice 5000 Cluster.
Services Annuaires
Dans le mode Cluster la base annuaire LDAP est située dans MiVoice 5000 Manager et répliquée dans le
Cluster Server pour sécuriser le service annuaire et pour optimiser les requêtes temps réel vers la base.
Les nœuds intègrent également une base réduite utilisée dans le cadre du mode autonome (cf. mode
autonome).
Chiffrement TLS
Le mode MiVoice 5000 Cluster autorise le chiffrement TLS des liaisons de signalisation entre le Cluster Server
et les nœuds. Un certificat TLS doit être attribué à chaque nœud.
25/51
Dimensionnements principaux
Un MiVoice 5000 Cluster est composé d’un serveur maître et jusqu’à 230 nœuds.
Jusqu’à 20000 abonnés peuvent être déclarés dans un MiVoice 5000 Cluster Server.
Jusqu’à 30000 terminaux sont gérés par un Cluster.
Pour plus de détail sur les dimensionnements d’un Cluster se reporter au chapitre 10 « Caractéristiques et
dimensionnements » du guide produit.
Licences
Pour simplifier la gestion d'un MiVoice 5000 Cluster la clé de déverrouillage des fonctions est associée à
MiVoice 5000 Cluster Server. Les licences déverrouillées au niveau du Cluster Server donnent accès aux
différentes fonctions au niveau de chaque nœud. Aucune licence n’est nécessaire pour un nœud dans un
MiVoice 5000 Cluster (Mitel 5000 Gateways, Mitel 500 ou MiVoice 5000 Server).
Dans le cas de Trunk SIP sur un nœud ou de Media Server sur un nœud MiVoice 5000 Server, le Cluster
Server permet une affectation statique de ces licences sur chaque nœud concerné.
En mode autonome, toutes les fonctions sont déverrouillées sur le nœud pendant 30 jours.
17.3.3 MIVOICE 5000 CLUSTER
Depuis la version MiVoice 5000 R6.5, la nouvelle fonctionnalité « Cluster hétérogène » introduit une notion
d’interfonctionnement « intra-cluster »
Cet interfonctionnement entraine les limites suivantes :
 Les fonctionnalités offertes par la nouvelle version ne sont pas ouvertes tant qu’il existe des nœuds en
version inférieure.
 Exception : le dual homing est ouvert avec la version MiVoice 5000 R6.4.
Dans un Cluster « hétérogène », les nœuds et le cluster peuvent avoir des versions différentes.
L'interfonctionnement téléphonique doit être positionné sur le Cluster server via la RHM d’interfonctionnement.
De ce fait, l’interfonctionnement correspond soit à :
 La plus petite version du multisite dans le cas d'un cluster en multisite.
 La plus petite version des nœuds (=R6.4) dans le cas d’un cluster isolé.
26/51
17.3.4 SERVICES MIVOICE 5000 CLUSTER
Communications
Les usagers bénéficient de services de communications audio, vidéo et instant messaging suivant les capacités
des terminaux en composant un numéro téléphonique court ou long (traduction de n° automatique). Ils peuvent
émettre des appels vers l’extérieur de l’entreprise ou les recevoir sur des ressources opérateurs de différents
types (TDM ou IP) centralisés ou distribués ou des appels intersites type QSIG ou Trunk SIP privé. Un
mécanisme de type Least Cost Routing est paramétrable. Les communications internes peuvent être chiffrées.
Il s’agit d’un réseau de communication transparent pour les usagers déployé sur un Lan ou un Wan privé. Ces
usagers bénéficient des services du logiciel MiVoice 5000 et des applicatifs associés de la configuration.
Haute disponibilité - Maintien de communications
Tous les appels sont maintenus de la même manière qu’en mode multisite lorsque le Cluster Server redémarre
ou bascule vers le serveur duplex.
Le tableau ci-dessous détaille les types d’appels maintenus dans le cas de perte de signalisation entre un
Cluster Server et un terminal ou entre un Cluster Server et un nœud (mode autonome).
Si la liaison de signalisation entre le Cluster Server et un nœud tombe et ce malgré le double attachement alors
tous les appels IP qui impliquent une ressource TDM géré par ce nœud sont libérés sauf les appels trunk TDM
sur ce nœud.
En mode autonome, les seuls appels TDM-TDM maintenus sont les appels entre un trunk TDM (sur le nœud)
et un terminal TDM hors Cluster.
Si une défaillance de la liaison IP empêche l'échange de paquets RTP, les appels sont naturellement coupés.
Si un nœud devient défaillant, les appels qui impliquent une ressource TDM (musiques, annonces,
conférences, trunk T0/T2) ou un terminal TDM géré par ce nœud sont libérés.
Centralisation des abonnés TDM & IP
Dans une architecture Cluster, tous les abonnés, sont déclarés et gérés par MiVoice 5000 Cluster Server.
Console Opératrice
La console opérateur disponible en mode Cluster est l’application Mitel 5000 Web Attendant.
La console opérateur numérique PO Mitel 6757 Digital Phone et l’application i2070 ne sont pas compatibles
avec une architecture Cluster. Il est possible pour répondre à des attentes particulières de déployer ce type de
PO i2070 en déployant une passerelle Mitel 5000 Gateways supplémentaire configurée en multisite avec le
Cluster Server (cf. Architecture XXL).
27/51
Free Seating
La fonction de Free Seating est disponible dans une architecture Cluster. Seuls les abonnements ayant le droit
peuvent se déloger d’un terminal puis se reloger.
La fonction Free Seating n’est pas compatible avec les terminaux analogiques et DECT TDM.
Postes associés
Le traitement d’appels étant centralisé sur le Cluster Server pour tous les abonnés, toutes les associations
entre postes IP, DECT et TDM, sont possibles quel que soit le nœud auquel est connecté le poste TDM.
Dual Homing
Le nœud de backup d'un abonnement en mode Cluster est défini de manière statique comme dans le mode
multisite.
Pour les postes IP, le nœud de backup peut être n’importe quel nœud du Cluster (de préférence le plus proche
géographiquement du poste IP).
Pour un terminal TDM le nœud de backup correspond au nœud auquel il est connecté physiquement.
Messagerie vocale et unifiée
Le service de messagerie vocale et unifiée est rendu directement par le Media Server de MiVoice 5000 Cluster
Server.
Cette messagerie offre le service à tous les abonnés d’un Cluster : IP, numérique DECT IP, DECT TDM et
analogique.
Le service de messagerie vocale intégré (BVI) dans les Mitel 5000 Gateways n’est jamais activé pour un nœud
du Cluster.
Une messagerie UCP peut également être utilisée dans une architecture Cluster celle-ci est connecté
directement au Cluster Server.
Serveur vocal interactif
Le service SVI peut être activé dans le Media Server de MiVoice 5000 Cluster Server ou rendu par l’application
Mitel 5000 Contact Center SVI ou par une application tierce.
Il est également possible de paramétrer les ressources SVI intégrés dans les nœuds Mitel 5000 Gateways.
L’intérêt réside dans l’optimisation de bande passante dans le cas d’un flux d’appel extérieur local au nœud qui
transiterait finalement que dans la gateway locale.
Couplage Téléphonie Informatique : Présence, Collaboration…
Le service de couplage téléphonie informatique et de collaboration dans un MiVoice 5000 Cluster est le même
que dans une architecture multisite. L’application CTI (Mitel 5000 Contact Center, MiCollab,…) doit être
directement connectée au Cluster Server compte tenu que tous les abonnements sont sur ce serveur.
Interfaces S0/S2
En mode MiVoice 5000 Cluster, les nœuds ne peuvent pas gérer des terminaux RNIS sur interface S0 ou S2.
Seules les bornes DECT TDM peuvent être raccordées à un nœud du Cluster sur ces interfaces.
Si des terminaux RNIS doivent être maintenus dans une architecture ToIP, il est toujours possible d’utiliser un
Mitel 5000 Gateways raccordé en mode multisite avec un MiVoice 5000 Cluster. Pour plus d’information se
reporter au paragraphe « Architecture XXL ».
28/51
17.3.5 MODE AUTONOME
Lorsque le dialogue entre le nœud et MiVoice 5000 Cluster Server est coupé, le nœud commute
automatiquement dans un mode autonome sans redémarrer.
Dans ce mode :
 Les abonnements de backup sont activés (Dual Homing),
 Le nœud essaye régulièrement de rétablir la connexion avec le Cluster Server.
Lorsque la connexion avec le Cluster Server est rétablie, le nœud revient automatiquement à son mode normal
et les abonnements de backup ne sont plus actifs.
Remarque : comme dans un multisite, les terminaux DECT, le portfolio Micollab ne sont pas compatibles Dual
Homing. Ils ne sont donc plus opérationnels en mode autonome.
Services Annuaires
Depuis la version R6.1 la résilience annuaire a été améliorée avec la possibilité d’un réplica réduit de la base
annuaire disponible en backup dans les nœuds. Ce réplica est limité aux fiches des abonnés secourus et il est
inférieur à 3000 fiches annuaires lorsque le nœud est un Mitel 5000 Gateway ou Mitel 500. Il est activé
automatiquement lorsque le nœud est en mode autonome (il ne peut plus atteindre la base de données
principale). Il offre ainsi plusieurs fonctionnalités annuaires telles : appel par le nom des abonnés locaux,
routage SDN, numéros interdits...
Ce mécanisme est intégré de base sans licence.
29/51
Débordement
Compte tenu de la topologie de signalisation (lien uniquement vers MiVoice 5000 Cluster server), un nœud en
mode autonome ne peut plus joindre les autres nœuds jusqu’à rétablissement du lien avec le Cluster Server
par une numérotation courte ou appel par le nom. Afin de proposer le service de numérotation courte ou
d’appel par le nom inter nœud en mode Dual Homing, le routage est réalisable via une programmation de
débordements réseau. Ces débordements sont soit les débordements RTC (traduction n° interne, n° SDA) soit
les débordements en mode trunk SIP (ajout préfixe).
Les appels sortants transitent via les trunks locaux déclarés dans la passerelle. Pour les appels entrants, s’ils
sont centralisés, deux cas sont possibles :
 Soit un routage de débordement peut être réalisé par le Cluster Server avec la fonction abonné vital.
Dans ce cas il est nécessaire d’avoir un second numéro SDA qui pointe sur l’accès opérateur local à la
passerelle.
 Soit le Cluster Server n’est plus visible par l’opérateur SIP dans ce cas il peut être souscrit une offre de
débordement opérateur sur les accès trunk du nœud en mode autonome.
Ci-dessous, l’appel interne par numéro court est transformé en numéros SDA de secours par le Cluster Server
grâce à la fonction Abonné vital.
Le numéro SDA de secours peut également être le numéro GSM de l’abonné. Il est également possible
d’utiliser à la place de la fonction abonné vitale la fonction poste associé avec un numéro externe (disponible
depuis la R6.1).
30/51
Ci-dessous, l’appel interne est réalisé par le numéro long (SDA), l’usager n’a pas connaissance des SDA de
secours c’est le Cluster Server qui fait la transformation par abonné vital. L’appel entrant utilise également, le
même chemin.
Dans le cas ci-dessous l’opérateur ne voit plus le Cluster Server, le routage est réalisé via une offre opérateur.
L’accueil de chacun des sites géographiques dispose également de ces mêmes fonctions de débordement. Il
est donc possible pour des abonnés n’ayant pas de numéro SDA de router les appels en débordement vers
leur accueil. L’accueil peut ensuite transférer les appels vers les destinataires par la numérotation interne.
31/51
17.4 ARCHITECTURE XXL
17.4.1 PRINCIPE GÉNÉRAL
Topologie d’une Architecture XXL
Un MiVoice 5000 Cluster est vu comme un site dans la logique MOVACS, il peut donc faire partie d'un réseau
multisite. On parle alors d’architecture XXL.
Une architecture XXL présente la même topologie de mise en réseau qu’un multisite, avec la particularité
d’inclure des MiVoice 5000 Clusters en plus des MiVoice 5000 Servers/Mitel 5000 Compact ou des passerelles
Mitel 5000 Gateways et Mitel 500 dans un même réseau MOVACS.
Pour un MiVoice 5000 Cluster, les liens de signalisation intersites MOVACS sont établis à partir de MiVoice
5000 Cluster Server.
Un MiVoice 5000 Cluster ne peut pas avoir de liaisons TDM multisites (signalisation et SVL) vers d'autres sites,
tous les liens sont IP avec le Cluster Server.
Tous les nœuds d’un Cluster partagent le même numéro de « site MOVACS » que le Cluster Server.
Prérequis XXL
Une architecture Cluster impose la présence d’un MiVoice 5000 Manager et la mise en place du SDN, ces
prérequis sont élargies à toute l’architecture XXL. Il ne peut y avoir qu’un seul MiVoice 5000 Manager dans une
architecture XXL.
Versions hétérogènes
Une architecture XXL présente les mêmes caractéristiques qu’une architecture multisite et en particulier, elle
supporte un interfonctionnement de version hétérogène tel R6.1, R6.2, R6.3, R6.4 ou R6.5. Comme décrit dans
le schéma ci-dessus un réplica de la base annuaire complète est nécessaire dans les serveurs MiVoice 5000
Cluster.
32/51
Centralisation des abonnés
Comme dans une configuration multisite traditionnel, il est possible de centraliser les abonnements sur un
MiVoice 5000 Cluster Server du multisite. Par exemple sur le schéma ci-dessus, un abonné sur un poste
analogique du site 3 peut être centralisé avec la fonction Virtual TDM sur le Cluster Server du site 1.
Cette centralisation permet de généraliser le Free Seating multisite (cf. ci-dessous).
Remarque : Les abonnés RNIS S0/S2 ne peuvent être déclarés dans MiVoice 5000 Cluster, ils ne seront donc
pas centralisés.
Dimensionnements principaux
Une architecture XXL permet d’atteindre des dimensionnements très grand, avec un maximum de 300 000
abonnés téléphonique et jusqu’à 2000 équipements actifs : MiVoice 5000 Cluster Server, MiVoice 5000 Server,
Mitel 5000 Gateways et Mitel 500.
Pour plus de détails sur les dimensionnements se reporter au chapitre 10 « Caractéristiques et
dimensionnements » du guide produit.
33/51
17.4.2 SERVICES XXL
Free Seating
Dans une configuration XXL, le Free Seating pour les terminaux IP peut être utilisé sans aucune restriction liée
aux sites ou aux nœuds tant que le terminal utilisé est compatible avec le Free Seating, peu importe où cet
abonnement est déclaré lorsque :
 L'abonnement est déclaré dans un MiVoice 5000 Cluster Server, le Free Seating n’est pas limité au
sein du Cluster mais élargi sur tous les terminaux IP du multisite.
 L'abonnement est déclaré sur un autre site dans le multisite le Free Seating est permis au sein des
terminaux IP de MiVoice 5000 Cluster.
En ce qui concerne les terminaux TDM :
 Les terminaux TDM du Cluster, quel que soit le nœud auquel ils sont raccordés, sont capables
d’accueillir uniquement des abonnés du même Cluster,
 Les terminaux TDM des autres sites peuvent accueillir des abonnés du Cluster grâce à la fonction
Virtual TDM.
Dual Homing
Dans une architecture XXL, le site/nœud de backup d’un abonné du Cluster A pourra être n’importe quel site du
multisite XXL ou nœud du Cluster A.
Un nœud d’un Cluster A ne pourra offrir le backup que pour les abonnés du Cluster A.
Le schéma ci-dessous illustre ce cas, l’abonné C du site 1 ne pourra pas être secouru par le nœud 2 du Cluster
« site 2 ».
Postes associés
Dans le schéma précédent, l’abonné A du Cluster « site 4 » bénéficiant de la fonction d’association pourra
associer jusqu’à 4 terminaux parmi les suivants :
 Tout terminal IP ou SIP du multisite XXL
 Tout terminal TDM du Cluster « site 4 »
 Tout terminal TDM du multisite XXL rattaché en Virtual TDM au Cluster Server du site 4 (sauf les
terminaux TDM rattachés physiquement à un nœud d’un autre Cluster tel le site 2)
 Tout terminal DECT SIP d’une OMM rattachée au Cluster Server du site 4
 Un terminal DECT TDM affecté à son abonnement de manière statique dans le Cluster Server
34/51
Interfaces S0/S2 et Console opérateur
L’architecture XXL complète le mode Cluster et permet de répondre à des besoins fonctionnels particuliers tel
que l’usage de terminaux RNIS ou de console opérateur numérique PO Mitel 6757 Digital Phone (et application
i2070).
En effet, il n’est pas possible de connecter un bus S0 ou un PO Mitel 6757 Digital Phone sur un nœud MiVoice
5000 Cluster. Néanmoins, il est possible de déployer un châssis Mitel 5000 Gateway en multisite XXL pour
supporter ces terminaux dans le réseau ainsi constitué.
Ci-dessous un exemple d’architecture :
35/51
17.4.3 MODE SURVIVABILITE – BACKUP DU CLUSTER SERVER
La survivabilité avec N nœuds (backup du Cluster Server) permet d’améliorer la sécurité dans la gestion des
très grands réseaux MiVoice 5000 Cluster (ou réseau XXL). (Disponible depuis R6.1 SP1)
Dans le cas d’une rupture de communication avec le Cluster Server (accès WAN), des nœuds de survie
peuvent être définis (dans une communauté) pour permettre le backup du Cluster Server dans cette zone.
L’objectif est de pouvoir assurer un niveau de service entre ces nœuds en mode survivabilité et centraliser des
ressources comme des accès opérateurs traditionnels ou SIP Trunk.
La fonction de survivabilité permet donc à tous les nœuds de la communauté de continuer à communiquer
entre eux, tout en assurant un niveau de service : chaque nœud établit une connexion avec le nœud de survie
de la communauté.
Une base de données principale réduite est hébergée dans le nœud de survie, elle contient tous les
enregistrements de la communauté et une base de données de sauvegarde réduite est hébergée dans chaque
nœud, elle contient tous les enregistrements locaux.
Pour tous les détails sur la base Annuaire, consulter le chapitre « Annuaire MiVoice 5000 » du Guide Produit.
36/51
Fonctionnement du mode de survivabilité :
Ce mécanisme de défense est activé dès que le Cluster Server n’est plus joignable.
Sur perte de lien avec le MiVoice 5000 Cluster Server, le Nœud de survie bascule à chaud (sans redémarrage)
en mode autonome :
 Les abonnements de backup sont alors activés sur le nœud de survie,
 Le nœud essaye régulièrement de rétablir la connexion avec le MiVoice 5000 Cluster Server.
La connexion des nœuds vers le nœud de survie est automatique dès détection de rupture, tout comme la
reconnexion vers le Cluster Server est automatique pour tous les nœuds
Un nœud peut être autonome sur une durée de 30 jours (licence bloquée au bout de 30 jours).
L’ensemble des nœuds agissant comme un Cluster est construit dynamiquement autour du nœud de survie :
 Le lien de signalisation de chaque nœud est automatiquement configuré avec le nœud de survie grâce
à l'automate.
 Les abonnements Dual Homing sont actifs dans chaque nœud (lien nœudCluster Server non
installé).
 La signalisation entre les différents nœuds est la signalisation MOVACS.
La configuration du mode de survivabilité nécessite la gestion de la communauté et est réalisée via MiVoice
5000 Manager
Prérequis :
 Un nœud de survie est un MiVoice 5000 Server, un Mitel 5000 Compact, ou un Mitel 5000 XD, XL, XS.
 Pour activer cette fonction, tous les nœuds doivent être dans le même LAN
Le niveau de service assuré entre les nœuds permet :
 D’avoir un accès opérateur centralisé (opérateurs traditionnels ou SIP Trunk) dans cette zone
 De pouvoir réaliser du routage d’appels locaux et d’appels trunk.
 D’avoir accès aux services d’appel par le nom et d’affichage du nom.
Restriction : La fonction CAC n’est pas disponible lorsque le nœud de survivabilité est activé.
37/51
Configuration :
La configuration ne concerne que l'identification du nœud de survie (par la communauté) et est gérée par
MiVoice 5000 Manager. MiVoice 5000 Web Admin optimise dynamiquement la configuration de base de
données réduite.
Chaque communauté doit correspondre à une zone géographique « locale » : les nœuds et le nœud de survie
doivent être connectés au même LAN (pas de WAN entre nœuds).
Exemple de configuration du nœud de survie via MiVoice 5000 Manager :
38/51
Exemple de nœud de survie au niveau de MiVoice 5000 Web Admin :
Exemple de nœud simple avec l’adresse du nœud de survie qui lui est associé, dans MiVoice 5000 Web
Admin :
39/51
Exemple de configuration de la base Annuaire LDAP réduite :
Dimensionnement :
Il ne peut y avoir qu’un nœud de survivabilité par communauté.
Si le nœud de survivabilité est un Mitel 5000 XS, XL ou XD :
 Un contrôle est réalisé par MiVoice 5000 Manager sur le nombre de nœuds dans la communauté (et
donc engagés dans la fonction de nœud de survivabilité)
 Nombre maximum de nœuds dans la communauté = 5
 Nombre maximum d’abonnements = 3000
Si le nœud de survivabilité est un MiVoice 5000 server (ou Mitel 5000 Compact) :
 Nombre maximum de nœuds dans la communauté = 10
 Nombre maximum d’abonnements = 1000
40/51
17.5 SERVICES RÉSEAU COMMUNS
Ce chapitre regroupe l’ingénierie de certains services qui sont indépendant du mode choisi : Multisite ou
MiVoice 5000 Cluster.
17.5.1 SERVICES VOCAUX
Ce paragraphe traite de l’ingénierie des services vocaux suivant :
 Guides vocaux – annonces
 MoH – musiques d’attente et pré-décroché
 Conférence à 3
Ces services peuvent être rendus soit par le Media Server d’un MiVoice 5000 Server ou Cluster Server soit par
les ressources média des Mitel 5000 Gateways. L’ingénierie de ces éléments est à prendre en compte dans le
dimensionnement des ressources media (calcul du nombre canaux sur Media Server/carte EIP sur Mitel 5000
Gateways), et dans le calcul des bandes passantes nécessaires sur le réseau.
Les passerelles Mitel 5000 Gateways disposent des capacités de pont de conférence à 3 pour répondre aux
sollicitations de 1000 abonnés avec un trafic d’usage moyen.
Le Media Server MiVoice 5000 dispose d’une capacité de 1000 canaux pour l’ensemble des services.
Ci-dessous, figurent quelques conseils sur le nombre de voix nécessaires en fonction des services retenus.
Guides vocaux et annonces
Pour les terminaux TDM, la passerelle Mitel 5000 Gateway à laquelle ils sont respectivement raccordés jouera
toujours les guides vocaux et annonces.
Pour les autre terminaux, les guides vocaux et annonces sont joués pour l’ensemble des usagers par le Media
Server dans une architecture centralisée multisite ou Cluster.
Si le Media Server n’est pas activé sur MiVoice 5000 Server hébergeant les abonnés, dans ce cas les guides
vocaux et annonces sont joués par les Mitel 5000 Gateways. Il faut donc prévoir des cartes EIP.
Pour les terminaux IP, deux cas sont possibles pour optimiser la gestion de la bande passante :
 Soit un ensemble de passerelles jusqu’à 8, peuvent être dédiées pour ce service
 Soit, pour optimiser la gestion de la bande passante, les guides vocaux sont joués par la passerelle la
plus proche à base localisation géographique.
41/51
Musiques d’attente et pré-décroché
Les musiques d’attente sont dédiées aux appels externes uniquement. Ces musiques sont toujours jouées par
le système MiVoice 5000 ou Mitel 5000 Gateways qui est raccordé à l’opérateur (RNIS ou Trunk SIP).
Un MiVoice 5000 Server raccordé à l’opérateur en trunks SIP et sur lequel le Media Server n’est pas activé, va
rechercher les ressources média sur des passerelles du multisite/Cluster en fonction de la soc/ser du numéro
demandé.
Ci-dessous par exemple, les usagers sont répartis par société service en fonction de leur site géographique.
Les musiques d’attentes et de pré-décroché sont également dédiées à base soc/ser. Les appels à destination
des usagers de Marseille (soc/ser 2) seront mis en attente sur le nœud n°2 de Marseille qui contient les
musiques dédiées à la soc/ser 2.
42/51
Conférences à 3
Concernant les conférences à 3 participants, différents cas sont possibles :
 Si la conférence est initiée par un terminal SIP Mitel 6700/6800 SIP Phone ou BluStar, les ressources
propres au terminal sont utilisées, pas de canaux média nécessaires.
 Si la conférence est initiée par un terminal MiVoice 5300 IP Phone ou Digital Phone, les ressources du
Media Server ou Mitel 5000 Gateways seront utilisées. Ci-dessous, différents scénarii sont décrits selon
le type de terminal initiateur, l’activation ou pas du Media Server et les optimisations possibles.
Dans le cas où le Media Server MiVoice 5000 est activé, ci-dessous les différents scénarii possibles :
43/51
A partir de la version R6.1, une amélioration d’architecture similaire à l’amélioration portant sur les ressources
Media Server dans un multisite ou MiVoice 5000 Cluster permet d’optimiser l’usage de la bande passante WAN
pour les ressources de conférence à 3 :
 Les ressources de conférence sur gateway sont toujours préférées quand au moins 2 terminaux
traditionnels sont connectés sur le même châssis Mitel 5000 Gateways.
 Si le Media Server de MiVoice 5000 Server ou MiVoice 5000 Cluster Server est désactivé, on exploite
alors les ressources des Mitel 5000 Gateways en fonction de la localisation du terminal IP maitre de
conférences ou des terminaux traditionnels. La ressource de conférence exploitée est celle qui partage
la même localisation géographique (même sous-réseau IP)
Ci-dessous, le cas où au moins deux postes TDM sont raccordés sur la même passerelle, les ressources de
cette passerelle sont alors utilisées.
Ci-dessous, sont exposés les scénarii lorsque le Media Server MiVoice 5000 est désactivé, afin d’utiliser
uniquement les ressources des passerelles Mitel 5000 Gateways pour les conférences à 3.
Un ensemble de passerelles jusqu’à 8 peuvent être affectées à ce service.
44/51
Pour optimiser la bande passante, si un des participants est un terminal TDM, les ressources de la passerelle à
laquelle il est rattaché sont utilisées.
S’il n’y a pas de participant TDM, une autre optimisation permet d’utiliser la passerelle la plus proche du
terminal maitre de conférences. Cette optimisation est basée sur la localisation géographique.
45/51
17.5.2 GESTION DES APPELS D’URGENCE
Les numéros d'appel d'urgence sont des numéros de téléphone permettant de joindre les secours publics
24H/24 et 7 jours/7. Ce sont en général des numéros courts et gratuits.
En France, les principaux numéros spéciaux urgents sont les suivants :
 112 : numéro d’urgence européen
 115 : numéro d’urgence sociale
 119 : numéro pour l’enfance maltraitée
 15 : SAMU
 17 : police/ gendarmerie
 18 : pompiers
Lors d’un appel d’urgence, les services d’urgence doivent pouvoir localiser précisément l’appelant même dans
le cas d’un abonné en déplacement sur un autre site de l’entreprise (DECT ou poste en free-seating) car
l’abonné garde son numéro tout en pouvant changer de site géographique.
Dans ce cadre, le logiciel MiVoice 5000 gère l’ID du terminal en fonction de sa localisation géographique (et
non en fonction de son site de déclaration). Il peut donc fournir aux services d’urgence un numéro d’appelant
dynamique correspondant au lieu géographique où se trouve l’appelant. Le rappel de l’appelant par les
services d’urgence est ainsi possible.
Cette fonction est compatible avec le free-seating et avec le roaming DECT traditionnel ou IP.
Avec la solution Micollab sur smartphone, les appels d’urgence européens sont directement émis par
l’application GSM en appel direct quel que soit la méthode d’appel choisi par l’utilisateur (Wi-Fi, call-through ou
call-back).
Les paragraphes suivants détaillent la gestion des appels d’urgence par le logiciel MiVoice 5000 quelle que soit
l’architecture multisite ou Cluster pour les trois configurations suivantes :
 Accès trunk SIP centralisés,
 Accès opérateur TDM centralisé,
 Accès opérateur TDM décentralisés.
46/51
17.5.2.1 ACCÈS TRUNK SIP CENTRALISÉS
Dans ce cas, il y a un accès opérateur Trunk SIP centralisé pour l’ensemble des abonnés.
Configuration :
Le but de la configuration est que l’opérateur SIP puisse router un appel d’urgence en fonction de la localisation
de l’appelant afin que le service d’urgence contacté soit celui du site concerné.
Le serveur CAC MiVoice 5000 dispose d’une fonction supplémentaire permettant d’identifier la localisation d’un
appel d’urgence. Cette localisation est basée sur le découpage CAC en sous-réseaux IP.
Ce découpage doit permettre d’associer à chaque site/lieu géographique un sous-réseau spécifique.
Le rôle de l’opérateur est de fournir pour chaque lieu – correspondant à un sous réseaux – un numéro NDI
(Numéro de Désignation d'Installation).
Ces NDI représentent l’information que l’opérateur attend afin de pouvoir router l’appel vers le service
d’urgence le plus proche de l’appelant.
Ci-dessous un exemple de correspondance entre les sous-réseaux et les NDI de différents sites :
Site
NDI attribué
Paris (sous-réseau 1)
01 40 00 20 00
Lyon (sous-réseau 2)
04 40 00 20 00
Marseille (sous-réseau 3)
04 40 00 30 00
47/51
Réalisation du routage de l’appel d’urgence
Lorsqu’un poste de Lyon compose le 18, le logiciel MiVoice 5000 identifie que c’est un numéro d’urgence (18
reconnu dans une liste de numéros spéciaux).
Le serveur CAC est ensuite sollicité pour identifier le sous réseau de l’appelant et attribuer le NDI
correspondant.
Suivant la configuration ci-dessus, le logiciel MiVoice 5000 transmet vers l’opérateur les informations
suivantes :
 Numéro appelé : 018 (le zéro étant l’index de sortie)
 Numéro d’appelant : 04 40 00 20 00 correspondant au NDI de site de Lyon.
L’opérateur est alors capable de router l’appel vers le bon service d’urgence, le plus proche du site de Lyon en
fonction du NDI. Cette configuration est ainsi indépendante du site d’implantation du Call Manager gestionnaire
du terminal.
Le logiciel MiVoice 5000 enregistre dans une table l’abonné ayant contacté le service d’urgence et permet ainsi
un callback. Par exemple si le service d’urgence rappelle ce numéro NDI, le logiciel MiVoice 5000 est capable
de router l’appel vers le dernier abonné ayant appelé ce numéro d’urgence : l’appelant est donc joignable en
retour.
Remarque : dans ce cas, les abonnés ayant le droit d’appels externes peuvent composer directement les
numéros d’urgence avec le 0 devant (018 directement). Ceci n’est pas possible dans le cas ci-après.
48/51
17.5.2.2 ACCÈS OPÉRATEUR TDM CENTRALISÉS
Dans ce cas, il y a un accès opérateur centralisé traditionnel sur un des sites pour l’ensemble du réseau
téléphonique.
La problématique de l’accès opérateur TDM est qu’il ne fournit aucune intelligence permettant de router les
appels d’urgence en fonction d’informations transmises par le Call Manager. Le lien TDM est rattaché au
central du réseau opérateur le plus proche, les services d’urgence sont automatiquement liés à la position
géographique de ce central.
Configuration :
L’accès TDM étant partagé par plusieurs sites géographiques, cela n’a donc pas de sens d’appeler
systématiquement les secours les plus proches du central opérateur concerné. La configuration est différente
de celle du cas précédent (accès opérateur SIP Trunk) car l’opérateur ne prend pas en compte le numéro de
l’appelant pour faire le routage du numéro d’urgence sur un lien TDM.
Dans cette configuration, il faut également utiliser le serveur CAC et associer à chaque site un sous-réseau
spécifique. Pour chacune de ces localisations, il faut faire le travail de l’opérateur c’est-à-dire transformer un
numéro d’urgence (17,18, ...) en un numéro SDA (selon le Plan National Opérateur) du service correspondant
et de la localité (Pompiers de Paris, Pompiers de Marseille, …).
Exemple de correspondance pour le numéro spécial 18 entre les sous-réseaux, et les numéros SDA.
Site
Numéro spécial
Numéro SDA des Pompiers les plus proches
Paris (sous-réseau 1)
18
01 xx xx xx xx
Lille (sous-réseau 2)
18
03 xx xx xx xx
Marseille (sous-réseau 3)
18
04 xx xx xx xx
Lyon (sous-réseau 4)
18
04 xx xx xx xx
49/51
Cette configuration présente certaine contrainte du au faite que l’accès TDM n’offre pas d’intelligence pour le
routage de ces numéros :

L’obligation de maintenir à jour la table de correspondance (ci-dessus)

Limitée à 20 sous-réseaux.
Réalisation du routage de l’appel d’urgence
Lorsqu’un poste de Lyon compose le 18, le logiciel MiVoice 5000 identifie que c’est un numéro d’urgence (18
reconnu dans une liste de numéros spéciaux) et réalise la transformation du numéro spécial en numéro SDA
en fonction du sous réseau.
Suivant le tableau ci-dessus, le logiciel MiVoice 5000 transmet vers l’opérateur les informations suivantes :
 Numéro appelé : 04 xx xx xx xx (correspondant à la SDA des pompier de Lyon)
 Numéro d’appelant : SDA de l’appelant ou NDI.
L’opérateur effectue un routage traditionnel en fonction de la SDA appelé.
Remarque : cette configuration ne permet pas à l’usager de composé le 018.
17.5.2.3 ACCÈS OPÉRATEUR TDM DÉCENTRALISÉS
Dans ce cas, chaque site possède des sorties réseaux opérateurs traditionnels TDM.
Configuration :
Dans cette configuration, la complexité ne réside pas dans la traduction de numéro mais dans l’exploitation du
routage en fonction de la localisation de l’appelant. Cette localisation géographique de l’appelant permet alors
d’exploiter la bonne ressource opérateur : la plus proche géographiquement de cet usager. Le routage des
numéros d’urgence sera donc géré par l’opérateur en fonction de la sortie opérateur du réseau du client. La
configuration à mettre en place est donc plus aisée que le cas précédent.
Il faut associer à chaque lieu un sous-réseau spécifique, puis attribuer à chaque sous-réseau un numéro de
nœuds/site qui dispose d’un accès opérateur.
Exemple de table de correspondance entre les numéros de grappe/site et les différents sous-réseaux :
Site
Numéro nœud/site
Paris (sous-réseau 1)
1
Lille (sous-réseau 2)
2
Lyon (sous-réseau 3)
3
Marseille (sous-réseau 4)
4
50/51
Réalisation du routage de l’appel d’urgence
Pour tous les appels sortants et spécifiquement pour les appels d’urgences le logiciel MiVoice 5000 permet de
réaliser un routage à base numéro appelé.
Les numéros d’urgence sont configurés pour être routés au plus proche de l’abonné. Lorsqu’un poste de Lyon
compose le 18, le logiciel MiVoice 5000 identifie le sous réseau correspondant et route l’appel via la passerelle
de Lyon correspondant à l’index 3 (ci-dessus).
Dans cette configuration, le logiciel MiVoice 5000 transmet vers l’opérateur les informations suivantes :
 Numéro appelé : 018
 Numéro d’appelant : SDA de l’appelant ou NDI.
L’appel est ensuite routé par l’opérateur grâce à la localisation du central opérateur.
17.5.2.4 PARTICULARITÉS
Localisation en fonction du type poste
La localisation des abonnés est basée sur les informations suivantes :
 Adresse IP du poste (si poste IP)
 Adresse IP de la passerelle intelligente sur laquelle est rattaché le poste (si poste TDM)
 Adresse IP de la borne sur laquelle est rattaché le poste (si borne DECT SIP)
Dual Homing
Dans le cas du Dual Homing le routage est similaire à une configuration décentralisée mais sans l’usage du
serveur CAC. La passerelle qui route l’appel correspond à la passerelle à laquelle devient rattaché l’abonné.
Le logiciel MiVoice 5000 transmet vers l’opérateur les informations suivantes :
 Numéro appelé : 018
 Numéro d’appelant : SDA de l’appelant ou NDI.
Poste appelant: cas spéciaux
 Appel depuis un poste non logué

L’appel est autorisé et le numéro de localisation sera transmis
Pas de callback possible sur le poste : Callback sur le poste d’accueil
 Appel depuis un poste verrouillé

Numéros spéciaux seulement : 18,17,…. (018, 017,… non autorisé)

Callback possible : utilise le numéro de l’abonnement verrouillé
 Appel depuis un poste multi-usagers

Numéros spéciaux seulement : 18,17,…. (018, 017,… non autorisé)

Callback possible : utilise le numéro de l’abonnement multi-usagers
51/51