Avertissement
Bien que des efforts aient été faits pour vérifier l'exhaustivité et l'exactitude des informations contenues
dans cette documentation, ce document est fourni « tel quel ». Pour obtenir des informations plus
précises sur l'intercompatibilité, les limites du produit, la politique logicielle et la liste des fonction,
veuillez vous référer aux documents précis publiés sur le site web Business Partner : https://
myportal.al-enterprise.com.
Dans l'intérêt du développement continu des produits, ALE International se réserve le droit d'apporter
des améliorations à ce document et aux produits qu'il décrit, à tout moment et sans préavis ni
obligation.
Le marquage CE indique que ce produit est conforme aux Directives du Conseil ssuivantes :
• 2014/53/EU pour équipement radio
• 2014/35/EU et 2014/30/EU pour les équipements autres que radio (y compris les équipements de
terminaux de télécommunication câblés)
• 2014/34/EU pour équipement ATEX
• 2011/65/UE (RoHS)
• 2012/19/EU (WEEE)
Sommaire
Système OXE : Manuel
d'installation
Chapitre 1
Documents de référence
Chapitre 2
À propos du présent document
Chapitre 3
Critères courants en matière de sécurité - Guide de déploiement
3.1 Introduction.....................................................................................................................................15
3.1.1 Présentation du chapitre..................................................................................................................15
3.1.2 Conventions typographiques.........................................................................................................16
3.1.3 Glossaire................................................................................................................................................. 16
3.2 Contexte général client........................................................................................................ 17
3.2.1 Infrastructure et politiques de sécurité déjà mises en place par le client ...............17
3.2.2 Attaques et menaces........................................................................................................................ 21
3.2.3 Solution de communication déployée....................................................................................... 23
3.3 Installation sécurisée de la solution de communication.................... 24
3.3.1 Installation, configuration et mise en route.............................................................................24
3.3.2 Essais de réception : transition vers l'état opérationnel...................................................50
3.4 Administration sécurisée du système.................................................................. 58
3.4.1 Gestion des modifications de configuration........................................................................... 59
3.4.2 Sécurité physique............................................................................................................................... 59
3.4.3 Architecture et configuration réseau..........................................................................................59
3.4.4 Postes de travail des administrateurs.......................................................................................60
3.4.5 Interfaces d'administration..............................................................................................................60
3.4.6 Administration des fonctions de sécurité.................................................................................64
3.4.7 Procédures de sécurité.................................................................................................................... 75
3.5 Utilisation sécurisée du système...............................................................................80
3.5.1 Interface utilisateur : Telephone User Interface................................................................... 80
Chapitre 4
Topologie
4.1 Préambule.......................................................................................................................................103
4.2 Zone principale à base d'OmniPCX Media Gateway............................. 103
4.2.1 Architecture..........................................................................................................................................103
4.2.2 ACT de la zone principale.............................................................................................................104
4.3 Zone principale à base d'ACT Media Gateway........................................... 105
4.3.1 Serveur de communication sur une carte CPU..................................................................105
4.3.2 Serveur de communication sur un Appliance Server...................................................... 106
4.4 Mise en oeuvre des Media Gateways...................................................................107
Chapitre 5
Généralités sur le BootDVD
Chapitre 6
Lancement du logiciel du Communication Server
6.2 Swinst..................................................................................................................................................112
6.3 Patchs................................................................................................................................................. 112
6.3.1 Patchs Linux........................................................................................................................................ 112
6.3.2 Patchs téléphoniques de type statique...................................................................................112
6.3.3 Patchs téléphoniques de type dynamique............................................................................ 113
Chapitre 7
Partitionnement du Communication Server
Chapitre 8
Installation du Communication Server sur une machine physique
Chapitre 9
Installation du Communication Server sur une machine virtuel
Chapitre 10
Autres machines virtuelles
Chapitre 11
Installation de Generic Appliance Server
Chapitre 12
Configuration du Communication server
Chapitre 13
Mise à jour du logiciel du Communication Server
Chapitre 14
Mise à jour du système d'exploitation du produit (bootDVD uniquement)
Chapitre 15
Conformité aux normes
Chapitre 16
Annexes
1 Documents de référence
La documentation OmniPCX Enterprise englobe les documents répertoriés dans le tableau suivant :
CCdistribution 8AL91301FRAG
Cloud Connect Operation Overview 8AL91354ENAA
ALE Terminals Accessories Management 8AL90373ENAA
OXE Description of IP Flows 3BA290002903XXZZA
Ce manuel est destiné aux personnes chargées d'installer et de mettre en service l'un des produits
suivants sur le site du client :
• OmniPCX Enterprise « serveur de communication »
Le serveur de communication est basé sur un système d'exploitation Linux et une application
téléphonique, qui peuvent être installés sur un matériel physique fourni par Alcatel-Lucent
Enterprise, ou un environnement virtualisé (KVM, VMware ESXi, Hyper-V ou Nutanix AHV).
• OXE Media Services (OXE-MS)
Le site OXE Media Services est basé sur un système d'exploitation Suse Linux Enterprise et le
logiciel OXE-MS, installés dans un environnement virtualisé (KVM, VMware ESXi, Hyper-V ou
Nutanix AHV).
• Serveur OST pour OXE Signaling Translator ou External Encryption Gateway
Le serveur OST est basé sur le système d'exploitation Suse Linux Enterprise (SLES) et le logiciel
OST, installés dans un environnement virtualisé (KVM, VMware ESXi, Hyper-V ou Nutanix AHV).
• Generic Appliance Server (GAS)
Le GAS est un logiciel à part entière installé dans un environnement KVM virtualisé, comprenant
une machine virtuelle de Communication Server, une machine virtuelle optionnelle OXE-MS et une
passerelle WebRTC optionnelle.
Ce document fournit des détails sur :
• Pour chaque produit logiciel, l'installation à partir de zéro d'une version logicielle sur un
environnement virtualisé (KVM, VMware ESXi, Hyper-V ou Nutanix AHV), ou sur un matériel
physique fourni par Alcatel-Lucent Enterprise (serveur de communicationOmniPCX Enterprise
uniquement).
Pour installer un produit logiciel, voir :
• Installation du Communication Server sur une machine physique à la page 116
• Installation du Communication Server sur une machine virtuel à la page 134
• Installation de Generic Appliance Server à la page 291
• Installation du système OXE Media Services à la page 260
• Installation du serveur OST 8for OST64 ou EEGW) à la page 281
• Pour le serveur de communication OmniPCX Enterprise, les opérations de mise à jour consistent à
installer une nouvelle version du logiciel par-dessus une version existante, sur une partition active
ou inactive.
Pour mettre à jour un serveur de communication, voir : Mise à jour du logiciel du Communication
Server à la page 394
• Pour les serveurs GAS, OXE-MS et OST, la mise à jour du système d'exploitation Suse Linux
Enterprise (SLES) qui héberge le produit, voir : Mise à jour du système d'exploitation du produit
(bootDVD uniquement) à la page 413.
Ce manuel comprend les opérations de mise en place :
• Le rôle du Communication Server en tant que :
• Serveur de communication principal ou dupliqué : voir : Duplication du Communication Server à
la page 342
• Passive Communication Server (PCS) : voir : Serveur de communication passif à la page 367
• Adressage Multi-IP : voir : Implémentation de l'adressage multi-IP
3.1 Introduction
Le présent chapitre est un "plan d'action" à suivre pour déployer et exploiter, en toute sécurité, la
solution de communication VoIP d'Alcatel-Lucent Enterprise dans des entreprises de taille moyenne :
l'OmniPCX Enterprise.
La sécurité suppose un compromis entre deux "intervenants" souvent conflictuels :
• le propriétaire du système de communication, qui évalue les risques et les coûts découlant de ce
système ;
• l'usager du système de communication, qui privilégie la facilité d'utilisation sur la sécurité et qui
compte bien bénéficier d'un ensemble de services de communication complet. Une utilisation
responsable du système de communication peut ainsi se traduire, sur le long terme, par l'ouverture
d'un plus grand nombre de fonctionnalités par le propriétaire du système.
La sécurité absolue étant un idéal difficile à atteindre, le présent plan d'action se veut être une "recette"
pratique principalement axée sur une seule entreprise de taille intermédiaire pour laquelle la maturité
de la sécurité est probablement moins élevée que celle des grandes entreprises disposant d'un service
d’infrastructure d'informations robuste.
Ce déploiement de précision a été validé comme étant à la fois fonctionnel et sécurisé :
• Sur le plan fonctionnel, il a été validé par l'équipe technique d'Alcatel-Lucent Enterprise ;
• La sécurité a été validée lors d'un processus de certification de critères communs conduit par un
laboratoire indépendant composé d'experts en sécurité agréés par l'Agence nationale française de
sécurité des systèmes d'information (ANSSI).
Le présent plan d'action fournit des informations concernant les valeurs spécifiques à adopter pour la
configuration et l'ordre à respecter. Les détails concernant la marche à suivre pour procéder à cette
opération de configuration font partie de la formation sur la certification du partenaire commercial
standard et figurent dans les documents techniques de la solution.
1 Ce certificat peut être consulté sur le site de l'ANSSI à l'adresse URL : https://www.ssi.gouv.fr/
uploads/IMG/certificat/ANSSI-CC_2010-15fr.pdf
Ce symbole signale la présence d'instructions qu'il est impératif de bien comprendre et d'appliquer
pour atteindre le niveau de sécurité prévu. Le non-respect de ces instructions RENDRA certains
moyens vulnérables aux attaques et engendrera des conséquences commerciales ET pécuniaires
SIGNIFICATIVES.
3.1.3 Glossaire
Abrégé Désignation Définition
ACSE Alcatel-Lucent Enterprise Certified Technicien d'un partenaire
System Engineer commercial qui a suivi des sessions
de formation avec succès et qui a
subi un examen pour obtenir cette
qualification
BP Business Partner Entreprise indépendante qui revend
des produits Alcatel-Lucent
Enterprise à des clients
CC Common Criteria Norme à respecter pour évaluer la
sécurité des produits. On parle aussi
de norme ISO 15408.
• L'espace de bureau est une zone privée qui –en général- n'est pas accessible aux membres du
public à moins que ces derniers rendent visite à un employé et qu'ils soient accompagnés par un
employé (une personne habilitée).
• Le centre de données n'est pas accessible à tous les employés : l'accès à cette zone doit répondre
à une exigence et être accordé aux administrateurs système en donnant à ces derniers un badge
offrant les droits d'accès requis. Les concierges peuvent accéder au centre de données, mais
uniquement sous la supervision d'un agent de sécurité.
Dans les faits, les procédures relatives à la sécurité physique sont plus complexes, car d'autres zones
doivent être prises en compte : plancher surélevé, armoires fermées, etc. L'exemple de procédure de
sécurité physique détaillée ci-dessous dresse la liste des exigences potentielles applicables entre la
zone la plus sécurisée et la zone la moins sécurisée :
tableau 3.1 : Exigences applicables à la zone de sécurité physique
Espace de bureaux à usage Intermédiaires faibles Accès contrôlé par badge en tout temps
général avec zonage possible. Les concierges
sont autorisés pendant les heures de tra-
vail et en dehors des heures de travail.
Commutateur d'infrastructure entre les 2 sous-ré- Soit dans le centre de données, soit dans la salle
seaux principaux de réseau central
Câblage réseau entre le commutateur d'infras- Tubes de câbles entre les étages
tructure et les commutateurs de répartition
Câblage réseau entre les commutateurs de répar- Planchers surélevés ou plafonds suspendus
tition et les prises murales
Data servers
Decontamination subnet
Data Users
subnet
IP switched LAN
Workstation Workstation
Dans les environnements qui présentent des risques plus critiques pour la sécurité, les fonctions de
sécurité suivantes peuvent être activées dans le commutateur d'infrastructure :
• Des VLAN peuvent remplacer des sous-réseaux IP afin de mieux isoler les serveurs du trafic
provenant de la zone d'espace à bureaux (p. ex. attaques UDP provenant des postes de travail)
• Listes de contrôle d'accès permettant de contrôler le trafic entre des sous-réseaux (ou VLAN) et de
limiter le débit auquel divers types de paquets peuvent pénétrer dans le sous-réseau du serveur de
données, ce afin d'empêcher un refus de service par inondation des serveurs de données ;
• Fonction de pare-feu dynamique qui applique une stricte conformité aux politiques du trafic réseau
de l'entreprise.
Cette entreprise protège ses serveurs de données contre les clients de données potentiellement
malveillants qui pourraient se trouver à l'extérieur de la salle du serveur, dans la zone de bureaux ou
sur l'Internet.
Internet et la DMZ ne seront plus mentionnés dans le mémento de ce chapitre.
• La journalisation des événements de sécurité est activée sur des serveurs et des postes de
travail.
• Les journaux sont envoyés à un serveur de réception central.
• Les journaux sont examinés à intervalles réguliers pour détecter toute activité intempestive.
• Audits de sécurité mis en place périodiquement et mesures prises en fonction des résultats
• Identification et authentification de l'utilisateur
• Personne ne peut se logger à des comptes de groupe
• Un compte par utilisateur
• Appliquer une politique de "mot de passe fort"
• S'assurer que le mot de passe est changé régulièrement (tous les 3 mois par exemple).
• Supprimer ou désactiver les comptes non utilisés : les comptes système et utilisateur
• Changer tous les mots de passe par défaut, durcir les règles régissant les mots de passe
• Imposer des limites de quota sur les ressources qu'un compte utilisateur peut utiliser
• Configurations de dispositifs réseau par défaut
• Tous les mots de passe par défaut doivent être changés avant de connecter le système au
réseau.
• Vérifier tous les paramètres de configuration par défaut avant de connecter le dispositif au
réseau.
• Confiance à l'égard des "personnes habilitées"
• Les administrateurs sont bien formés et ne commettent pas d'erreur lorsqu'ils configurent le
système.
• Les administrateurs sont dignes de confiance et n'exécutent pas d'actes illicites, tels que des
modifications non permises visant des paramètres de configuration, l'installation de programmes
illicites ou la suppression de journaux d'activité.
• Des contrôles d'antécédents sont effectués lorsqu'on embauche du "personnel habilité".
• Vulnérabilités du logiciel
• Tester rapidement les mises à jour de sécurité du vendeur avant de les déployer à grande
échelle
• Bannir tout logiciel non autorisé sur des dispositifs connectés au réseau
• Exécuter un anti-virus sur les postes de travail, activer le pare-feu hôte du poste
• Empêcher l'arrivée de spams et de malware en filtrant les connexions Internet
• Installer un détecteur d’intrusion de réseau
• Politique de sécurité applicable aux sous-traitants dans la zone où ont lieu des activités de
maintenance et de support
Leur motivation est modérée : principalement évitement fiscal ou vol, plus rarement refus de service
sur l'OmniPCX Enterprise attaqué (par exemple pour exercer des représailles ou dégrader l'image
publique de l'entreprise dans le cas d'un ancien employé mécontent). De même, l'accès à des
informations confidentielles constitue rarement le motif, car cela peut se faire en utilisant des moyens
mieux connus et déployés plus facilement (p. ex. piratage psychologique).
Plus précisément, tous les accès au PSTN de l'utilisateur externe malveillant se font par le biais d'une
entreprise de télécommunications en utilisant un téléphone ou un modem : il ne bénéficie pas d'un
accès direct aux lignes RTPC pénétrant dans le PBX et, par conséquent, ne peut pas élaborer des
paquets RNIS du fait de la sécurité physique des lignes réseau et des lignes de communication
implémentés par l'entreprise de télécommunications.
Serveur OmniVista 8770 OmniPCX EnterpriseServeur d'appel OmniPCX Enterprise Media Gateway
CPU principal avec
messagerie vocale 4645
CPU de secours
Administrateur TDM
Téléphone IP Téléphone IP
Téléphone SIP Téléphones analogiques
Opérateur TDM
Téléphones TDM
Crystal 1
tableau 3.3 : Agencement du châssis Media Gateway
SLI (1-6)
Les procédures d'installation et de mise en route doivent être effectuées par un partenaire
commercial Alcatel-Lucent Enterprise certifié (ACSE), jamais par les administrateurs du client ou des
utilisateurs finals.
Planification de l'installation
Étape 1 - § 3.3.1.1
Installation physique
Étape 2 - § 3.3.1.2
Installation du logiciel
Étape 3 - § 3.3.1.3
Sécurité et configuration IP
Étape 4 - § 3.3.1.4
Configuration du téléphone
Étape 5 - § 3.1.5
Démarrage
Étape 6 - § 3.3.1.6
Chacune de ces étapes est détaillée avec des conditions initiales et finales qui présentent des
exigences de connectivité aux divers éléments de solution, et indiquent l'outil utilisé pour accéder à ces
éléments.
Ces composants seront utilisés pour élaborer un LAN isolé lors des prochaines étapes, telles que
décrites plus bas :
PSTN falsifié
Téléphone IP
Hub IP
Administrateur TDM
Téléphone SIP
Téléphones analogiques
Opérateur TDM
OmniPCX Enterprise
Serveur OmniVista 8770 Serveur d'appel
Téléphones TDM
Figure 3.5 : Sécurisation de l'installation sur un LAN isolé à l'aide d'un concentrateur
Le LAN isolé sera utilisé au-delà de la dernière phase, lorsque le client autorise la connexion à son
LAN d'exploitation.
Lors de cette opération, tous les éléments sont retirés de leurs caisses et cartons OmniPCX
Enterprise ; les châssis sont placés dans des baies, mis sous tension, mais pas allumés. Les systèmes
de refroidissement sont connectés, si nécessaire.
Les exigences physiques figurent dans la documentation spécifique à chaque produit.
L'accès physique aux composants de solution critiques doit être rigoureusement contrôlé. Comme un
tel contrôle peut s'avérer onéreux en termes de contraintes liées au bâtiment ou de frais généraux
supplémentaires pour accéder aux zones contrôlées, plusieurs zones de sécurité physique sont
définies, chacune avec ses propres exigences.
Le tableau ci-dessous répertorie les zones de sécurité physique et les composants de solution
hébergés associés :
tableau 3.5 : Zones de sécurité physique hébergeant les composants de l'OmniPCX Enterprise
Les deux composants de l'OmniPCX Enterprise (CS et MGW) doivent être installés dans une
salle (le centre de données) dont l'accès est limité aux administrateurs et aux personnes de confiance
uniquement. Il peut s'agir, par exemple, d'une pièce sans fenêtre dont la porte s'ouvre au moyen d'une
carte magnétique, dont les murs ne comportent aucun espace au-dessus ou au-dessous du plancher
surélevé ou du plafond suspendu, mais qui courent, au contraire, vers le haut sur toute la hauteur
jusqu'au plancher et jusqu'au plafond du bâtiment.
Les postes de travail sur lesquels les clients 8770 sont installés sont réservés à l'usage exclusif
des administrateurs. Ils doivent être protégés contre les tentatives d'accès physique de personnes non
habilitées, en les installant, par exemple, dans une salle verrouillée dont la clé est fournie uniquement
aux administrateurs.
Des informations importantes spécifiques à une version logicielle sont énoncées dans la note de
version publiée en tant que Communications techniques (document 5). Consultez ces documents
avant de continuer.
que root), utilisez l'outil Swinst pour afficher cette identité logiciel (chemin de menu 2-8-2). Si vous
utilisez le port console, veuillez noter que cette valeur est affichée lors d'une ouverture de session en
tant que mtcl (à condition que le service téléphonique ait commencé).
Au minimum :
• Un anti-virus doit être installé et convenablement configuré avec une base de signature à jour ;
• Un pare-feu doit être activé et configuré pour permettre l'ensemble de flux IP le plus petit possible ;
• Le nombre minimal de services doit pouvoir être offert ;
• Les mécanismes de mise à jour Windows et Java doivent être désactivés ;
• D'autres mesures de sécurité (p. ex. protection contre une inondation SYN) doivent également être
activées (voir l'étape 8 ci-dessous).
Pour en savoir plus sur ces mesures de sécurité et leur compatibilité avec l'application du serveur
8770, voir la rubrique Déploiement de l'OmniVista 8770 dans un environnement Windows sécurisé
du document 8AL90705FRAK.
Des informations importantes spécifiques à une version logicielle sont énoncées dans la note de
version publiée en tant que Communications techniques (document 6). Consultez ces documents
avant de continuer.
Le document 8AL90705FRAK est le guide à suivre étape par étape pour renforcer le
déploiement de l'OmniVista 8770. Il est impératif de lire ce guide en entier et d'appliquer les consignes
qu'il contient lors de l'installation.
Le document 8AL90705FRAK présente la méthodologie générale, les rubriques 3 et 4 traitent du
renforcement de la couche d'infrastructure : plateforme Windows et réseau, tandis que les rubriques 5
et 6 décrivent le renforcement au niveau de la couche applicative en vue de protéger les données de
gestion de téléphonie pendant un transit depuis le PBX et sur l'OmniVista 8770.
• Une passerelle média (MGW) fonctionnant sur un matériel spécifique Alcatel-Lucent appelé
Common Hardware ;
Pour plus d'informations sur cette plate-forme matérielle, voir le document 8AL91027FRBA.
• Un serveur d'administration (serveur OmniVista 8770) fonctionnant sur un système d'exploitation
Microsoft pris en charge ;
• Un client ou plusieurs clients d'administration (client OmniVista 8770 ) fonctionnant comme des
applications standard Microsoft Windows sur des postes de travail ;
• Des postes téléphoniques vocaux IP ou logiciels.
Les recommandations de sécurité en place pour le LAN existant doivent être respectées pour les
composants vocaux.
OmniVista
Serveur(s) de données
8770 serveur
PSTN
Serveur de gestion
OmniPCX Enterprise OmniPCX Enterprise
Serveur d'appel Media Gateway
IP
basculé
LAN Sous-réseau des utilisateurs de données :
Téléphones analogiques
Opérateur TDM
Téléphone SIP
Téléphone IP Téléphone IP
Téléphones TDM
Sous-réseau des utilisateurs voix
Il se peut que des équipements données soient utilisés pour contrôler la transmission des flux IP entre
les trois sous-réseaux.
Sous-réseau des serveurs données et voix
Les serveurs CS, MGW et 8770 sont connectés au sous-réseau des serveurs données et voix.
Les serveurs CS, MGW et 8770 doivent être installés dans une salle fermée à clé dont l'accès est
réservé au personnel habilité, éventuellement dans la même pièce que celle dans laquelle sont
installés les serveurs de données préexistants.
L'accès physique aux câbles (Ethernet, série, alimentation) doit également être contrôlé et limité pour
éviter toute falsification.
Sous-réseau des utilisateurs de données
Les clients OmniVista 8770, qui sont installés sur des postes de travail existants utilisés exclusivement
par des administrateurs, se trouvent sur le sous-réseau des utilisateurs de données. L'accès physique
à ces postes de travail est limité au personnel de confiance uniquement.
Lorsqu'aucun softphone n'est déployé, la sécurité physique entre la salle du serveur et les prises LAN
murales doit être garantie, conformément à la politique de sécurité du client. Lorsque des softphones
sont déployés, ils sont connectés à ce sous-réseau d'utilisateurs de données, qui doit ensuite
bénéficier des mêmes mesures de sécurité physique que le réseau d'utilisateurs voix (voir Sous-
réseau des utilisateurs voix à la page 33).
Sous-réseau des utilisateurs voix
Tous les postes vocaux matériels sont connectés au sous-réseau client voix.
La sécurité physique doit être assurée entre la salle du serveur et la prise murale à laquelle les
téléphones sont branchés. Les pratiques suivantes doivent être mises en place :
• L'équipement de commutation du réseau central se trouve soit à l'intérieur du centre de données,
bénéficiant ainsi de la protection physique de ce dernier, soit à l'extérieur du centre de données,
dans une zone physiquement protégée dont l'accès est limité au personnel habilité seulement.
Exemple : armoire dont la porte est fermée avec une clé (ou un verrouillage par clavier, lecteur de
cartes, etc.).
• Les équipements du réseau d’agrégation et de distribution (commutateurs LAN) sont installés dans
des armoires munies d'une porte verrouillée par une clé (ou un clavier, lecteur de cartes, etc.).
• Les câbles installés entre des commutateurs de réseaux centraux et d'agrégation/distribution sont
physiquement protégés par des conduites aménagées entre les planchers et offrant aucun accès
en dehors de l'entrée des conduites elles-mêmes, qui se trouvent dans les armoires auxquelles
elles sont raccordées.
• Les câbles situés entre le dernier commutateur de distribution et la prise murale sont installés dans
des plafonds suspendus (plénum) ou sous un plancher surélevé, dans un endroit difficile d'accès
pour une personne malveillante qui voudrait passer inaperçue.
Matrice d'interconnexions
La solution OmniPCX Enterprise ajoute les flux suivants entre les éléments de réseau
supplémentaires :
tableau 3.6 : Matrice d'interconnexion des éléments Voice over IP
Pour être plus précis, la solution OmniPCX Enterprise autorise les flux suivants dans chaque sous-
réseau :
• Sous-réseau des utilisateurs voix
• Flux de signalisation entre les postes téléphoniques et le serveur d'appels OmniPCX Enterprise ;
• Flux média entre les postes téléphoniques (appels téléphoniques internes), entre les postes
téléphoniques et la passerelle média (appels RTC ou appels avec téléphones DECT et d'autres
téléphones non IP tels que les téléphones TDM), entre les postes téléphoniques et le serveur
d'appels OmniPCX Enterprise pendant l'enregistrement et la lecture des messages vocaux.
• Lorsque des softphones sont déployés :
• Flux média entre les softphones et les postes téléphoniques (appels internes).
• Sous-réseau des utilisateurs de données :
• Les flux application déjà identifiés dans la politique de sécurité du réseau préexistant du client ;
• Les flux IPsec entre les postes de travail fonctionnant sur le client OmniVista 8770 et le serveur
OmniVista 8770.
• Lorsque des softphones sont déployés :
• Flux de signalisation entre des applications softphones et le serveur d'appels OmniPCX
Enterprise ;
• Flux média entre les applications softphones (appels téléphoniques internes), entre les
softphones et des postes téléphoniques (appels internes), entre les softphones et la
passerelle média (appels RTC ou appels avec téléphones non IP tels que les téléphones
TDM), entre les softphones et le serveur d'appels OmniPCX Enterprise pendant
l'enregistrement et la lecture des messages vocaux.
• Sous-réseau des utilisateurs de données :
• Les flux application déjà identifiés dans la politique de sécurité du réseau préexistant du client ;
• Sous-réseau des serveurs Voix
• Flux de signalisation entre la passerelle média et le serveur d'appels, flux de signalisation entre
les téléphones IP et logiciels et le serveur d'appels ;
• Flux média entre la passerelle média et le serveur d'appels (cas d'un utilisateur de téléphone
TDM quittant ou recevant un message de messagerie vocale) ;
• Flux de gestion entre le serveur OmniVista 8770 et le serveur d'appels ;
• Flux IPsec provenant des applications client OmniVista 8770 et se dirigeant vers le serveur
OmniVista 8770.
• Lorsque des softphones sont déployés :
• Flux de signalisation entre des applications softphones et le serveur d'appels OmniPCX
Enterprise ;
• Flux média entre les softphones et la passerelle média (appels externes ou appels vers des
postes TDM ou DECT), entre les softphones et le serveur d'appels lorsqu'on quitte ou qu'on
lit un message de messagerie vocale.
srv-mgw PSTN
srv-router srv-csm Srv-mga
Srv-csA
Sous-réseau des utilisateurs de données
Srv-csB :
Routeur Dtcl Dtcl-net
Dtcl1
Dtcl2,...
IP
basculé Clavier
LAN Stations de travail Postes de travail standards
+ OmniVista 8770
Client Administrateur TDM
Opérateur TDM
Téléphones analogiques
PSTN
192.168.1.31
192.168.1.1 192.168.1.32
192.168.3.0/24
Pour faciliter la consultation, les données ont été récapitulées dans le tableau ci-dessous :
3 La navigation dans les menus swinst et netadmin est toujours donnée à partir du menu de niveau
supérieur. Il n'est pas nécessaire de revenir au niveau supérieur avant de passer dans un autre sous-
menu.
4 Configurer un serveur Configurer le serveur DHCP pour Rubrique DHCP sur IPv4 du
DHCP pour des les postes IP en utilisant le choix document 8AL91047FRAA.
postes de téléphone de l'outil mgr "DHCP
Voir Les attaquants éventuels à
IP. Configuration".
la page 21 pour les paramètres
spécifiques.
4 Contrôler les appels. Configurer l'interdiction d'appels Rubrique Gestion via 8770 du
en définissant les postes document 8AL91002FRBA
téléphoniques et la Classe de
services d'accès au réseau
public pour contrôler des appels
téléphoniques entrants et/ou
sortants.
5 Compte DISA La taxation DISA est toujours
activée.
6 Taxer les appels. La taxation de tous les appels
est toujours activée.
7 Gérer le verrouillage Définir le préfixe de verrouillage/ Verrouiller/déverrouiller une
téléphone. déverrouillage et activer rubrique du document
individuellement des utilisateurs 8AL91003FRBA
pour verrouiller leur téléphone.
3.3.1.6 Démarrage
Voici la dernière opération à exécuter pour transformer un système en cours d'installation sur un
système opérationnel Comme ce fut le cas lors des opérations précédentes, cette tâche incombe à un
ACSE.
Pour une liste complète des flux IP de la solution, reportez-vous à la rubrique Services IP et numéros
de ports du document 8AL91047FRAA.
Pour la configuration opérationnelle du téléphone avec OmniVista 8770, voir la rubrique Gestion
via mgr du document 8AL91002FRBA.
Il s'agit de l'interface privilégiée, car toutes les étapes peuvent être effectuées à partir de
l'OmniVista 8770, y compris la vérification de la configuration de l'OmniVista 8770.
• La ligne de commande mgr accessible après ouverture d'une session SSH sur le CS et connexion
en tant que ‘mtcl’.
Pour plus de détails sur la configuration via mgr, voir la rubrique Gestion via 8770 du document
8AL91002FRBA.
Les lignes de commande de l'OmniPCX Enterprise sont toujours accessibles pour exécuter
plusieurs contrôles de niveau système sur le CS et la MGW. Les lignes de commande peuvent être
utilisées via une connexion de console distante initiée à partir d'un client OmniVista 8770.
Les interfaces OmniVista 8770 et mgr présentent les paramètres organisés dans une structure
hiérarchique. Les paragraphes qui suivent donnent le détail de leur emplacement dans la structure
hiérarchique et la valeur recommandée, ce pour chaque paramètre de configuration de téléphone.
Exemple d'informations
affichées
L'accès SSH est restreint par l'authentification administrateur. Pour la configuration du mot de passe
administrateur, voir la section Bonnes pratiques concernant le plan d'adressage IP à la page 34
OmniPCX Enterprise CS Etapes de configuration 3, 4, 5 et 6.
Les paragraphes qui suivent traitent des fonctions nécessitant une attention spéciale pour garantir la
sécurité (seuls les paramètres qui peuvent être configurés de manière utile pour la sécurité sont décrits
ici).
Lorsqu'un événement suspect se produit, une alarme est immédiatement transmise au poste
téléphonique de l'administrateur.
3.3.2.1.5 DISA
Parameters Stratégie Valeurs recommandées
Blocage temporaire DISA activé System > Other System Param. Oui
> DISA Parameters
Code d'accès DISA Trunk Groups > Trunk Group Chaîne de 4 chiffres entre 0 et 9.
Utiliser un code spécifique pour
chaque faisceau en utilisant
DISA.
Préfixe de déverrouillage DISA Translator > Prefix Plan > Entrer un numéro de préfixe
Number compatible avec le plan de
numérotation existant (utiliser un
Translator > Prefix Plan > Prefix
seul préfixe de déverrouillage
Meaning
différent pour chaque faisceau
utilisant DISA).
Dans la liste, sélectionner le pa-
ramètre : Unlock DISA.
gestion de réseau OmniVista 8770. Exécutez ces opérations à partir d'un client PC distant et via
une session Web.
• Vérifiez si l'accès de gestion 8770 se connecte correctement et si les autorisations d'accès sont
bien établies.
• Au niveau de l'Annuaire système, procédez à une synchronisation complète et vérifiez si tous les
postes téléphoniques (extensions) ont été téléchargés correctement.
• Si l’annuaire entreprise est utilisé, vérifiez les informations suivantes :
• le champ Poste principal est renseigné pour les utilisateurs disposant d'une entrée annuaire et
d'un poste sur le PCX,
• absence d'homonymes (détectés par le module d'alarmes),
• la possibilité de connexion à l’annuaire entreprise et de lancement d’un appel automatique par
un navigateur Internet. En cas de dysfonctionnement, vérifiez les UID des utilisateurs et l’attribut
STAP du poste (autorisé, décroché, interdit).
• Pour chaque PCX, vérifiez le lancement de SHH et l'accès à la configuration.
• Taxation : vérifiez la remontée des tickets à l’organisation, puis générez un rapport de Taxation.
• Analyse de trafic : générez un rapport d’analyse de trafic.
• Alarmes : vérifiez, pour chaque PCX, la remontée des alarmes ainsi que la remontée des
événements si la synchronisation (OmniPCX Enterprise vers le 87xx) est cochée coté PCX.
• Topologie, vérifiez la remontée de la topologie du réseau de PCX.
• Planificateur : vérifiez le statut des tâches planifiées par défaut et celui des tâches planifiées par
l'administrateur. La sauvegarde de la base de données et du PCX doit être planifiée.
• Maintenance
• Dans l'application Maintenance, exécutez la tâche de sauvegarde immédiate. Cela a pour effet
de télécharger une sauvegarde immédiate entre le PCX et le système de gestion réseau
OmniVista 8770.
Une opération de sauvegarde doit préalablement être effectuée à l’aide de Swinst à partir
d'OmniPCX Enterprise CS.
• Exécutez une opération de sauvegarde du système de gestion réseau OmniVista 8770.
• Licence : Ouvrez le menu Aide > A propos de et vérifiez si le nœud de déclaration a bien été trouvé
et si la quantité d'utilisateurs gérés ne dépasse pas la limite définie par la licence.
La rubrique Vérification de l’installation du serveur du document 8AL90704FRAN décrit le
processus plus en détail.
La responsabilité incombant aux administrateurs est grande, en raison des privilèges d'accès
étendus : les employeurs leur font confiance et s'appuient sur leur professionnalisme pour agir de
manière responsable au mieux des intérêts des systèmes de communication administrés.
• Afin d'empêcher d'autres postes de travail non-protégés d'utiliser l'application client OmniVista
8770, le serveur OmniVista 8770 doit refuser l'ensemble du trafic de gestion qui n'est pas protégé
par IPsec et IPsec n'est autorisé qu'en provenance de l'ensemble pré-déterminé d'adresses IP des
postes de travail des administrateurs,
• Des règles de routage (et éventuellement un taux limitant ou filtrant les règles) sont prévues dans le
commutateur de cœur de réseau IP.
À des fins de contrôle, la liste des flux IP autorisés se trouve dans la Matrice d'interconnexions à la
page 33.
Afin de garantir que la configuration de la solution OmniPCX Enterprise ne soit pas facilement
modifiable, l'OmniVista 8770 client doit être utilisé uniquement à partir de postes de travail dédiés aux
administrateurs accrédités : il ne doit ni être installé ni être utilisé sur des postes de travail partagés
entre administrateurs et utilisateurs réguliers (c'est-à-dire sur lesquels un utilisateur régulier peut
s'enregistrer sans être sous la supervision d'un administrateur).
Il faut toujours modifier les mots de passe fournisseur par défaut dès que les systèmes sont
reçus et avant de se connecter au LAN. Les administrateurs doivent régulièrement changer les mots
de passe sur l'OmniPCX Enterprise Communication Server et Media Gateway, l'application OmniVista
8770 et leurs propres comptes Windows. Il faut choisir des mots de passe avec un niveau de sécurité
élevé. (Des objectifs de sécurité de l'environnement seront ainsi mis en œuvre partiellement)
Les recommandations relatives aux mots de passe forts figurent dans la rubrique Stratégie
recommandée en matière de mot de passe du document 8AL91012FRBA.
Pour afficher les alarmes sur l'OmniVista 8770, mentionné dans Enumération des incidents à la page
61, est détaillé :
Voir la rubrique Alarmes du document 8AL90703FRAN
Il faut que l'administrateur sache qu'une utilisation malveillante peut entraîner des coûts très
élevés en matière de communication pour le propriétaire PBX. Les administrateurs doivent vérifier
l'activité DISA (utilisation des services DISA et des échecs de tentatives d'accès). Concernant ce
dernier point, voir Taxation DISA à la page 70.
4 Le service DISA est associé à un joncteur. Des tentatives d'accès infructueuses à un service DISA
entraînent le verrouillage du service DISA uniquement pour le joncteur associé. Les utilisateurs peuvent
continuer à utiliser DISA sur un autre joncteur, diminuant le caractère critique du déverrouillage manuel
du joncteur dans la configuration avec des joncteurs multiples. diminuant le caractère critique du
déverrouillage manuel du joncteur dans la configuration avec des joncteurs multiples.
Le poste téléphonique de l'administrateur peut recevoir des alarmes (Les postes d'alarme à la page
61) depuis le système de messagerie vocale :
• incident #904 "MESSAGERIE VOCALE. Info Utilisateur Inconnu <extension>" est généré si un code
d'accès incorrect est saisi.
Pour plus d'informations, voir la rubrique 4645 VMS du document 8AL91047FRAA.
Pour détecter les occurrences de telles attaques, les journaux d'incidents doivent être analysés
chaque semaine en veillant particulièrement à la présence de l'incident #386 (perte de lien de
signalisation avec le poste téléphonique IP et l'incident #2053 (redémarrage de téléphone IP). Une
première analyse est requise pour éliminer les faux positifs pouvant résulter d'utilisateurs débranchant
et rebranchant leur téléphone lors de déplacements vers le bureau.
Les téléphones SIP sont également pris en charge en plus des téléphones IP propriétaires. Ils donnent
accès à une gamme complète de services offerts par l'OmniPCX Enterprise. Certains paramètres
proxy SIP doivent être vérifiés pour garantir le même niveau de fiabilité que celui fourni par la gamme
de téléphones IP propriétaires :
• Méthode d'authentification minimale : par défaut elle est configurée sur "SIP résumé"
qui est la valeur recommandée. Une valeur de "SIP aucun" implique le risque d'un
appelant usurpant l'identité d'une autre personne.
Les administrateurs doivent régulièrement surveiller la taxation des appels, puisque cette
information concernant l'activité des appels peut aider à ajuster l'interdiction d'appel au plus près
(Taxation des appels à la page 69).
Les numéros abrégés permettent de contourner l'interdiction d'appel pour des destinations spécifiques.
Les numéros abrégés peuvent être configurée via mgr (mgr à la page 62) ou via l'OmniVista 8770
(OmniVista 8770 à la page 63). Les paramètres de configuration (chemin Numérotation abrégée >
Numéros abrégés directs > Préf.Num.abrég.direct) incluent :
• le préfixe à utiliser pour ce numéro abrégé doit être compatible avec le plan de numérotation de
l'installation,
• le numéro appelé qui sera transmis au réseau.
• Si ce numéro abrégé est soumis à des restrictions d'appels (interdiction d'appel) : oui = l'interdiction
relative au numéro d'appel est vérifiée, non = le numéro d'appel est transmis sans avoir été vérifié
(n'est pas bloqué par un verrouillage du téléphone).
La configuration des numéros abrégés est détaillée dans la rubrique Appel direct du document
8AL91003FRBA.
• Application APL_ACCOUNTING lorsque la taxation est activée ou désactivée, ou lorsque les tickets
sont perdus à cause des limites du buffer
• Application APL_SAVE lorsque l'espace disque de stockage est rempli
Les tickets de taxation peuvent être affichés en utilisant la commande accview (Outils de ligne de
commande Shell Linux à la page 63) ou l'OmniVista 8770 (OmniVista 8770 à la page 63). accview
propose une liste de fichiers à choisir, puis effectue l'action définie par le ou les arguments commande
sur ce fichier. Sa syntaxe est :
• accview Affiche la syntaxe de commande
• accview –f Affiche la liste des archives de tickets de taxation compressées
• accview -b <n> ou (accview -e <n>) Affiche les premiers (ou derniers) n tickets dans le
fichier concerné
Voir la rubrique accview du document 8AL91011FRBA.
L'OmniVista 8770 application de taxation est bien plus puissante et conviviale pour les administrateurs
qui peuvent suivre l'activité des appels et être alertés lorsque des seuils prédéterminés sont atteints
(coût, durée ou nombre).
Voir détails dans la rubrique Taxation : Analyse VOIP et performance du document 8AL90703FRAN.
L'OmniVista 8770 prend également en charge une application de reporting pour attribuer les coûts des
appels par unité commerciale, par opérateur, etc. Un nombre de rapport prédéfinis sont proposés pour
aider l'administrateur.
Voir informations détaillées dans le Manuel administrateur de l'OmniVista 8770 (document 2) Section 5
Rapports.
Les autres options pour la surveillance des appels sont :
• application de rapport financier interne
• Application tierce externe recevant des données de taxation par le biais d'Ethernet
• Le poste téléphonique de l'administrateur peut réaliser certaines opérations journalières sur cette
configuration au moyen de TUI (Telephone User Interface (Interface utilisateur téléphone) à la page
62)
Voir la rubrique Taxation du document 8AL91048FRAA.
Les administrateurs doivent régulièrement surveiller les informations relatives à la taxation des
appels en utilisant une des options ci-dessus selon leurs préférences et leurs besoins.
Si DISA est utilisé, les administrateurs doivent régulièrement surveiller les rapports de taxation
DISA.
Dès que le système est opérationnel, et régulièrement par la suite, l'administrateur doit vérifier le
contenu de la base de données hôte du système /etc/hosts et du fichier .rhosts de swinst
~swinst/.rhosts pour s'assurer que seul l'ensemble minimal strict de noms système et d'adresses
IP soit inclus. Cet ensemble est composé du système local et de son adresse de bouclage, des
adresses IP physiques et logiques du CS principal et passif. En cas de plusieurs OmniPCX Enterprise
mis en réseau, les adresses IP des CS principal et passif pour les nœuds en réseau font également
partie de cet ensemble minimal. Pour la configuration de la solution OmniPCX Enterprise, cela donne
le contenu prévu suivant :
/etc/hosts ~swinst/.rhosts
L'administrateur doit modifier le mot de passe par défaut durant l'installation système et changer
les mots de passe régulièrement en utilisant swinst.
La console système, locale ou distante, est toujours accessible par le compte mtcl. Ce mot de
passe de compte constitue une information sensible dont la confidentialité doit être strictement
garantie. Ce mot de passe doit avoir un niveau de sécurité très élevé (c'est-à-dire en utilisant une
phrase secrète encodée en langage haxor) et être changé régulièrement (p. ex. chaque trimestre).
Les journaux système peuvent être consultés en utilisant l'utilitaire de ligne de commande Linux utility
tail ou tout autre outil Linux approprié.
Le journal téléphonique peut être vérifié avec maoview (p. ex. pour contrôler l'activité d'authentification
CMIP, échecs et réussites de tentatives).
Maoview est décrit dans la rubrique maoview du document 8AL91011FRBA.
Pour détecter les occurrences des attaques d'usurpation d’adresses ARP à l'encontre d'un ou
plusieurs téléphones IP, les journaux d'incident doivent être analysés chaque semaine à la recherche
de l’occurrence d'incident #386 (perte de lien de signalisation avec le poste téléphonique IP et incident
#2053 (redémarrage de téléphone IP). Il faut prévoir des faux positifs car ces incidents sont également
générés lorsque des utilisateurs déconnectent et reconnectent plus tard leur téléphone après ou
pendant une perte de charge dans leur espace de bureau.
La distribution centralisée de logiciels est décrite dans la rubrique Mise à jour des
Communication Servers en réseau (chargement/installation à distance) du document
8AL91032FRBA
La restauration s'effectue un nœud à la fois. Les données restaurées peuvent être un sous-réseau
fonctionnel des données restaurées initialement.
OmniPCX Enterprise la sauvegarde et la restauration sont détaillées dans la rubrique maintenance du
document 8AL90703FRAN.
• Des tonalités connues (par ex. la tonalité ‘occupé’ spécifique à chaque pays) et des messages
vocaux (également appelés guides vocaux) pour la navigation par menu (sans affichage)
• Un message monoligne affiché pendant la tonalité ou la lecture du guide vocal
• Un message élaboré (avec icônes et affichage graphique) affiché pendant la tonalité ou la lecture
des guides vocaux.
Cette section doit décrire les configurations locales divergeant de l'expérience quotidienne d'utilisation
d'un opérateur téléphonique public : tonalité de numérotation, numérotation d'urgence, appel à
l'opérateur, etc. et couvrir les différents postes téléphoniques à disposition de l'utilisateur.
Toute utilisation inconsidérée de l'accès DISA peut occasionner des factures de communication
très élevées pour l'entreprise. Il est interdit de transmettre le code DISA à un tiers, même au sein de
l'entreprise. Il est de la responsabilité de l'administrateur de divulguer le code d'accès DISA aux
membres du personnel.
Les utilisateurs téléphoniques doivent également être conscients que la fonction DISA est
automatiquement verrouillée en cas d'échecs trop nombreux de tentatives d'accès : s'ils ne se
rappellent pas du code d'accès DISA, ils ne doivent pas tenter d'utiliser DISA, évitant ainsi de
verrouiller la fonction DISA pour tous les utilisateurs du faisceau entrant.
Un utilisateur compose le numéro DISA pour se connecter au service DISA. Une fois connecté,
l'utilisateur entend :
• Le guide vocal standard si DISA est actif ou un guide vocal d'erreur si DISA est inactif.
• Lorsque DISA est actif, une guide vocal répertorie ensuite les opérations disponibles, à moins que
DISA ne soit temporairement verrouillé suite à la saisie répétée d'un code d'accès incorrect.
• Si DISA est verrouillé, l'utilisateur entend un guide vocal de dissuasion l'informant de la situation.
Ce code doit être constitué, au minimum, de 7 chiffres pour empêcher la réussite de toute attaque
par force brute sur une brève période. Il doit être difficile à deviner et ne pas contenir de valeurs
fréquemment utilisées dans le contexte opérationnel (par ex. numéro du standard téléphonique) ou
personnel (par ex. date de naissance).
Voir la rubrique 4645 VMS du document 8AL91047FRAA.
Les utilisateurs ont accès aux opérations liées à la messagerie vocale après la numérotation de ce
code.
Voir la rubrique 4645 VMS8AL91047FRAA du document
Les utilisateurs peuvent modifier leur code à volonté ou être forcés de le modifier (lors de leur premier
accès au service de messagerie vocale ou à l'expiration de leur mot de passe). Les administrateurs
peuvent empêcher l'utilisateur de modifier son mot de passe dans les configurations hôtelières où des
services de messagerie vocale client sont utilisés. Ils peuvent configurer des restrictions sur le code
utilisateur (ex : mots de passe au niveau de protection insuffisant interdits).
Les utilisateurs sont encouragés à utiliser un mot de passe de 7 numéros minimum. Ces numéros
correspondent aux touches 0 à 9 et, si le poste téléphonique TUI le permet, aux touches A-D.
L'utilisateur doit modifier son code secret au moins une fois par an et utiliser le code le plus long
possible (au max. 10 chiffres). Ce code ne doit pas être trop facile : éviter les codes utilisés dans le
contexte opérationnel (par ex. numéro d'extension ou de fax) ou personnel (par ex. date de naissance,
anniversaire de mariage), les séquences de chiffres répétés, les séries logiques, même avec des
numéros proches les uns des autres (p. ex. 8901).
Il convient de rappeler aux utilisateurs qu'ils ne doivent pas divulguer les numéros abrégés aux
visiteurs ou à toute autre personne n'appartenant pas à l'entreprise, au risque d'entraîner des coûts de
communication supplémentaires à l'entreprise.
l'origine de l'apparente faille affectant la configuration du système déployé ou, le cas échéant, de faire
remonter le problème jusqu'au Business Partner Alcatel-Lucent Enterprise qui pourra alors résoudre
rapidement le problème. Dans le cas contraire le Business Partner de votre entreprise ouvrira une
Service Request auprès du service d'assistance technique Alcatel-Lucent Enterprise.
Dans les rares cas où votre service IT ne saurait éliminer la faille potentielle et où le Business Partner
ne fournirait par de réponse satisfaisante ni n'ouvrirait une Service Request, vous pouvez conseiller à
votre équipe d'assistance d'entreprise de consulter le site Web public d'Alcatel-Lucent Enterprise :
https://www.al-enterprise.com/en/support/security-advisories. Sur ce site, le grand public peut accéder
aux avis de sécurité publiés par Alcatel-Lucent Enterprise. Il est également possible de s'y abonner
pour recevoir des notifications à la publication de nouveaux avis de sécurité. En outre, la procédure de
signalement de failles de sécurité y est présentée en détail, accompagnée d'un modèle de rapport.
3.6.2.3 Entités
Entités 0 et 1 ne sont pas utilisées ni gérées.
L'entité 10 est gérée et l'entité de tous les postes est 10.
Ce qui donne aux utilisateurs :
• Numéro d'installation (ISDN)
• Numéro d’installation supplémentaire (ISDN)
• Services de débordement en fonction de l'état de l'entité
• Restriction des appels par l'état de l'entité (nuit, jour, mode 1, mode 2)
• Sélection du discriminateur des appels externes
Note :
Entité par défaut pour la création d'un poste est 1.
Les entités autres que 10 sont toujours en état Nuit.
• Catégorie Réseau public 10 pour poste 65003 (poste avec restriction sur appel sortant externe)
• Catégorie Réseau public 18 pour tous les autres postes
Gestion catégorie Réseau public 18 :
Droits aux appels entrants externes, au transfert Autorisés uniquement en mode JOUR de l'entité
en provenance d'un opérateur, au débordement du poste
sur opérateur
Droit aux appels sortants publics, privés, Autorisés uniquement en mode JOUR de l'entité
professionnels : du poste pour la zone 1 et 2 (cf Discriminateur)
Droit aux appels réseau sortants : Autorisés uniquement en mode JOUR de l'entité
du poste pour tous les sous-réseaux ABCF (cf
SIP)
Droit d'accès au faisceau : Autorisé uniquement en mode JOUR de l'entité
du poste pour les faisceaux bouclés et le faisceau
SIP (cf faisceaux et SIP)
Gestion Classe de service Réseau public 10 :
Droits aux appels entrants externes, au transfert Autorisés uniquement en mode JOUR de l'entité
en provenance d'un opérateur, au débordement du poste
sur opérateur
Droit aux appels sortants publics, privés, Autorisés uniquement en mode JOUR de l'entité
professionnels : du poste pour la zone 2 (discriminateur)
Droit aux appels réseau sortants : Autorisés uniquement en mode JOUR de l'entité
du poste pour tous les sous-réseaux ABCF (cf
SIP)
Droit d'accès au faisceau : autorisé uniquement en mode JOUR de l'entité du
poste pour les faisceaux bouclés et le faisceau
SIP (cf faisceaux et SIP)
Note :
La catégorie Réseau public par défaut pour la création d'un poste est 0.
Toutes les autres catégories Réseau public n'ont aucun droit, quel que soit l'état des entités.
Number: 66005
Accès avec mot de passe : Oui
Mot de passe trivial autorisé : Non
Mot de passe de l'administrateur : 3845627
Connexions simultanées max. : 16
Service de limitation d'appels : 4
Expiration du mot de passe : 60 jours
Tous les postes ont une messagerie vocale (sauf opérateur A11) :
3.6.2.11 Faisceaux
Le faisceau T2 ISDN est géré pour permettre des appels externes.
Ce faisceau est bouclé sur Crystal 1 comme suit :
Faisceau 1 :
Le numéro appelé sortant possède un discriminateur 7 virtuel (cf Discriminateur)
Faisceau 2 :
Le numéro appelé sortant possède un discriminateur 7 virtuel (cf Discriminateur)
Aucun préfixe pour prise de faisceau n'est géré, seul le préfixe ARS peut accorder l'accès aux appels
externes sortants (cf ARS et préfixe).
3.6.2.12 Discriminateurs
Les discriminateurs sont des index de tableaux permettant à l'administrateur du site de donner accès
aux numéros composés. Par défaut, les tableaux sont vides, interdisant toutes les numérotations.
Tableau discriminateur 3 possède deux numéros gérés :
Numéro d'appel : 01
Numéro de zone : 1
Numéro de table de routage ARS : 10 (ARS)
Nombre de chiffres : 10
Ainsi, en passant un appel sortant par le biais d'un faisceau avec discriminateur réel 3, on gère :
• Vous pouvez composer un numéro commençant par 01
• Ce numéro possède 10 chiffres
• Dans votre Catégorie accès rés.public, vous devez avoir accès à la zone 1
Si vous avez composé un préfixe ARS, le faisceau sélectionné sera celui dans le tableau 10 ARS.
Ceci signifie qu'en passant un appel sortant par le biais d'un faisceau avec discriminateur réel 3 est
géré :
• Vous pouvez composer un numéro commençant par 112
• Ce numéro possède 3 chiffres
• Dans votre Catégorie accès rés.public, vous devez avoir accès à la zone 2
Si vous avez composé un préfixe ARS, le faisceau sélectionné sera celui dans le tableau 12 ARS.
Tableau discriminateur 2 possède un numéro géré :
Numéro d'appel : 01
Numéro de zone : 1
Numéro de table de routage ARS : 11 (ARS)
Nombre de chiffres : 10
Ceci signifie qu'en passant un appel sortant par le biais d'un faisceau avec discriminateur réel 2 est
géré :
• Vous ne pouvez composer qu'un numéro commençant par 01
• Dans votre Catégorie accès rés.public, vous devez avoir accès à la zone 1
Si vous avez composé un préfixe ARS, le faisceau sélectionné sera celui dans le tableau ARS 11.
Note :
Le discriminateur virtuel par défaut est 0, le tableau est vide.
Les traducteurs DDI sont utilisés par les objets DESCRIPTEUR DE PLAN DE NUMEROTATION
(numéro des attributs DDI pour appelant et numéro DDI pour appelé).
Le numéro traducteur DDI 0 est utilisé et géré (Plan de numérotation à la page 85).
Ceci signifie que si le poste n'est pas dans un traducteur DDI, il peut passer un appel externe sortant,
mais ne peut pas recevoir un appel externe.
3.6.2.14 NPD
LE DESCRIPTEUR DE PLAN DE NUMEROTATION (NPD) décrit comment traduire les numéros reçus
en provenance du réseau externe et comment élaborer les numéros appelés vers ce réseau externe.
Voici les NPD utilisés :
NPD 33 (Faisceau 1 et 2)
Les appels 01xxxxxxxx seront envoyés par le faisceau 1 (et arriveront sur le faisceau 2 dans le
système).
3.6.2.19 DISA
Disa permet à un appel externe d'accéder aux services présents sur le nœud, notamment de substituer
un poste interne et de passer des appels (internes ou externes) en fonction des droits du poste
substitué.
La fonction Disa a été activée sur le faisceau 1.
Le numéro DDI DISA est 0155666009 correspondant au préfixe DISA 66009.
Le mot de passe DISA est 4608.
Le verrouillage temporaire DISA a été activé :
L'utilisateur DISA externe est habilité à 5 tentatives pour le mot de passe DISA et 3 tentatives pour le
mot de passe du poste. Après ces 5 tentatives, l'accès DISA est verrouillé pour le site entier (sur le
noeud correspondant à l'accès DISA). L'accès DISA est verrouillé pour une période définie par les
temporisateurs 257 et 258, et les appels DISA sont connectés à un guide de dissuasion. Après cette
période, le déverrouillage s'effectue automatiquement.
Liste entités 10
Centre de coûts 17
Public Network Category 10
Service de limitation d'appels : 4
Si l'application téléphonique se lance, le poste opérateur A11 affiche "mode nuit", le poste opérateur
est donc hors service pour le groupe opérateur.
Pour mettre A11 en service, appuyez sur la touche programmable supérieure droite, puis saisissez le
code secret de A11 si demandé -> le poste A11 est en service.
Note :
L'opération inverse (basculer en mode nuit) est effectuée de la même manière.
Ainsi seul le poste 65001 peut réaliser un appel DATA externe entrant.
3.6.2.22 e-RMA :
ERMA est géré sur le GD passerelle e-Media (Position 1-0).
3.6.2.24 Préfixes
Tous les préfixes peuvent être consultés ou créés à partir de TRADUCTEUR> PREFIXE.
Ce tableau permet de définir des préfixes de service téléphonique.
Pour sortir tous les préfixes et leurs significations, utilisez l'utilitaire LISTRAD.
Le fait que l'utilisateur puisse avoir recours à chaque préfixe dépend du COS de sa station (voir
FEATURE COS et TRUNK COS) sauf pour l'appel opérateur qui est accessible par tous.
3.6.2.25 Taxation
La taxation de la durée est configurée sur le nœud.
Activé sur le faisceau 1 et 2
3.6.2.29 SIP
Un proxy SIP est activé sur le serveur d'appels pour les postes SIP (port 5060).
L'authentification SIP est gérée, ainsi tous les postes SIP doivent donner leur code secret pour utiliser
le serveur d'appels.
Poste SIP créé 65004 avec code secret #SIP_2030!
Ce poste SIP est un modèle Thomson ST2030 :
Remarque : après 3 échecs de tentatives de connexion, le compte est verrouillé pendant 15 min.
Sur le GD
Sur le GA
Les adresses DHCP déclarées sont automatiquement remplies dans des hôtes fiables.
Login Jours
Root 90
Swinst Non recommandé
Mtcl 90
Adfexc 90
3.6.4.2.4 Antivirus
Vous pouvez installer un logiciel antivirus sur votre PC client et PC serveur OmniVista 8770, en
respectant les recommandations suivantes :
• Arrêtez l’antivirus pendant l’installation de l’OmniVista 8770.
• Définissez le répertoire utilisé par l'OmniVista 8770 comme exception dans la règle d’antivirus, afin
d’éviter l’analyse de l’antivirus dès que vous démarrez le client. Cela augmente la durée de
chargement de l’application client.
• Configurez l’antivirus, les options antispam et wormstopper pour autoriser le protocole de
messagerie (smtp port 25).
Autorisez les binaires Omnivista (javaw.exe) à utiliser le protocole de messagerie et augmentez le
nombre d’e-mails autorisés (l’option wormstopper peut limiter le nombre d’e-mails provenant d’un PC à
un maximum de six messages par minute).
Le serveur OmniVista 8770 (version5.0.07.05.c) est configuré pour se connecter et gérer srv-csm :
• Le serveur d'appel srv-csm est déclaré
• Connexion et mot de passe pour compte ftp (adfexc) sont déclarés (voir §7.a)
• SSH est activé
Pour utiliser la configuration, l'accès à la sécurité est activé et le mot de passe de la station pour
CMISD rempli (Manuel administrateur de l'OmniVista 8770)
Le port pour le serveur dap est 993 (389 par défaut). Ajouté à la configuration Ipsec.
Le port pour le serveur Apache est 7856 (80 par défaut). Ajouté à la configuration Ipsec.
La page d'accueil IE est configurée pour pointer sur ce serveur (avant d'utiliser, consultez la rubrique
« Accès via un navigateur » de la Documentation technique de l'OmniVista 8770).
Comptes OmniVista 8770 :
La gestion du pare-feu Windows a été effectuée pour permettre uniquement au sous-réseau utilisateur
de données d'accéder aux ports client OmniVista 8770 et aux ports application OmniVista 8770.
Le tunnel IPSec est géré en utilisant la méthode d'authentification basée sur PSK (la connexion à srv-
mgmt nécessite un niveau de sécurité) :
• Key = passphrase_pour_ipsec
• La stratégie serveur est d'accepter des communications non-cryptées et ne pas forcer la protection
de toutes les communications.
RAM 4 Go
Disque dur 40 Go
Carte graphique Mémoire vidéo de 4 Mo avec une résolution de
1024 X 768 en 16 millions de couleurs
Moniteur 17 pouces (19 pouces recommandé)
Navigateur Internet Internet Explorer (version 9, 10 ou 11)
Mozilla Firefox
Étant donné qu'il n'y a aucun serveur DNS sur la plateforme, srv-mgmt est ajouté aux fichiers hôtes de
dtcl1.
La gestion du pare-feu Windows a été effectuée pour permettre uniquement au serveur OmniVista
8770 d'accéder aux ports application client OmniVista 8770.
Pour utiliser l'application client OmniVista 8770 sur dtcl1 :
1. Exécute la commande Démarrer > Programmes > Client OmniVista 8770.
L'écran de connexion apparaît vierge.
2. Spécifiez le nom du serveur auquel vous souhaitez vous connecter
3. Saisissez le nom et le mot de passe d'un compte authentifié dans l'Annuaire d'entreprise de ce
serveur
4. Confirm
Le réseau est analysé à la recherche de ce serveur.
Connectez-vous à l'application en tant que Gest87xx pour effectuer des opérations normales (voir les
comptes OmniVista 8770 listés dans la section précédente).
La gestion de "politiques de sécurité locales" est effectuée.
La gestion des droits d'accès s'est effectuée pour le répertoire "c:\Client8770".
Un tunnel IPSec est géré en utilisant la méthode d'authentification basée sur PSK (accepter sécurité si
requis par le serveur) :
Key = passphrase_pour_ipsec
4 Topologie
4.1 Préambule
Cette rubrique décrit les différentes topologies possibles sur un noeud OmniPCX Enterprise.
Un nœud est constitué d'un serveur de communication qui contrôle une ou plusieurs Media Gateways.
Les Media Gateways fournissent les interfaces vers les postes et vers les réseaux extérieurs.
Chaque noeud est structuré entre zone principale et zones déportées. La zone principale contient une
Media Gateway “à proximité” du serveur de communication. C'est elle qui supporte les artères vers les
autres noeuds du réseau.
Les zones déportées peuvent être raccordées à la zone principale via le WAN (zone déportée IP avec
ACT ou OmniPCX Media Gateway) ou via le réseau public (raccordement RT2).
Il existe trois possibilités de supports pour le serveur de communication :
• une carte CPU hardware Crystal dans un meuble M2, M3, WM1 ou VH : le serveur de
communication est alors appelé IPCS (IP Crystal Server). La carte CPU8 n'est pas prise en charge
sur la WM1 ou le meuble VH
• Une carte CPU Common Hardware dans un coffret S ou L : le serveur de communication est alors
appelé IPRS (IP Rack Server).
• Appliance Server (PC externe) : le serveur de communication est alors appelé IPAS (IP Appliance
Server).
Il y a deux types de matériel pour les Media Gateway :
• coffrets S et L, pour les OmniPCX Media Gateways,
• meubles M2, M3, WM1, VH pour les ACT Media Gateway.
Quel que soit le matériel utilisé, les services offerts sont les mêmes. Cependant l'e-RMA et la
messagerie vocale A4645 ne sont pas disponibles sur carte CPU. Et certaines fonctions ne sont
disponibles que sur cartes au format de l'ACT (voir ci-dessous).
Les paragraphes qui suivent présentent les topologies possibles en fonction du matériel utilisé dans la
zone principale :
1. le matériel dans la zone principale est à base de coffrets S et L : le serveur de communication peut
alors être embarqué soit sur une carte CS placée dans un coffret S ou L, soit sur un Appliance
Server,
2. le matériel dans la zone principale est à base d'ACT : le serveur de communication peut être
embarqué soit sur une CPU placée dans un ACT, soit sur un Appliance Server.
INT-
IP B
MEX MEX
GD
WAN
LAN
INT-
GD IP B
Call Server
ACT
MEX
Appliance Server ou
MEX
carte CS
zone principale
Figure 4.1 : Exemple de configuration avec OmniPCX Media Gateway dans la zone principale
INT-
IP B
MEX MEX
GD RT2 Niv. 3
B
lien RT2
WAN
Réseau public
LAN
Niv. 1 INTOF
CPU B
INTOF Niv. 2
B
INTOF Niv. 2
B INTOF
B
Niv. 3
Niv. 2
zone principale
Note :
• seules les cartes contrôleur sont représentées sur le schéma,
• l'ACT principal doit aussi contenir une carte INT-IP A pour assurer les liaisons avec les zones déportées sur IP,
• à chaque carte INTOF B (ou RT2 B) correspond une carte INTOF A (ou RT2 A) sur l'ACT de niveau supérieur.
INT-
IP B
MEX MEX
GD
RT2
B
Niv.2
lien RT2
WAN
Réseau public
IOIP
Niv.1
INT-
Internet Server platform IP A
INTOF
B
Appliance Server
INTOF
B
Niv.2
zone principale
Figure 4.3 : Exemple de configuration avec Appliance Server et zone principale ACT
Note :
• dans cette configuration, l'ACT de niveau 3 est interdit,
• l'ACT principal est contrôlé par une carte IOIP (fonction signalisation 4x64 kbps). Cette carte ne comportant
pas de compresseurs, une INT-IP A est nécessaire pour assurer les communications IP avec les autres zones
déportées,
• à chaque carte INTOF B (ou RT2 B) correspond une carte INTOF A (ou RT2 A) sur l'ACT principal.
Le bootDVD est un logiciel destiné à être gravé sur un DVD de démarrage ou à être utilisé via une
machine virtuelle (format de fichier iso). Cela comprend principalement le système d'exploitation Suse
Linux Enterprise Server (SLES).
Son objectif est de pouvoir installer le système d'exploitation SLES et de préparer l'installation d'un
produit logiciel, tel que :
• OmniPCX Enterprise
• Generic Appliance Server
• OXE Media Services (OXE-MS)
• OST (OXE Signaling Translator 64 (OST64) ou External Encryption Gateway (EEGW))
La liste de produits est évolutive et peut inclure plus de produits.
Le bootDVD peut être déployé avec le logiciel du produit soit à partir de la machine hôte, soit à partir
du réseau via S.O.T. :
• Depuis le serveur hôte : une fois la machine physique ou virtuelle démarrée sur le bootDVD, un
menu apparaît à l'écran pour installer le système d'exploitation SLES et préparer l'installation pour
plusieurs produits. L'installation du produit dépend du produit en lui-même et nécessite un logiciel
supplémentaire, tel que Generic Appliance Server, OXE-MS ou des fichiers iso OST. L'installation
du système d'exploitation SLES commence après la sélection du produit correspondant dans le
menu.
• Via S.O.T. : une fois que la machine hôte (physique ou virtuelle) a démarré, elle se connecte au site
S.O.T. et charge le bootDVD et le logiciel du produit. L'installation du système d'exploitation SLES
démarre automatiquement sur la machine virtuelle.
Les versions du bootDVD sortent régulièrement avec de nouvelles fonctionnalités, de nouveaux
produits, des correctifs de bogues et/ou de sécurité. Des informations sont fournies sur le portail
commercial Alcatel-Lucent Enterprise.
Il est important de vérifier les compatibilités entre la version du bootDVD et le produit en question. Pour
plus de détails, reportez-vous aux notes de version du produit à installer.
Le système d'exploitation SLES déployé pour un produit peut également être mis à jour depuis la
machine hôte, ou depuis le réseau via S.O.T. : voir Mise à jour du système d'exploitation du produit
(bootDVD uniquement) à la page 413.
Cette procédure de mise à jour s'applique à tous les produits gérés par le bootDVD. Dans une
implémentation typique, cette opération n'est pas obligatoire, mais est recommandée pour des raisons
de sécurité.
Pour une nouvelle installation, utilisez le dernier bootDVD trouvé sur le portail commercial Alcatel-
Lucent Enterprise.
Le mot de passe racine par défaut est letacla1. Il doit être modifié lors de la première connexion. Le
mot de passe doit respecter la règle suivante : être composé de 6 à 8 caractères au minimum, avec au
moins un chiffre (de 0 à 9), une minuscule et un caractère spécial (signe de ponctuation).
Les figures suivantes présentent les menus proposés après démarrage sur le bootDVD. Ils peuvent
varier en cas d'ajout de nouveaux produits ou de modification des menus. Seule la section OmniPCX
Enterprise est affichée.
Figure 5.3 : Exemple de page de menu du BootDVD pour les produits OmniPCX Enterprise
6 Lancement du logiciel du
Communication Server
Les versions logicielles du Communication Server sont livrées sous forme de fichiers iso et peuvent
être téléchargées à partir du portail professionnel Alcatel-Lucent Enterprise.
Une version logicielle comprend les éléments suivants :
• Système d'exploitation Linux
• Paquet swinst
• des binaires pour la partie téléphone,
• éventuellement des mises à jour pour Linux, swinst et le téléphone.
Les mises à jour sont contenues dans des patches. Un patch pourra regrouper une ou plusieurs
mises à jour.
Certaines de ces mises à jour sont appelées patchs dynamiques. Ces patchs comportent des
binaires pour le téléphone ainsi qu’une procédure qui en plus d’installer les fichiers sur disque, les
installe aussi en mémoire, ce qui évite de redémarrer le système. Cette procédure est intéressante
pour une installation de patch sur un site en service.
Les versions logicielles disponibles sur Alcatel-Lucent Enterprise ont l'arborescence suivante :
• sous la racine, un répertoire dhs3mgr
• un (ou plusieurs) sous-répertoire(s) contenant les noms de version.
Exemple :
\dhs3mgr\<release (version) name, or static or dynamic patch name>\...
Un fichier readme est inclus avec les patchs. Il se trouve dans / dhs3mgr/<patch or dynamic
patch name>. Ce fichier résume les corrections, avec libellés (en anglais la plupart du temps) ainsi
que numéros et rapports d'anomalies. Ce fichier décrit aussi les binaires modifiés (un champ new
identifie chacun de ces binaires). Tous les patchs précédents de la version standard complète sont
listés : les fichiers Readme antérieures ne sont de ce fait pas nécessaires. Le dernier fichier récapitule
tous les autres.
Attention :
Ce document ne traite pas de l’installation manuelle de binaires de téléphone (opération sans formatage
du disque, où le système d'exploitation et les données client sont conservés). Ce type d'installation
s'effectue à l'aide de swinst (voir : document 8AL91011FRBA), et est utile notamment lorsque l’on veut
mettre à jour une version ou ajouter un patch (statique ou dynamique).
6.1 Linux
Les versions complètes de Linux se trouvent dans : \dhs3mgr\<version>\pcmao\boot_res
\bootp\linux\ suivi du numéro de version.
La version complète de Linux est identifiée au moyen d'un numéro se terminant par trois zéros (par
exemple : 106.000).
Pour obtenir le numéro de version, utilisez la commande sysload version.
Les mises à jour se trouvent dans : \dhs3mgr\<version>\pkglinux\linux" and "\dhs3mgr
\<version>\pkglinux\RPMS.
Pour identifier la version de mise à jour, voir le fichier lx_version-[version]..
6.2 Swinst
Swinst est un paquet qui est livré dans la version complète Linux. Il peut aussi être re-livré en tant que
mise à niveau dans des versions complètes d'applications téléphoniques ou pour des patchs statiques
ou même dynamiques. Son installation se fait téléphone démarré ou non. Il ne s'installe pas seul (sauf
cas exceptionnel) car il fait toujours partie d'une livraison de Linux ou de patch(s) téléphonique(s) et
s'installe donc en même temps que ceux-ci.
Il est toujours inclus dans le répertoire \dhs3mgr\<version>\pkglinux\facil.
Le numéro de version figure dans le nom (par exemple swinst-2.14.0-4alc.i386.rpm pour la
version 2.14.0).
Pour identifier la version installée sur disque, connectez-vous avec le compte swinst : le numéro de
version s'affiche dans l'en-tête des menus.
Pour plus d'informations sur les fonctionnalités du menu swinst, voir : document 8AL91011FRBA.
6.3 Patchs
Les patchs téléphoniques arrivent sous forme d'un fichier de type cpiofile (fichier compacté Unix)
qui se situe dans le répertoire \dhs3mgr\<version>\dhs3linux (exemple : \dhs3mgr
\e1604\dhs3linux\comm\cpiofile).
Le répertoire comm contient la majorité des binaires. Pour les binaires spécifiques aux pays, le fichier
cpiofile se trouve au même niveau d’arborescence mais dans un répertoire nommé selon la norme
internationale (exemple : es pour l'Espagne, ch pour la Suisse, etc.).
Les patchs Linux et swinst sont fournis sous forme de paquets de type "RPM" ("Red hat Package
Manager" : standard pour les versions Mandrake, Suse et Red Hat). Ces fichiers installables
contiennent des binaires ainsi que des scripts d'installation pour diverses fonctionnalités liées au
système d'exploitation (exemple : package dhcp_a4400-2.1.17-1oxe.i386.rpm pour dhcp …).
Le premier fichier sert lors de l'installation d'une version complète en mode standard (voir Installation
sur partition active à la page 118) : pour un patch statique, il donne le nom de la version complète
associée au patch. Le second fichier donne la version du patch : un nombre commençant par "1".
• Le nom d'un patch statique est généralement constitué par le nom de la version complète suivi du
numéro de patch.
• Chaque nouveau patch statique reprend forcement les corrections de tous les précédents.
• Pour identifier la version installée sur disque, utilisez la commande siteid.
• Certains patchs nécessitent un redémarrage complet : c’est le cas lorsque l’on a installé une
nouvelle version de Linux par exemple. À la fin de l'installation par swinst, un message système
est émis, demandant de procéder au redémarrage de la machine.
7 Partitionnement du Communication
Server
À l'installation, le disque dur du Communicaton Server comporte deux parties distinctes. La première
reçoit la version active de l'application et la seconde offre suffisamment de place pour contenir une
version inactive de l'application téléphonique.
Ceci permet d'installer une version de l'application sur la partie inactive du disque sans perturber le
fonctionnement du téléphone.
Serveur de
communications
Terminaux de
Version active téléphonie
Version inactive
7.1 Description
Lors du formatage d’un disque dur, il existe des partitions créées en vue d’accueillir une deuxième
version du Communication Server.
Cela permet de réaliser une mise à jour de version tout en conservant la version actuelle, de minimiser
le temps d’indisponibilité du téléphone et d’éviter les manipulations de disque dur.
Cette opération se réalise téléphone démarré ou arrêté. Un téléphone éteint ne procure aucun
avantage. Un téléphone en fonctionnement n'a pas d'impact sur les utilisateurs : les opérations
effectuées dans le système de fichiers n'affectent en aucun cas le traitement d'appels.
L’utilisation du bi-partitionnement n’est possible que si les tailles de toutes les partitions sont
conservées. C’est à dire si le nouveau Linux, en cas d’installation standard, formatte toutes les
partitions à la même taille que celle de la version à mettre à jour. Dans le cas contraire, il faudra
procéder par installation standard (avec reformatage. On ne conserve plus l’ancienne version).
On parlera d’une manière générale de la partition bis bien qu’il y ait en fait plusieurs partitions
dupliquées. La nouvelle version à installer peut contenir un nouveau Linux (mise à jour ou version
majeure) ou uniquement des binaires de téléphone (c’est à dire une version complète ou des patchs).
La version actuelle est dite présente sur la partition active. La nouvelle version est installée sur la
partition dite inactive. La version à installer sur la partition inactive doit être supérieure ou égale à la
version qui s'exécute actuellement sur la partition active.
La base de données est dupliquée sur une des partitions inactives. Elle peut être traduite par swinst
avant la prise en compte de la nouvelle version ou après. La traduction est aussi automatique au
lancement du téléphone si l’on ne l’a pas faite auparavant.
Après installation sur la partition inactive, l’opération de passage sur la nouvelle version s’appelle un
« basculement ». Elle est déclenchée manuellement. Des opérations sont alors réalisées sur les
différents systèmes de fichiers et un redémarrage est exécuté. La nouvelle version passe alors sur la
nouvelle partition active.
Toutes les partitions ne sont pas dupliquées. Certaines resteront communes quel que soit l’état avant
ou après un basculement (voir Structure à la page 115).
Les partitions « bis » sont invisibles pour l’utilisateur. Une fois que l’on est passé sur la nouvelle
version, on n’a pas à se préoccuper des chemins pour les fichiers et les autres opérations : la syntaxe
reste identique. Tout cela est caché pour l’utilisateur car un mécanisme de liens Unix est utilisé pour
cette fonctionnalité.
La méthode de bi-partition est aussi utilisée par l’application « chargement à distance ». Cette
application permet aussi d’installer un Communication Server (à distance ou même en local).
7.2 Structure
Principaux systèmes de fichiers communs :
/dev/hda9 on /usr4 type ext2 (rw) contient la taxation, l'observation de trafic et divers fi-
chiers de traces…
8 Installation du Communication
Server sur une machine physique
(*)
: l'installation "manuelle" s'effectue avec swinst via le menu : 2 Expert menu > 9 Remote
download > 10 Local load as distributor of ISO image/ZIP file and
installation. Pour plus d’informations, reportez-vous au document 8AL91011FRBA.
Pendant le redémarrage BIOS, le BIOS est automatiquement lancé si la version BIOS existante est
antérieure à la version installée dans /usr2/downbin
6. Lorsque le lancement est terminé, redémarrez la carte encore une fois.
La carte démarre avec le nouveau BIOS.
Attention :
Pendant le lancement, ne soumettez pas la carte à un redémarrage dur et ne coupez pas l'alimentation.
8. Lorsque les informations nécessaires ont été fournies, cliquez sur Next
La page de Configuration Project settings s'ouvre
9. Effectuez les opérations suivantes :
1. Saisissez un Project name.
2. Remplissez les autres champs avec les paramètres de réseau de la LAN du client.
Note :
Ne sélectionnez pas OVF Generation. Cette option est utilisée uniquement pour le déploiement du serveur
de communication sur machine virtuelle.
Champ Signification
CPU IP address Entrez l'adresse IP du serveur de communication.
Dans une duplication de serveur de communication (redondance
locale ), ce champ doit être complété avec l'adresse IP principale,
qui est identique pour les deux serveurs de communication.
Dans une redondance spatiale, ce champ doit être complété
avec les adresses IP principales des deux serveurs de communi-
cation.
Note :
La redondance spatiale est un serveur de communication dupliqué où
les deux serveurs de communication se trouvent dans des sous-réseaux
IP distincts.
CPU redundancy (facultatif). Dans le cas d'une configuration dupliquée, si l'installation doit
également inclure l'installation du serveur de communication
jumelé, cochez cette case et complétez la configuration avec les
paramètres du serveur de communication jumelé.
14. Si vous lancez le déploiement immédiatement en utilisant la touche Deploy, démarrez le booting
PXE sur la CPU sur laquelle le logiciel OmniPCX Enterprise doit être déployé (voir : Déploiement du
projet Communication Server (amorçage réseau) à la page 123)
• Cartes CS et CPU8 : Exécution de la commande grubboot ETHER sous le compte root Linux.
Une confirmation est demandée et la carte redémarre. La carte redémarre et ouvre
automatiquement le menu BIOS (voir : Amorçage réseau avec la commande grubboot ETHER à
la page 126)
Attention :
Après cette commande le disque dur du Communication est invalidé et nécessite un reformatage.
Le Communication Server émet une requête bootp vers l'O.O.L et l'installation du logiciel démarre
(voir : Progression de l'installation standard à la page 126).
Exemple :
Lancement de l'amorçage réseau à partir de la carte CPU7-2 :
Dans la fenêtre console, attendez l'affichage du message suivant :
......
value of DIL switch forced CPU7 2
USB Base address is FC21
No HD trace
YOU CAN strike Ctrl B to enter in BIOS monitor during several seconds
from NOW !
[Action]: Press Ctrl + B
hit [Ctrl I] for BIOS monitor!
[Action]: Press Ctrl + i
CPU7 Password or CR ?:
[Action]: Press Enter (no password)
Boot Loader Menu
1 - Load From Hdisk #0
2 - * disabled menu entry *
3 - Load From Ethernet (4400 method)
4 - Load From Hdisk #0 and Bootp
CPU7>
[Action]: Select 3
4. Dans la section Boot Option Priorities, définissez la première option de démarrage sur IBA
GE SLOT 0200 v1216
5. Allez sur l'onglet Save & exit et appuyez sur la touche Enter pour quitter le menu BIOS.
Le Communication Server émet une requête bootp vers l'O.O.L et l'installation du logiciel démarre
(voir : Progression de l'installation standard à la page 126).
• R) : aucune fonction de sécurité n'est activée. L'installateur devra restaurer les configurations de
sécurité depuis une sauvegarde.
• 0) : aucune fonction de sécurité n'est activée. Cette configuration s'applique lors de l'utilisation
d'un réseau IP de confiance.
• 1) : dans ce cas, le système demande un nouveau mot de passe pour les comptes root, swinst,
mtcl et adfexc. Ces nouveaux mots de passe doivent être conformes aux règles de création des
mots de passe. Pour plus d'informations sur les règles de création des mots de passe, voir la
section Règles de création des mots de passe du document 8AL91012FRBA. Il est à noter
que le nom du compte et le mot de passe ne peuvent pas être identiques. Par exemple : root
n'est pas un mot de passe valide pour le compte root.
De plus, le système demande d'entrer la durée de validité du mot de passe de chaque compte.
Mise à zéro, l'option « aging password » indique que cette option est désactivée pour le compte
correspondant.
• 2) : dans ce cas, le système demande de nouveaux mots de passe (comme pour 1). De plus, le
serveur de communication est isolé du réseau IP. Seuls les hôtes de confiance peuvent s'y
connecter. L'installateur peut déclarer ces hôtes de confiance plus tard, via l'outil netadmin.
• 3) : dans ce cas, le système demande de nouveaux mots de passe (comme pour 1) et le serveur
de communication est isolé du réseau IP (comme pour 2). De plus, la fonction SSH est activée.
La fonction SSH crypte les appels entre machines. Pour plus d'informations sur la fonction SSH,
voir la section Sécurisation des échanges par SSH du document 8AL91012FRBA.
• Y : si la réponse est Oui, de nouveaux mots de passe/une limite de validité sont demandés (comme
pour 1), le serveur de communication est isolé du réseau IP (comme pour 2) et la fonction SSH est
activée (comme pour 3).
Une fois le niveau de sécurité choisi, la configuration de sécurité s'affiche.
Par exemple :
Security configuration:
[+] Default password changed.
[+] Aging password configured.
[+] Isolation from ethernet (trusted host TO
BE configured).
[-] The SSH security is currently NOT set.
Il est fortement recommandé de modifier les mots de passe pour tous les comptes utilisateurs du
serveur de communication, ainsi que les mots de passe enregistrés sur l'OmniVista 8770 à
l'installation. Les mots de passe à modifier sont ceux des comptes : root, swinst, mtcl, adfexc et client
(si ce dernier existe). Ces modifications doivent être effectuées sur tous les nœuds du réseau.
Pour plus d'informations sur les recommandations d'Alcatel-Lucent Enterprise concernant la gestion
des mots de passe, voir : Stratégie recommandée en matière de mot de passe 8AL91012FRBA.
5. Lorsque les informations nécessaires ont été fournies, cliquez sur Next
Note :
Le champ Enable autostart est grisé et est non modifiable.
7. Lorsque les informations nécessaires ont été fournies, cliquez sur Next
La page Media s'ouvre.
8. Sélectionnez le support sur lequel le progiciel OmniPCX Enterprise est disponible :
• Si le fichier est disponible sur un serveur de stockage externe (serveur NFS ou Windows) et que
vous avez déjà déclaré le chemin de stockage externe pour un autre projet, sélectionnez-le dans
la liste déroulante.
• Si le fichier est disponible sur un serveur de stockage externe et que vous n'avez pas encore
déclaré le chemin de stockage externe, déclarez le serveur de stockage externe à l'aide de l'une
des méthodes suivantes :
• Pour le serveur NFS, cochez la case NFS share et entrez le chemin de stockage NFS :
[URL NFS]:/[dossier(s) NFS]
• Pour le serveur Windows, cochez la case Windows share et entrez le chemin de stockage
Windows : //[URL du serveur Windows]:/[dossier(s) Windows]/, suivi des
informations d'identification d'un utilisateur disposant des droits d'accès au(x) dossier(s) de
stockage
• Si le fichier a été chargé sur le stockage local O.O.L, sélectionnez S.O.T. Stockage local
9. Cliquez sur Refresh medias list.
10. Sélectionnez le fichier approprié répertorié à l'écran, et cliquez sur Declare media.
11. Dans l'option OXE soft. version, sélectionnez la version du logiciel à installer : la version
complète, une version du logiciel avec un patch statique ou une version du logiciel sans patch.
9 Installation du Communication
Server sur une machine virtuel
Figure 9.1 : Exemple de duplication OmniPCX Enterprise avec duplication de serveur FlexLM
Cela ne couvre pas l'installation du système d'exploitation et des paquets KVM sur le serveur physique.
L'installation des packs virtualisation KVM nécessite le système d'exploitation SUSE Linux Enterprise
Server (SLES) 12 SP5 (ou une version supérieure). Pour installer le système d'exploitation SLES et les
paquets KVM, reportez-vous à la documentation technique du fournisseur.
Notes :
• Les paquets de virtualisation peuvent être installés soit lors de la procédure d'installation de l'hôte, soit après
celle-ci, à l'aide de la commande zypper.
• Assurez-vous que le réseau ponté a été configuré, parce que les machines virtuelles du serveur de
communication utilisent le même réseau pour l'accès LAN, et veillez également à désactiver Network Manager
pour utiliser le service réseau à sa place.
• Le fichier de licence du serveur FlexLM (extension .ice) : licence pour le serveur FlexLM pour le
dongle.
• Le fichier de licence du serveur OmniPCX Enterprise (extension .swk). Ce fichier de licence sert
pour le serveur OmniPCX Enterprise virtualisé.
Note :
Tous ces éléments sont requis pour l'installation. Si l'un de ces éléments est indisponible, arrêtez la procédure.
6. Démarrez la machine virtuelle du serveur FlexLM : faites un clic droit sur la machine virtuelle et
sélectionnez Run dans le menu contextuel.
Vérifiez que les services FlexLM sont démarrés : service flexlmd status
Vérifiez que les informations sur la licence sont disponibles :
/opt/Alcatel-Lucent/flexlm_standalone/lmutil lmstat –a
Vous avez installé et configuré avec succès le serveur FlexLM.
9.1.2.7 Installation d'un serveur FLexLM pour plusieurs serveurs OmniPCX Enterprise
virtualisés
• Cette architecture ne nécessite pas de configuration spécifique sur les serveurs OmniPCX
Enterprise ou sur le serveur FlexLM.
• Un dongle unique est utilisé.
• Plusieurs fichiers de licence (extension .ice) doivent être installés sur le serveur FlexLM.
• Plusieurs fichiers de licence (extension .swk) doivent être installés sur chaque serveur OmniPCX
Enterprise.
Une fois les fichiers de licence installés sur tous les serveurs, redémarrez le service FlexLM ou la
machine virtuelle afin que les licences soient prises en compte. Chaque serveur OmniPCX Enterprise
peut alors être enregistré sur le même serveur FlexLM.
En cas de duplication du serveur FlexLM (ce qui implique que deux adresses sont déclarées sur
chaque serveur OmniPCX Enterprise), deux dongles sont nécessaires et deux fois plus de
licences .ice doivent être installées sur les serveurs FlexLM.
Notes :
• Une fois le serveur FlexLM configuré, redémarrez l'OmniPCX Enterprise pour appliquer vos modifications.
• Si aucun serveur FlexLM ne répond au bout de cinq jours, un indicateur de situation d'urgence est émis sur le
serveur OmniPCX Enterprise, avant d'afficher Call Installer sur les postes téléphoniques.
Note :
L'indicateur en question est levé après quatre heures sans réponse du serveur FlexLM dans les versions plus
anciennes.
8. Dans l'option OXE soft. version, sélectionnez la version du logiciel à installer : la version complète,
une version du logiciel avec un patch statique ou une version du logiciel sans patch.
9. Lorsque les informations nécessaires ont été fournies, cliquez sur Next
La page de Configuration Project settings s'ouvre
10. Effectuez les opérations suivantes :
1. Saisissez un Project name.
2. Sélectionnez le champ OVF Generation si l'OmniPCX Enterprise et sa machine virtuelle doivent
être déployés sur la machine cible à l'aide d'un fichier OVF.
3. Dans le champ Network interface used, sélectionnez l'interface réseau S.O.T. utilisée pour le
déploiement du projet
4. Remplissez les autres champs avec les paramètres du client.
Champ Signification
CPU MAC address Entrez l'adresse MAC du serveur de communication
Note :
Dans le cas d'un déploiement de machine virtuelle OmniPCX Enterprise
produit avec OVF, le champ MAC address est grisé et ne peut pas être
modifié.
CPU redundancy (facultatif). Dans le cas d'une configuration dupliquée, si l'installation doit
également inclure l'installation du serveur de communication
jumelé, cochez cette case et complétez la configuration avec les
paramètres du serveur de communication jumelé.
14. Vérifiez le nom d'hôte de l'OmniPCX Enterprise ainsi que la version du logiciel et cliquez sur
Deploy
Vous pouvez également cliquer sur Save pour créer le projet et le déployer plus tard à partir du
project listing.
9.1.3.5 Déploiement de la machine virtuelle OmniPCX Enterprise sur un serveur physique KVM
Pour déployer la machine virtuelle OmniPCX Enterprise sur un serveur physique KVM :
1. À partir de la page d'accueil du serveur physique KVM, naviguez jusqu'à : Applications >
System Tools > Virtual Machine Manager pour lancer l'application Virtual Machine
Manager
La fenêtre Virtual Machine Manager s'ouvre.
2. En fonction du type de déploiement, effectuez l'une des opérations suivantes :
• Déploiement de la machine virtuelle OmniPCX Enterprise produit à l'aide d'un fichier OVF :
L'installation diffère de l'installation sur un Blade Server. Elle s'interrompt en effet après le
chargement des fichiers de configuration Linux et nécessite une intervention manuelle pour
sélectionner le type d'installation.
Figure 9.8 : Exemple de duplication OmniPCX Enterprise avec duplication de serveur FlexLM
Note :
Sautez cette opération lorsque l'attribution de licence est exécutée en utilisant Cloud Connect. Voir la rubrique
Licences dans le document 8AL91047FRAA.
Cela ne comprend pas l'installation de l'infrastructure VMware ESXi sur le serveur physique.
L'infrastructure VMware ESXi n'est pas à la charge d'Alcatel-Lucent Enterprise. Pour un bon
déploiement des machines virtuelles, l'infrastructure ESXi doit avoir été correctement installée et
configurée.
9.2.2 Installation de l'OmniPCX Enterprise sur une machine virtuelle VMware ESXi
9.2.2.1 Présentation générale
Alcatel-Lucent Enterprise recommande l'une des méthodes d'installation suivantes pour l'installation de
l'OmniPCX Enterprise sur une machine virtuelle :
• Installation de la machine virtuelle OmniPCX Enterprise via S.O.T.
• Installation de la VM OmniPCX Enterprise via l'OmniVista 8770 (utilisée pour installer l'OmniPCX
Enterprise sur une partition active)
Pour une première installation, se reporter à : Création du projet de déploiement OmniPCX Enterprise
via S.O.T. à la page 253.
informations d'identification d'un utilisateur disposant des droits d'accès au(x) dossier(s) de
stockage
• Si les fichiers ont été chargés sur le stockage local O.O.L, sélectionnez S.O.T. Stockage
local
6. Cliquez sur Refresh media list.
7. Sélectionnez les fichiers appropriés répertoriés à l'écran, et cliquez sur Declare media
8. Dans l'option OXE soft. version, sélectionnez la version du logiciel à installer : la version
complète, une version du logiciel avec un patch statique ou une version du logiciel sans patch.
9. Lorsque les informations nécessaires ont été fournies, cliquez sur Next
La page de Configuration Project settings s'ouvre
10. Effectuez les opérations suivantes :
1. Saisissez un Project name.
2. Sélectionnez le champ OVF Generation si l'OmniPCX Enterprise et sa machine virtuelle
doivent être déployés sur la machine cible à l'aide d'un fichier OVF.
3. Dans le champ Network interface used, sélectionnez l'interface réseau S.O.T. utilisée pour le
déploiement du projet
4. Remplissez les autres champs avec les paramètres du client.
Champ Signification
CPU MAC address Entrez l'adresse MAC du serveur de communication
Note :
Dans le cas d'un déploiement de machine virtuelle OmniPCX Enterprise
produit avec OVF, le champ MAC address est grisé et ne peut pas être
modifié.
CPU redundancy (facultatif). Dans le cas d'une configuration dupliquée, si l'installation doit
également inclure l'installation du serveur de communication
jumelé, cochez cette case et complétez la configuration avec les
paramètres du serveur de communication jumelé.
14. Vérifiez le nom d'hôte de l'OmniPCX Enterprise ainsi que la version du logiciel et cliquez sur
Deploy
Vous pouvez également cliquer sur Save pour créer le projet et le déployer plus tard à partir du
project listing.
Pour déployer la machine virtuelle OmniPCX Enterprise sur un serveur physique VMware :
1. Ouvrez un navigateur Web et saisissez l'URL suivante :
https://<VMware ESXi server IP address>
2. Connectez-vous avec vos identifiants d'utilisateur
La page d'inventaire de client Web vSphere s'ouvre
3. En fonction du type de déploiement, effectuez l'une des opérations suivantes :
• Déploiement de la machine virtuelle OXE-MS produit à l'aide d'un fichier OVF :
Note :
Pour sélectionner l'option Yes, cliquez une fois sur la fenêtre de la console et utilisez les flèches de défilement
pour accéder à Yes. Appuyez sur Entrée.
5. Configurez le serveur OmniPCX Enterprise en fonction de vos besoins.
Note :
Les paramètres donnés dans ces figures ont été utilisés à des fins de test.
6. À ce stade, le clavier par défaut est le clavier anglais. Si vous devez utiliser un clavier autre que le
clavier par défaut (par exemple : le clavier français ou allemand), il vous faudra d'abord modifier le
type de clavier avant de configurer l'OmniPCX Enterprise : Ouvrez une console sur la machine
virtuelle.
a) Entrez les identifiants root (login et mot de passe).
b) Saisissez la commande kbdconfig.
c) Utilisez les flèches vers le haut et vers le bas pour sélectionner le clavier correspondant, puis
appuyez sur la barre d'espace pour valider votre sélection.
7. À partir de la même session root, saisissez la commande netadmin et configurez l'adresse IP de
la machine virtuelle OmniPCX Enterprise, le masque de sous-réseau et le routeur par défaut :
• Lorsque la configuration netadmin est terminée, vous pouvez accéder à la machine virtuelle
OmniPCX Enterprise depuis le réseau.
• La configuration de la machine virtuelle OmniPCX Enterprise est similaire à la configuration
OmniPCX Enterprise standard, à l'exception du fichier de licence. La licence utilisée pour la
machine virtuelle OmniPCX Enterprise doit être identique à celle associée au fichier de licence du
serveur FlexLM, ou une requête de licence spécifique est nécessaire (fichier .swk).
• Avant de configurer le serveur FlexLM sur la machine virtuelle OmniPCX Enterprise, vérifiez que le
rôle de la machine virtuelle OmniPCX Enterprise est défini sur main.
9.2.3 Installation des outils VMware sur la machine virtuelle OmniPCX Enterprise
Il est obligatoire d'installer les outils VMware dans la machine virtuelle OmniPCX Enterprise.
La livraison de l'OmniPCX Enterprise inclut une version compatible des outils VMware (open-vm-
tools). Cependant, ALE recommande de vérifier si VMware fournit une version plus récente des outils
VMware.
Pour plus de détails sur l'installation des outils VMware, consultez le document TC2432 disponible sur
le Business Portal d'Alcatel-Lucent Enterprise : https://myportal.al-enterprise.com/alebp/s/PN/
TC2432en.
• Redondance du serveur FlexLM : permet de s'appuyer sur un second serveur FlexLM lorsque le
premier serveur FlexLM est indisponible. Les serveurs FlexLM sont indépendants. Ils fournissent
chacun le même identifiant produit.
• Redondance du serveur OmniPCX Enterprise : lorsque le serveur principal OmniPCX Enterprise
est coupé, le serveur OmniPCX Enterprise de secours (qui devient le nouveau serveur principal)
assure le service d'octroi de licence avec le serveur FlexLM (vérifications, pulsations)
• Défense : pour prévenir les tentatives de fraude
La fenêtre du serveur FlexLM s'affiche pour montrer que le déploiement est en cours.
Lorsque la machine virtuelle a été créée avec succès, elle s'affiche sur le côté gauche du vSphere
client.
5. Mettez le serveur OVF FlexLM en marche. Cliquez avec le bouton droit de la souris sur le serveur
FlexLM pour afficher le menu contextuel et sélectionnez Power>Power On
18. Lorsque vous y êtes invité, entrez la commande startx pour ouvrir l'interface graphique.
19. Accédez à Applications > System tools > Settings, puis cliquez sur Date & Time.
20. Configurez l'heure et le fuseau horaire.
21. Confirmez votre saisie
Vérifiez les journaux Flexlm pour vous assurer que le service flexlmd a été démarré.
Les détails concernant la vérification de licence VM-OXE à partir du serveur FlexLM sont consignés
dans . /opt/Alcatel-Lucent/logs/flexlm/flexlm_lmlog.log
Vous avez installé et configuré avec succès le serveur OVF FlexLM.
9.2.4.6 Installation d'un serveur FLexLM pour plusieurs serveurs OmniPCX Enterprise
virtualisés
• Cette architecture ne nécessite pas de configuration spécifique sur les serveurs OmniPCX
Enterprise ou sur le serveur FlexLM.
• Un dongle unique est utilisé.
• Plusieurs fichiers de licence (extension .ice) doivent être installés sur le serveur FlexLM.
• Plusieurs fichiers de licence (extension .swk) doivent être installés sur chaque serveur OmniPCX
Enterprise.
Une fois les fichiers de licence installés sur tous les serveurs, redémarrez le service FlexLM ou la
machine virtuelle afin que les licences soient prises en compte. Chaque serveur OmniPCX Enterprise
peut alors être enregistré sur le même serveur FlexLM.
En cas de duplication du serveur FlexLM (ce qui implique que deux adresses sont déclarées sur
chaque serveur OmniPCX Enterprise), deux dongles sont nécessaires et deux fois plus de
licences .ice doivent être installées sur les serveurs FlexLM.
Note :
Une fois que vous avez configuré le serveur FlexLM, vous devez réamorcer VM-OXE pour appliquer les
modifications.
Note :
Si aucun serveur FlexLM ne répond après cinq jours, un indicateur de situation d'urgence est émis sur le serveur
OmniPCX Enterprise, avant d'afficher Call Installer sur les postes téléphoniques.
9.2.5 Annexe
9.2.5.1 Export de l'image/du modèle OVF à partir du serveur VMware ESXi
Vous devez arrêter la machine virtuelle pour exporter le modèle OVF, sinon l'option d'exportation sera
désactivée.
La machine virtuelle a été exportée avec succès via l'image/le modèle OVF.
9.2.5.2 Installation de la VM OXE (image OVF) à partir d'un ESX vers un autre ESX.
Si vous disposez de l'image/du modèle OVF d'une machine virtuelle OmniPCX Enterprise, voir
Déploiement des paquets KVM à la page 137 pour l'installation.
Sinon, référez-vous aux sections suivantes :
• Export de l'image/du modèle OVF à partir du serveur VMware ESXi à la page 182
• Déploiement des paquets KVM à la page 137
Note :
Effectuez un clic droit sur Hyper-V Manager pour l'épingler à la barre des tâches.
2. Pour vous connecter au serveur, procédez comme suit :
1. Sélectionnez : Action > Connect to Server...
2. Cliquez sur Another computer et sélectionnez Browse...
3. Cliquez sur Advanced et Find Now pour sélectionner le serveur correspondant dans la liste
disponible
Note :
L'Hyper-V Manager ne permet pas de sélectionner le serveur via son adresse IP ou son nom.
L'Hyper-V Manager se connecte au serveur et le nom du serveur (par exemple : HYPERVIBM3) est
affiché à l'écran
3. Dans le volet Actions, sélectionnez Virtual Switch Manager...
4. Assurez-vous que l'option External est sélectionnée, puis cliquez sur Create Virtual
Switch
5. Si plus d'un NIC est présent, assurez-vous que le NIC correspondant est sélectionné pour les
connexions réseau externes de la VM
• Si les fichiers sont disponibles sur un serveur de stockage externe (serveur NFS ou Windows) et
que vous avez déjà déclaré le chemin de stockage externe pour un autre projet, sélectionnez-le
dans la liste déroulante
• Si les fichiers sont disponibles sur un serveur de stockage externe et que vous n'avez pas
encore déclaré le chemin de stockage externe, déclarez le serveur de stockage externe à l'aide
de l'une des méthodes suivantes :
• Pour le serveur NFS, cochez la case NFS share et entrez le chemin de stockage NFS :
[URL NFS]:/[dossier(s) NFS]
• Pour le serveur Windows, cochez la case Windows share et entrez le chemin de stockage
Windows : //[URL du serveur Windows]:/[dossier(s) Windows]/, suivi des
informations d'identification d'un utilisateur disposant des droits d'accès au(x) dossier(s) de
stockage
• Si les fichiers ont été chargés sur le stockage local O.O.L, sélectionnez S.O.T. Stockage
local
6. Cliquez sur Refresh media list.
7. Sélectionnez les fichiers appropriés répertoriés à l'écran, et cliquez sur Declare media
8. Dans l'option OXE soft. version, sélectionnez la version du logiciel à installer : la version
complète, une version du logiciel avec un patch statique ou une version du logiciel sans patch.
9. Lorsque les informations nécessaires ont été fournies, cliquez sur Next
La page de Configuration Project settings s'ouvre
10. Effectuez les opérations suivantes :
1. Saisissez un Project name.
2. Laissez la case OVF Generation non sélectionnée
3. Dans le champ Interface réseau utilisée, sélectionnez l'interface réseau S.O.T. utilisée pour le
déploiement du projet
4. Remplissez les autres champs avec les paramètres du client.
CPU redundancy (facultatif). Dans le cas d'une configuration dupliquée, cochez cette case et
complétez les paramètres du Communication Server dupliqué.
15. Lancez l'amorçage PXE sur la machine virtuelle sur laquelle l'OXE-MS doit être installé : voir
Déploiement de la machine virtuelle OmniPCX Enterprise sur un serveur physique Hyper-V à la
page 191
Pour déployer la machine virtuelle OmniPCX Enterprise sur un serveur physique Hyper-V :
1. À partir de l'ordinateur de gestion, ouvrez Hyper-V Manager
L'accès Hyper-V Manager varie selon la version du système d'exploitation Windows déployée sur
l'ordinateur de gestion. Pour plus d'informations, reportez-vous à la documentation du fabricant.
2. Mettez la machine virtuelle sous tension à l'aide de l'une des options suivantes :
• Cliquez avec le bouton droit sur la machine virtuelle et sélectionnez Start
• Sélectionnez la machine virtuelle et sélectionnez Start dans la barre verticale Actions
La machine virtuelle effectue un démarrage réseau, se connecte au S.O.T. et charge le logiciel
OmniPCX Enterprise. L'installation de l'OmniPCX Enterprise démarre automatiquement sur la
machine virtuelle.
Surveillez la progression de l'installation de l'OmniPCX Enterprise sur la console de Hyper-V
Manager.
3. Sélectionnez Yes pour redémarrer l'OmniPCX Enterprise après la réussite de l'installation.
Note :
Pour sélectionner l'option Yes, cliquez une fois sur la fenêtre de la console et utilisez les flèches de défilement
pour accéder à Yes. Appuyez sur Entrée.
4. Configurez le serveur OmniPCX Enterprise en fonction de vos besoins.
Note :
Les paramètres donnés dans ces figures ont été utilisés à des fins de test.
5. À ce stade, le clavier par défaut est le clavier anglais. Si vous devez utiliser un clavier autre que le
clavier par défaut (par exemple : le clavier français ou allemand), il vous faudra d'abord modifier le
type de clavier avant de configurer l'OmniPCX Enterprise : Ouvrez une console sur la machine
virtuelle.
a) Entrez les identifiants root (login et mot de passe).
b) Saisissez la commande kbdconfig .
c) Utilisez les flèches vers le haut et vers le bas pour sélectionner le clavier correspondant, puis
appuyez sur la barre d'espace pour valider votre sélection.
6. À partir de la même session root, saisissez la commande netadmin et configurez l'adresse IP de
la machine virtuelle OmniPCX Enterprise, le masque de sous-réseau et le routeur par défaut :
• Lorsque la configuration netadmin est terminée, vous pouvez accéder à la machine virtuelle
OmniPCX Enterprise depuis le réseau.
• La configuration de la machine virtuelle OmniPCX Enterprise est similaire à la configuration
OmniPCX Enterprise standard, à l'exception du fichier de licence. La licence utilisée pour la
machine virtuelle OmniPCX Enterprise doit être identique à celle associée au fichier de licence du
serveur FlexLM, ou une requête de licence spécifique est nécessaire (fichier .swk).
• Avant de configurer le serveur FlexLM sur la machine virtuelle OmniPCX Enterprise, vérifiez que le
rôle de la machine virtuelle OmniPCX Enterprise est défini sur main.
Syntax Description
Get-VMNetworkAdapterVlan Ce cmdlet est utilisé pour obtenir les adaptateurs
réseau virtuels de la machine virtuelle spécifiée
(voir : Vérification de la configuration du réseau
local virtuel de la machine virtuelle à la page 196).
où :
• MUL*8B est le nom de la machine virtuelle OmniPCX Enterprise.
• 30 est le numéro VLAN défini dans l'adaptateur réseau hérité.
Attention :
L'activation ou la modification du numéro de VLAN peut entraîner une perte réseau, elle doit donc se
faire sur port V24 et non par telnet.
4. Dans une configuration dupliquée, répétez l'opération sur le second OmniPCX Enterprise
Attention :
Activez ou modifiez le numéro de VLAN manuellement sur les deux OmniPCX Enterprise. Le Copy
Setup de netadmin ne doit pas être utilisé.
5. Configurez le niveau de priorité via l'outil de configuration OmniPCX Enterprise (voir : Configuration
des paramètres 802.1p/Q dans les catégories de qualité de service IP à la page 196)
Attention :
Si 802.1p/Q n'est pas activé via netadmin, la gestion du niveau de priorité dans la Catégorie de qualité
de service IP n'est pas prise en compte.
9.3.7.3 Configuration des paramètres 802.1p/Q dans les catégories de qualité de service IP
Les paramètres 802.1p/Q (numéro VLAN et niveau de priorité) doivent être configurés dans un COS
de qualité de service IP utilisé par l'OmniPCX Enterprise ainsi que par les appareils distants
(téléphones IP et OXE-MS), lors de leur initialisation.
1. Ouvrez l'outil de configuration OmniPCX Enterprise et sélectionnez : IP > Catégorie de qualité de
service IP
2. Vérifiez/Modifiez les attributs suivants :
IP QoS COS Entrez un numéro de la catégorie de qualité de service
IP (entre 0 et 15)
Utilisation de 802.1Q Sélectionnez Oui pour activer le taggage 802.1Q
Priorité 802.1p Entrez le niveau de priorité à attribuer aux datagrammes
utilisant l'accès. Le niveau de priorité est un nombre
entre 0 et 7. La priorité 0 est la priorité la plus faible.
Cette valeur doit être définie en relation avec le
responsable réseau client.
2. Saisissez PowerShell
3. Entrez la commande PowerShell Get-VMNetworkAdapterVlan :
Cette commande PowerShell permet de configurer le réseau local virtuel sur tous les adaptateurs
réseau virtuel de la machine virtuelle spécifiée.
Note :
Des connexions réseau supplémentaires peuvent être nécessaires, en fonction de la configuration du cluster et
des exigences de l'application.
3. Configurez les paramètres des adaptateurs réseau. Par exemple, pour changer le nom et définir
l'adresse IP statique pour Heartbeat/iSCSI et le canal de synchronisation, exécutez les commandes
suivantes PowerShell :
Get-NetAdapter “Ethernet3” | Rename-NetAdapter –NewName “Sync”
Get-NetAdapter “Sync” | New-NetIPAddress –IPAddress 10.10.10.1 –PrefixLength 24
Get-NetAdapter “Ethernet4” | Rename-NetAdapter –NewName “iSCSI”
Get-NetAdapter “iSCSI” | New-NetIPAddress –IPAddress 10.10.20.1 –PrefixLength 24
Note :
Les adresses IP correspondantes doivent être configurées sur le serveur partenaire.
Le commutateur virtuel peut également être créé à l'aide de l'Hyper-V Manager (voir : Lancement et
configuration du Hyper-V Manager sur l'ordinateur à la page 185).
Note :
Le nom du commutateur virtuel doit être le même sur les deux serveurs.
Toute baie de stockage destinée à être utilisée par StarWind Virtual SAN pour stocker des images de
disque virtuel doit répondre aux exigences suivantes :
• Initialisée comme GPT
• Avoir une seule partition formatée en NTFS
• Avoir un identificateur de lecteur assigné
7. Si besoin, cliquez sur le bouton Browse puis modifiez le chemin d'installation, puis cliquez sur
Next.
La page de sélection des composants s'affiche.
Note :
Ce type d'installation est conçu pour les éditions d'OS sans interface utilisateur graphique. Le service StarWind
est le « cœur » du logiciel. Il peut créer des cibles iSCSI ainsi que partager des périphériques virtuels et
physiques. Le service peut être exploité par la console de gestion StarWind à partir de n'importe quel
ordinateur Windows ou machine virtuelle du réseau où la console de gestion StarWind est installée, ou en
utilisant le client Web de la console de gestion StarWind.
8. Sélectionnez le scénario de déploiement requis pour StarWind VSAN et cliquez sur Next.
9. Cliquez sur le bouton Browse pour sélectionner l'emplacement du raccourci du programme dans le
dossier du menu Démarrer, puis cliquez sur Next.
10. Sélectionnez l'option appropriée pour la saisie de la clé de licence, puis cliquez sur Next.
11. Cliquez sur le bouton Browse afin de localiser le fichier de licence, puis cliquez sur Next.
13. Vérifiez les paramètres d'installation. Cliquez sur Back pour effectuer un changement, ou cliquez
sur Install.
Note :
La StarWind Management Console demande l'emplacement par défaut du pool de stockage sur le serveur
connecté pour la première fois. Configurez le pool de stockage par défaut pour utiliser l'un des volumes
préparés précédemment. Tous les périphériques créés à l'aide de l'assistant Ajouter un périphérique y seront
stockés. Si un dossier de stockage alternatif pour les disques virtuels StarWind est nécessaire, il est possible
d'utiliser l'élément de menu Add Device (advanced).
5. Sélectionnez le serveur StarWind sur lequel l'appareil doit être créé et cliquez sur le bouton Add
Device (advanced) dans la barre d'outils, ou cliquez avec le bouton droit de la souris sur le
serveur StarWind.
6. Dans l'Add Device Wizard, sélectionnez Hard Disk Device, puis cliquez sur Next.
7. Sélectionnez Virtual Disk et cliquez sur Next.
8. Sélectionnez Create a new Virtual Disk, spécifiez les paramètres du dispositif StarWind
(Name, Location et Size), puis cliquez sur Next.
Note :
Il est recommandé de créer un périphérique de 1 Go pour éviter un long processus de synchronisation. Le
dimensionnement peut être étendu après la création.
9. Spécifiez les options du disque virtuel. Sélectionnez Use 4096 bytes sector size. May be
incompatible with some clients pour Microsoft Windows, puis cliquez sur Next.
10. Définissez la politique de mise en cache et la taille (en Go), puis cliquez sur Next.
Note :
La recommandation de base est d'attribuer 1 Go de mémoire cache L1 en mode Write-Back ou Write-
Through par 1 To de capacité de stockage si nécessaire. La taille du cache doit correspondre à l'ensemble de
travail de stockage des serveurs.
11. Si nécessaire, définissez les paramètres du cache Flash (emplacement et taille du SSD), puis
cliquez sur Next.
Note :
Il est recommandé de choisir une taille de cache L2 égale à 10 % de la capacité initiale du dispositif StarWind.
12. Précisez les paramètres cibles. Cochez la case Target Name pour personnaliser le nom cible,
puis cliquez sur Next.
Sinon, le nom sera automatiquement généré en fonction de l'alias cible.
13. Sélectionnez Create pour ajouter un nouvel appareil et l'attacher à la cible, puis cliquez sur Close
pour sortir de l'assistant.
14. Cliquez avec le bouton droit de la souris sur l'appareil précédemment créé et sélectionnez
Replication Manager.
15. Dans la fenêtre Replication Manager, cliquez sur l'élément du menu Add Replica.
16. Sélectionnez Synchronous "Two-Way" Replication et cliquez sur Next.
17. Spécifiez le nom d'hôte du serveur partenaire ou l'adresse IP et son numéro de port, puis cliquez
sur Next.
Le port de gestion de StarWind par défaut est 3261. Dans le cas où un autre port doit être
configuré, veuillez le saisir dans le champ Port Number.
21. Cliquez sur Change Network Settings pour sélectionner les réseaux Synchronisation et
Heartbeat pour l'appareil HA.
22. Spécifiez les interfaces pour Synchronisation et Heartbeat, puis cliquez sur OK.
Note :
Il est recommandé de configurer les canaux Heartbeat et iSCSI (dans ce document 10.10.10.xx et 10.10.20.xx)
sur les mêmes interfaces pour éviter le problème du « split brain ». Si les interfaces Synchronisation et
Heartbeat sont situées sur le même adaptateur réseau, il est recommandé d'affecter une interface Heartbeat
supplémentaire à un adaptateur séparé.
23. Cliquez sur Next.
24. Sélectionnez Synchronize from existing Device pour le mode d'initialisation de l'appareil
partenaire, puis cliquez sur Next.
25. Cliquez sur Create Replica, et cliquez sur Close pour sortir de l'assistant.
26. Répétez les étapes de création de l'appareil HA pour tous les disques virtuels qui seront utilisés
comme volumes partagés en cluster (CSV). Une fois tous les appareils créés, ils sont affichés dans
la StarWind Management Console comme suit :
Une fois l'extension terminée, la nouvelle taille de l'appareiil HA StarWind apparaît dans la StarWind
Management Console comme suit :
3. Cliquez sur le bouton Discover Portal, puis entrez 127.0.0.1 dans l'IP address or DNS
name.
Passez en revue les étapes de découverte des portails cibles sur le serveur partenaire.
Note :
Si les cibles créées ne sont pas répertoriées, vérifiez les paramètres du pare-feu du serveur StarWind ainsi
que la liste des réseaux desservis par le serveur StarWind (accédez à : StarWind Management Console >
Configuration > Network).
Sinon, vérifiez l'onglet Access Rights sur un serveur StarWind correspondant dans la StarWind
Management Console pour toute restriction en vigueur.
2. Sélectionnez la cible témoin disponible sur le serveur local et cliquez sur Connect.
3. Cochez toutes les cases, puis cliquez sur Advanced.
Note :
Il est recommandé de connecter le dispositif témoin en utilisant uniquement l'adresse IP en boucle (127.0.0.1).
Ne connectez pas la cible au dispositif témoin à partir du serveur partenaire StarWind.
5. Validez vos modifications.
6. Sélectionnez la cible CSV disponible sur le serveur local et cliquez sur Connect.
7. Cochez toutes les cases, puis cliquez sur Advanced.
15. Répétez les étapes décrites dans cette partie sur un autre serveur StarWind en spécifiant les
adresses IP locales et de canal de données correspondantes. Le résultat doit être similaire à celui
du tableau ci-dessous.
1. À partir de la fenêtre iSCSI Initiator Properties (voir : Découverte des portails cibles à la
page 221), sélectionnez l'onglet Targets.
2. Configurez la MPIO policy pour chaque cible (à l'exception de la cible témoin) avec la politique
d'équilibrage de charge de votre choix. Sélectionnez la cible localisée sur le serveur local, puis
cliquez sur le bouton Devices.
5. Pour la cible témoin, définissez sur la Load balance policy sur Failover Only.
6. Répétez les étapes précédentes pour configurer la politique MPIO pour chaque dispositif restant sur
le serveur actuel et sur le serveur partenaire.
Note :
Dans le cas de l'utilisation de la police MPIO Failover Only, vérifiez que le chemin local (127.0.0.1) est défini
sur Active, alors que la connexion du partenaire est définie sur Standby.
4. Valider la configuration en effectuant les tests de validation des clusters : sélectionnez Yes et Run
all tests (recommended), puis cliquez sur Next.
6. Assurez-vous que tous les paramètres sont corrects, puis cliquez sur Next.
Si nécessaire, utilisez le bouton Previous pour effectuer des changements.
Note :
Si la case Add all eligible storage to the cluster est cochée, l'assistant essaiera d'ajouter
automatiquement tous les disques au cluster. Le plus petit appareil sera assigné comme témoin. Il est
recommandé de désactiver cette option avant de cliquer sur Next, et d'ajouter un témoin manuellement.
Une fois la création du cluster terminée, le système affiche un rapport contenant les informations détaillées
peuvant être vérifiées en cliquant sur le bouton View Report.
3. Pour configurer le disque témoin du cluster, cliquez avec le bouton droit de la souris sur Cluster
et sélectionnez More Actions >. Configure Cluster Quorum Settings
7. À partir du Failover Cluster Manager, sous Disks, cliquez avec le bouton droit de la souris
sur Cluster Disk puis sélectionnez Add to Cluster Shared Volumes.
9. Effectuez les étapes précédentes si d'autres disques doivent être configurés dans le Failover
Cluster Manager. Le résultat (liste des disques) doit être similaire à celui du tableau ci-dessous.
2. Si le cluster Hyper-V est disponible, ajoutez des machines virtuelles : cliquez avec le bouton droit
de la souris sur la section Roles et sélectionnez Configure Role.
9. Lorsque les informations nécessaires ont été fournies, cliquez sur Next
La page de Configuration Project settings s'ouvre
10. Effectuez les opérations suivantes :
1. Saisissez un Project name.
2. Laissez le champ OVF Generation non sélectionné
3. Dans le champ Network interface used, sélectionnez l'interface réseau S.O.T. utilisée pour le
déploiement du projet
4. Remplissez les autres champs avec les paramètres du client.
Champ Signification
CPU MAC address Entrez l'adresse MAC du serveur de communication
Note :
Dans le cas d'un déploiement de machine virtuelle OmniPCX Enterprise
produit avec OVF, le champ MAC address est grisé et ne peut pas être
modifié.
CPU redundancy (facultatif). Dans le cas d'une configuration dupliquée, si l'installation doit
également inclure l'installation du serveur de communication
jumelé, cochez cette case et complétez la configuration avec les
paramètres du serveur de communication jumelé.
14. Vérifiez le nom d'hôte de l'OmniPCX Enterprise ainsi que la version du logiciel et cliquez sur
Deploy
Vous pouvez également cliquer sur Save pour créer le projet et le déployer plus tard à partir du
project listing.
15. Lancez l'amorçage du PXE sur la machine virtuelle sur laquelle l'OmniPCX Enterprise doit être
installé (voir Déploiement du site OmniPCX Enterprise sur une plateforme Nutanix AHV à la page
257)
9.4.3 Déploiement du site OmniPCX Enterprise sur une plateforme Nutanix AHV
Pour déployer le site OmniPCX Enterprise sur une plateforme Nutanix AHV :
1. Dans un navigateur Web, entrez l'URL suivante pour ouvrir l'application Nutanix Prism :
https://<adresse IP du serveur Nutanix>:9440/console/#login
2. Connectez-vous avec vos identifiants d'utilisateur
La page d'accueil Nutanix Prism s'affiche.
3. Sélectionnez la machine virtuelle créée pour le déploiement de OmniPCX Enterprise, et cliquez sur
le bouton Power on en bas à droite de la fenêtre
OXE-MS :
- Système d'exploitation Suse
- Logiciel OXE-MS
machine virtuelle
Environnement virtualisé
Serveur physique
Dans ces environnements virtualisés, il est possible de créer d'autres machines virtuelles sur le
serveur pour héberger d'autres applications (telles que l'OmniPCX Enterprise ou Alcatel-Lucent 4645
voice mail).
Machines virtuelles
OmniPCX
OXE-MS
Enterprise
Environnement virtualisé
Serveur physique
Notes :
• Une seule instance d'OXE-MS par machine virtuelle est autorisée. L'OXE-MS ne peut pas fonctionner lorsque
d'autres applications (comme OmniPCX Enterprise ou Alcatel-Lucent 4645 voice mail) sont installées sur la
même machine virtuelle
• L'OXE-MS s'exécute dans la machine virtuelle avec sa propre adresse IP.
• OXE-MS peut fonctionner avec une passerelle multimédia telle que Common Media Gateway
VM CS VM VM CS VM
principal OXE-MS1 principal OXE-MS1
Basculement
VM CS VM VM CS VM
de secours OXE-MS1 de secours OXE-MS1
: Liaison IP
10.1.1.5 Sécurité
Flux de signalisation
chiffrement via DTLS
LAN
• La solution KVM comprend un système d'exploitation Suse Linux Enterprise, une couche de
virtualisation KVM et des packages KVM. L'installation des packs de virtualisation KVM nécessite le
système d'exploitation Suse Linux Enterprise en tant que système d'exploitation.
• Les paquets de virtualisation peuvent être installés soit lors de la procédure d'installation de l'hôte, soit
après celle-ci, à l'aide de la commande zypper et de Suse network.
• Assurez-vous que le réseau ponté a été configuré, parce que le serveur de communication et les
machines virtuelles OXE-MS utilisent le même réseau pour l'accès LAN, et veillez également à
désactiver Network Manager pour utiliser le service réseau à sa place.
• En cas de solution VMware : la version doit être 5.5 ou ultérieure.
• Les outils de gestion de la virtualisation ont démarré :
• Pour la solution KVM : utilisez l'application Virtual Machine Manager disponible dans les
packages KVM installés avec la solution KVM sur le serveur physique.
• Pour la solution VMware : utilisez le client Web vSphere (version 5.5 ou ultérieure), étant donné
qu'il s'agit du seul client permettant l'installation d'un bootdvd de SUSE 12 SP5 sur une machine
virtuelle.
• Pour la solution Hyper-V : utilisez le Hyper-V Manager
• Pour Nutanix AHV : utilisez Nutanix Prism
Pour plus de détails sur l'installation et le démarrage de l'outil de gestion de la virtualisation,
reportez-vous à la documentation technique du fabricant.
• Pour VMware, KVM ou Nutanix AHV :
• L'outil S.O.T. a démarré
Pour plus d'informations sur l'installation et le démarrage du S.O.T., voir
document 8AL90559USAF
• Si l'OXE-MS et sa machine virtuelle sont déployés sans fichier OVF, la machine virtuelle doit être
créée manuellement sur la solution de virtualisation appropriée :
• Pour KVM : voir : Création d'une machine virtuelle sur KVM à la page 428
• Pour VMware ESXi : voir TC2431 disponible sur le portail du groupe Entreprise d'Alcatel-
Lucent Enterprise : https://myportal.al-enterprise.com/alebp/s/PN/TC2431en.
• Pour Nutanix AHV : voir : Créer une machine virtuelle sur Nutanix AHV à la page 437
Danger :
• Nutanix AHV ne prend pas en charge le déploiement de machines virtuelles avec fichier OVF. La
machine virtuelle doit être créée manuellement sur Nutanix AHV.
• Après la création, la machine virtuelle doit être arrêtée avant l'installation de OXE-MS.
• Pour Hyper-V : la machine virtuelle doit être créée manuellement sur le serveur hôte : Création
d'une machine virtuelle sur Hyper-V à la page 432,
Note :
Hyper-V ne supporte pas le déploiement de machines virtuelles OXE-MS avec S.O.T..
• Progiciel OXE-MS :
• Le bootdvd comprenant le système d'exploitation SUSE Linux Enterprise Server (bootdvd-
<version>.iso)
• Le fichier logiciel OXE-MS (oms-<version>.iso)
Note :
Les fichiers bootdvd et logiciels OXE-MS sont présents dans le pack logiciel OmniPCX Enterprise disponible
sur le site Web du portail du groupe Entreprise. En cas de déploiement sur VMware, KVM ou Nutanix AHV, ils
doivent être téléchargés et déclarés dans la liste des supports sur S.O.T.
La déclaration d'OXE-MS dans le menu Shelf crée automatiquement l'OXE-MS dans le menu Media
Gateway et vice-versa.
Attention :
Ne déclarez aucune carte et aucun rack secondaire.
Max simultaneous voice gui- Entrez le nombre maximum de guides vocaux simultanés.
des
Cette valeur doit être conforme aux règles PCM. Voir la note ci-
dessous.
Max. number of 3-part confe- Entrez le nombre de conférences à 3 participants autorisées sur
rences la passerelle multimédia OXE-MS.
Valeur par défaut : 0 (valeur maximale : 40)
La passerelle multimédia OXE-MS doit être redémarrée pour que
la valeur soit prise en compte.
<= 30 3
<= 30 2 1 ou 2
<= 30 2 <= 4
<= 30 1 3 ou 4
<= 30 1 1 ou 2 <= 4
<= 30 1 <= 8
<= 30 5 ou 6
<= 30 3 ou 4 <= 4
<= 30 1 ou 2 <= 8
<= 30 <= 12
31 <= x <= 60 2
31 <= x <= 60 1 1 ou 2
31 <= x <= 60 3 ou 4
61 <= x <= 90 1
61 <= x <= 90 1 ou 2
G722 conference with OMS • No : les conférences G722 ne sont pas autorisées avec OXE-
MS (valeur par défaut)
• Yes : les conférences G722 sont autorisées avec OXE-MS
Note :
OXE-MS doit être redémarré pour que la modification de cette option
soit prise en compte
10.1.5 Installation d'OXE-MS sur une machine virtuelle KVM, VMware ou Nutanix
AHV
10.1.5.1 Création du projet de déploiement OXE-MS via S.O.T.
Pour créer un projet de déploiement du OXE-MS via S.O.T. :
1. Depuis la page d'accueil de S.O.T., sélectionnez Projects > Create project
2. Sélectionnez l'option Greenfield project.
3. Sélectionnez OMS et cliquez sur Next
La page Media s'ouvre.
4. Sélectionnez le support sur lequel les fichiers (logiciel bootdvd et OXE-MS) sont disponibles :
• Si les fichiers sont disponibles sur un serveur de stockage externe (serveur NFS ou Windows) et
que vous avez déjà déclaré le chemin de stockage externe pour un autre projet, sélectionnez-le
dans la liste déroulante
• Si les fichiers sont disponibles sur un serveur de stockage externe et que vous n'avez pas
encore déclaré le chemin de stockage externe, déclarez le serveur de stockage externe à l'aide
de l'une des méthodes suivantes :
• Pour le serveur NFS, cochez la case NFS share et entrez le chemin de stockage NFS :
[URL NFS]:/[dossier(s) NFS]
• Pour le serveur Windows, cochez la case Windows share et entrez le chemin de stockage
Windows : //[URL du serveur Windows]:/[dossier(s) Windows]/, suivi des
informations d'identification d'un utilisateur disposant des droits d'accès au(x) dossier(s) de
stockage
• Si les fichiers ont été chargés sur le stockage local O.O.L, sélectionnez S.O.T. Stockage
local
5. Cliquez sur Refresh media list.
6. Sélectionnez les fichiers appropriés répertoriés à l'écran, et cliquez sur Declare media
7. Une fois que les informations nécessaires ont été fournies, cliquez sur Next.
1. À partir de la page d'accueil du serveur physique KVM, naviguez jusqu'à : Applications >
System Tools > Virtual Machine Manager pour lancer l'application Virtual Machine
Manager
La fenêtre Virtual Machine Manager s'ouvre.
2. En fonction du type de déploiement, effectuez l'une des opérations suivantes :
• Déploiement de l'OXE-MS et de sa machine virtuelle à l'aide d'un fichier OVF :
2. À partir de la fenêtre Hyper-V Manager, cliquez avec le bouton droit de la souris et sélectionnez
Connect.
3. Montez le logiciel bootdvd dans la machine virtuelle : sélectionnez : Media > DVD drive > Insert
Disk ..., et sélectionnez le fichier iso du bootdvd (bootdvd-<version>.iso)
4. À partir de la machine virtuelle, sélectionnez : action > Start pour démarrer la machine virtuelle
La machine virtuelle effectue un démarrage réseau et lance l'installation du logiciel bootdvd.
Le menu d'installation bootdvd s'ouvre.
6. Après l'installation de bootdvd, ouvrez une session root (mot de passe : letacla1)
7. Montez le fichier iso OXE-MS dans la machine virtuelle :
1. Sélectionnez : Media > DVD drive > Insert Disk ..., et sélectionnez le fichier iso OXE-MS
2. Montez le disque dans la machine virtuelle :
# mount /dev/sr0 /media/cdrom/
3. Accédez au lecteur de DVD :
# cd /media/cdrom/
8. Copiez le fichier d'installation dans la machine virtuelle OXE-MS :
# mkdir /home/admin/oms
# cp -rf /media/cdrom/* /home/admin/oms
# cd /home/admin
# chmod -R a+x ./tmp/
9. Exécutez le script d'installation OXE-MS :
# cd /home/admin/oms
# ./oxe_media_server-launcher.bin -silent
10. Après le déploiement, complétez les paramètres d'OXE-MS(voir Configuration de l'OXE-MS à la
page 277)
11. Effacez les fichiers temporaires :
# cd /home/admin/oms
# rm *
• L'option 5. ssh server ouvre ssh pour l'utilisateur admin uniquement et seulement à partir de
l'OmniPCX Enterprise associé
Note :
Pour accéder à tout autre adresse IP, le /etc/hosts.allow doit être modifié.
• L'8. Activer/Désactiver l'option SSH permet d'activer/désactiver la connexion à distance SSH
à partir d'une machine externe (par exemple, S.O.T. application pour la mise à jour du système
d'exploitation)
Une fois l'option sélectionnée, saisissez l'adresse IP de la machine externe pour laquelle la
connexion SSH doit être activée/désactivée
8. Enregistrez et redémarrez l'OXE-MS.
9. Sur l'OmniPCX Enterprise, l'état de l'OXE-MS peut être vérifié par la commande config
<crystal number>.
Exemple :
(1)cs80> config 6
Thu Aug 14 19:24:14 CEST 2014
+-------------------------------------------------------------------+
| Cr | cpl| cpl type | hw type | cpl state | coupler ID |
|----|----|------------|-----------|--------------|-----------------|
| 6 | 0 | GD4 | OXE MS | EN SERVICE | PAS DE CODE PCMS |
+-------------------------------------------------------------------+
--- Inter Crystal Topology ---
+-------------------------------------------------------------------------+
| CR | CPL Type Role Free/Tot Role Type CPL | CR |
|-------------------------------------------------------------------------|
|006 | 00 -GD4 <PRINCIPAL > --- 0/0--- < INT_A> INTIP3A - 01|019 |
|-------------------------------------------------------------------------|
(1)cs80>
L'état de l'OXE-MS peut être également vérifié par d'autres commandes OmniPCX Enterprise telles
que cplstat ou listerm.
Vous pouvez accéder à l'OXE-MS en utilisant une connexion SSH. À partir de l'invite de l'OmniPCX
Enterprise, entrez la commande suivante : ssh admin@<OXE-MS adresse IP>. Un mot de
passe est demandé pour l'accès : ce mot de passe correspond à celui du compte root de
l'OmniPCX Enterprise.
Exemple :
(1)cs80>ssh admin@172.19.108.12
où :
• OMSVM est le nom de la machine virtuelle OmniPCX Enterprise.
• 30 est le numéro VLAN défini dans l'adaptateur réseau hérité.
• Les paquets de virtualisation peuvent être installés soit lors de la procédure d'installation de l'hôte, soit
après celle-ci, à l'aide de la commande zypper et de Suse network.
• Assurez-vous que le réseau ponté a été configuré, parce que le serveur de communication et les
machines virtuelles OST utilisent le même réseau pour l'accès LAN, et veillez également à désactiver
Network Manager pour utiliser le service réseau à sa place.
• En cas de solution VMware : la version doit être 5.5 ou ultérieure.
• Les outils de gestion de la virtualisation ont démarré :
• Pour la solution KVM : utilisez l'application Virtual Machine Manager disponible dans les
packages KVM installés avec la solution KVM sur le serveur physique.
• Pour la solution VMware : utilisez le client Web vSphere (version 5.5 ou ultérieure), étant donné
qu'il s'agit du seul client permettant l'installation d'un bootdvd de SUSE 12 SP5 sur une machine
virtuelle.
• Pour Hyper-V : utilisez Hyper-V Manager.
• Pour Nutanix AHV : utilisez Nutanix Prism.
Pour plus de détails sur l'installation et le démarrage de l'outil de gestion de la virtualisation,
reportez-vous à la documentation technique du fabricant.
• Pour VMware, KVM ou Nutanix AHV :
• L'outil S.O.T. a démarré
Pour plus d'informations sur l'installation et le démarrage du S.O.T., voir
document 8AL90559USAF.
• Si l'OST et sa machine virtuelle sont déployés sans fichier OVF, la machine virtuelle doit être
créée manuellement sur la solution de virtualisation appropriée :
• Pour KVM : voir : Création d'une machine virtuelle sur KVM à la page 428.
• Pour VMware ESXi : voir TC2431 disponible sur le portail du groupe Entreprise d'Alcatel-
Lucent Enterprise : https://myportal.al-enterprise.com/alebp/s/PN/TC2431en.
• Pour Nutanix AHV : voir : Créer une machine virtuelle sur Nutanix AHV à la page 437
Danger :
• Nutanix AHV ne prend pas en charge le déploiement de machines virtuelles avec fichier OVF. La
machine virtuelle doit être créée manuellement sur Nutanix AHV.
• Après la création, la machine virtuelle doit être arrêtée avant l'installation de OST.
• Pour Hyper-V : la machine virtuelle doit être créée manuellement sur le serveur hôte : Création
d'une machine virtuelle sur Hyper-V à la page 432,
Note :
Hyper-V ne supporte pas le déploiement de machines virtuelles OST avec S.O.T..
• Progiciel OST :
• Le bootdvd comprenant le système d'exploitation SUSE Linux Enterprise Server (bootdvd-
<version>.iso)
• Le fichier logiciel OST (OST-<version>.iso)
Note :
Les fichiers bootdvd et logiciels OST sont présents dans le pack logiciel OmniPCX Enterprise disponible sur le
site Web du portail du groupe Entreprise. En cas de déploiement sur VMware, KVM ou Nutanix AHV, ils
doivent être téléchargés et déclarés dans la liste des supports sur S.O.T.
Attention :
La mise à jour directe de l'OST d'une version fonctionnant sur SUSE Linux Enterprise 12 SP1 vers une
version fonctionnant sur SUSE Linux Enterprise 12 SP5 (version supérieure) n'est pas autorisée. Vous
devez d'abord installer le boot SP5 et réinstaller l'OST.
10.2.3 Installation d'OST sur une machine virtuelle KVM, VMware ou Nutanix AHV
L'installation d'OST sur la machine virtuelle KVM, VMware ou Nutanix AHV est effectuée via S.O.T..
Pour installer l'OST via S.O.T. :
1. Sur la page d'accueil S.O.T., sélectionnez Projects > Create project.
2. Sélectionnez l'option Greenfield project.
3. Sélectionnez OST, puis cliquez sur Next
La page Media s'ouvre.
4. Sélectionnez le support sur lequel les fichiers (logiciel bootdvd et OST) sont disponibles et cliquez
sur Refresh media list
5. Sélectionnez les fichiers répertoriés à l'écran, et cliquez sur Declare media
6. Lorsque les informations nécessaires ont été fournies, cliquez sur Next
La pageProject settings s'ouvre
7. Saisissez un Project name.
8. Sélectionnez le champ OVF Generation si l'OST et sa machine virtuelle doivent être déployés sur
la machine cible à l'aide d'un fichier OVF (possible uniquement dans les environnements KVM et
VMware).
9. Dans le champ Network interface used, sélectionnez l'interface réseau S.O.T. utilisée pour le
déploiement du projet
10. Remplissez les autres champs avec les paramètres du client et cliquez sur Next
La page des paramètres OST s'ouvre.
11. Remplissez les champs des paramètres serveur OST
Le champ Machine type est utilisé pour sélectionner le mode de fonctionnement de la machine
virtuelle OST (EEGW ou OST64).
En cas d'utilisation d'OVF, l'adresse MAC de la machine virtuelle n'est pas nécessaire : le champ
adresse MAC est grisé.
Figure 10.50 : Exemple de page de configuration OST de la machine virtuelle pour OST64
Note :
L'accès à Hyper-V Manager varie selon la version du système d'exploitation Windows déployée sur
l'ordinateur de gestion. Pour plus d'informations, reportez-vous à la documentation du fabricant.
2. À partir de la fenêtre Hyper-V Manager, cliquez avec le bouton droit de la souris et sélectionnez
Connect.
3. Montez le logiciel bootdvd dans la machine virtuelle : sélectionnez : Media > DVD drive > Insert
Disk ..., et sélectionnez le fichier iso du bootdvd (bootdvd-<version>.iso)
4. À partir de la machine virtuelle, sélectionnez : action > Start pour démarrer la machine virtuelle
La machine virtuelle effectue un démarrage réseau et lance l'installation du logiciel bootdvd.
Le menu d'installation bootdvd s'ouvre.
6. Après l'installation de bootdvd, ouvrez une session root (mot de passe : letacla1)
7. Montez le fichier iso OST dans la machine virtuelle :
1. Sélectionnez : Media > DVD drive > Insert Disk..., et sélectionnez le fichier iso OST
2. Montez le disque dans la machine virtuelle :
# mount /dev/sr0 /media/cdrom/
3. Accédez au lecteur de DVD :
# cd /media/cdrom/
8. Copiez le fichier d'installation dans le répertoire /tmp de la machine virtuelle OST :
# cp -rf /media/cdrom/* /tmp
# cd /
# chmod -R a+x ./tmp/
9. Pour EEGW, exécutez le script d'installation suivant :
# cd /tmp
# ./egw-installer.sh
10. Pour OST64, exécutez le script d'installation suivant :
# cd /tmp
# ./ost64-installer.sh
11. Après le déploiement, complétez les paramètres d'OST (voir configuration de OST à la page 287)
12. Effacez les fichiers temporaires :
# cd /tmp
# rm ost*
# rm nsp*
# rm egw*
# rm media.inf
Les réglages de la machine virtuelle de l'OST sont affichés à l'écran. Certains champs sont remplis
automatiquement avec des informations fournies par S.O.T. (adresse IP, Masque réseau et
adresse de la passerelle).
4. Le cas échéant, sélectionnez 10. Machine Type pour vérifier le mode de fonctionnement de la
machine virtuelle OST (OST64 ou E-Gateway (External Encryption Gateway))
5. Si la machine virtuelle OST fonctionne en tant que passerelle External Encryption Gateway (E-
Gateway), vérifiez/modifiez les réglages suivants :
• sélectionnez 7. CS Physical address, puis entrez l'adresse IPv4 physique du serveur de
communication associé.
• Sélectionnez 8. CS role address, puis entrez l'adresse IPv4 du serveur de communication
associé lorsqu'il joue le rôle principal (duplication du serveur de communication).
• Sélectionnez l'option 9. IP QoS menu pour accéder aux réglages VLAN.
• L'13. Activer/Désactiver l'option SSH permet d'activer/désactiver la connexion à distance SSH
à partir d'une machine externe (par exemple, S.O.T. application pour la mise à jour du système
d'exploitation)
Une fois l'option sélectionnée, saisissez l'adresse IP de la machine externe pour laquelle la
connexion SSH doit être activée/désactivée
Les autres champs doivent être laissés vides.
Exemple d'outil de configuration pour EEGW
[root@ost ~]# ostconfig
Welcome to the OST configuration tool
-----------------------------------------------
FW version
ost_05.18_20Sep19_16h40
-----------------------------------------------
Une fois l'option sélectionnée, saisissez l'adresse IP de la machine externe pour laquelle la
connexion SSH doit être activée/désactivée
Exemple d'outil de configuration pour OST64
[root@ost ~]# ostconfig
Welcome to the OST configuration tool
-----------------------------------------------
FW version
ost_05.18_20Sep19_16h40
-----------------------------------------------
0. Exit
7. Saisissez 0 pour effectuer la modification et quitter l'outil de configuration OST.
Note :
La configuration du niveau de priorité peut également être effectuée à partir du menu OmniPCX Enterprise (voir :
Configuration des paramètres 802.1p/Q dans les catégories de qualité de service IP à la page 196).
Le Generic Appliance Server peut être commandé soit chez Alcatel-Lucent Enterprise, soit choisi
séparément à travers un revendeur. Si la commande se fait via Alcatel-Lucent Enterprise, elle peut être
pré-installée en usine.
Consultez la documentation disponible sur le portail commercial au sujet des règles liées à des
produits et offres spécifiques.
Note :
La fonction de Multi-IP configuration permettant de créer des VLAN séparés n'est pas supportée sur Generic
Appliance Server. Le serveur hôte et les machines virtuelles doivent se trouver dans le même sous-réseau IP.
Le chiffre suivant représente l'architecture déployée sur le matériel cible : une instance de l'OmniPCX
Enterprise (OXE VM), une instance du système OXE-MS (OXE-MS VM), une instance de passerelle
WebRTC (VM WebRTC) et un Flex-LM.
Virtual Machines
Flex-LM
SUSE Linux
Server
OXE Linux DEBIAN Linux
Host
Hardware
SIP Trunking
Carrier
11.1.4 Licences
11.1.4.1 Licences de l'OmniPCX Enterprise
L'ALUID est un chiffre hexadécimal à 32 chiffres associé à un serveur matériel et utilisé pour signer
tous les éléments techniques des fichiers de licence.
L'ALUID doit être déclaré dans la page eLicensing Host Registration pour finaliser le fichier de licence .
L'ALUID peut être lu après l'installation du système d'exploitation SLES, à l'aide de la
commande : /usr/bin/getaluid.
Les fichiers en lien avec la licence de l'OmniPCX Enterprise sont obtenus par le biais du portail d'e-
licence (eLP) basé sur l'ALUID de l'hôte physique.
Dans le processus d'installation, les fichiers Actis sont automatiquement recopiés sur l'OmniPCX
Enterprise.
11.1.4.2 Flex-LM
Flex-LM est un gestionnaire de licences logicielles de Flexera Software. Il est prévu pour des
environnements d'entreprise, où des licences flottantes sont mises à la disposition de plusieurs
utilisateurs finaux de logiciels.
• Generic Appliance Server a le même périmètre fonctionnel que le serveur logiciel OmniPCX
Enterprise
OXE avec OTMS y (2) Non y (2) N (1) y (2) Non y (2)
applicable applicable
OXE avec OTMS-V Cloud Connect obligatoire (voir ligne OXE + OTMS-V + Cloud)
OXE dupliqué + OTMS-V Cloud Connect obligatoire (voir ligne OXE + OTMS-V + Cloud)
7. Réglez l'option Embedded SATA Configuration sur Enable SATA AHCI Support
8. Naviguez jusqu'à : Disponibilité du service
Taille de la mémoire
Taille du disque dur
(RAM)
OXE-MS 1 Go 4 Go
Passerelle Rainbow WebRTC 2 Go 4 Go
• Les fichiers .iso qui correspondent aux applications à installer :
• Fichiers de licences pour les différents composants d'Generic Appliance Server : Licences
OmniPCX Enterprise et licences Flex-LM
• Si les fichiers de licence sont disponibles, ils doivent être placés dans : /opt/sws_lic (sws_lic
dossier à créer si indisponible) pour l'autodétection des fichiers de licence durant la post-installation
Note :
Si le serveur ne s'amorce pas sur le lecteur DVD, modifiez l'ordre d'amorçage sur le BIOS du serveur.
2. Appuyez sur F2 pour sélectionner votre langue et votre type de clavier
3. Faites défiler la liste des options d'installation et sélectionnez OmniPCX Software Package.
Le fichier AutoYaST correspondant (autoinstoxesw.xml) est affecté à Boot Options.
ou
Note :
La clé branchée dans un port USB doit être au format FAT32.
La pré-installation et la post-installation du Generic Appliance Server peuvent être réalisées soit à
partir de l'interface utilisateur graphique (GUI), soit de la console en mode silencieux.
La pré-installation et la post-installation sont masquées dans une commande unique xxxxxxx.sh.
Les opérations suivantes sont réalisées durant la procédure de pré-installation :
• Vérification de la compatibilité du matériel (disponibilité de l'espace libre, prise en charge de la
virtualisation du processeur)
• Vérification de la compatibilité du système d'exploitation de l'hôte (version du système d'explication,
prise en charge KVM)
• Copie des fichiers obligatoires (images de la machine virtuelle, scripts) sur l'hôte
• Installation de Flex-LM sur le système d'exploitation hôte
• Création d'une passerelle de réseau (br0) dans le système d'exploitation hôte afin de faciliter l'accès
de la machine virtuelle au réseau externe
Les opérations suivantes sont réalisées durant la procédure de post-installation :
• Configuration réseau
• Création d'une VM pour l'OmniPCX Enterprise et, éventuellement, d'une VM pour chaque
composant optionnel (OXE-MS et passerelle Rainbow WebRTC) avec leurs images
correspondantes
Par défaut, aucun composant optionnel (OXE-MS et/ou passerelle Rainbow WebRTC) n'est
sélectionné lors de la post-installation.
S'il n'est pas sélectionné lors de la post-installation, OXE-MS ne peut pas être installé
ultérieurement sur Generic Appliance Server. Toutefois, la passerelle Rainbow WebRTC peut être
installée ultérieurement à l'aide du fichier webrtc.bin (voir : Ajout de la passerelle Rainbow
WebRTC au Generic Appliance Server à la page 337).
• Transfert des fichiers de licence à la machine virtuelle OmniPCX Enterprise
Procédure de pré-installation
Pré-nstallation en mode silencieux
Pour réaliser la pré-installation du package du programme d'installation Generic Appliance Server :
1. Ouvrez une session sur la console du serveur comme racine.
2. Insérez le support externe contenant le fichier .iso (CD-ROM dans le lecteur ou clé USB sur un port
du serveur), ou copiez-le via SFTP.
Le support externe utilisé peut être soit un CD-ROM contenant l'image ISO, soit une clé USB avec
le fichier .iso montée sur l'hôte. La clé USB est le seul support décrit ici.
La clé USB est automatiquement montée dans /run/media/root/.
3. Démarrez l'interface graphique via la commande :
systemctl start display-manager
4. Ouvrez une session de terminal : Applications > Utilities > XTerm
5. Extrayez les fichiers d'installation (.bin) du fichier .iso à l'aide des commandes :
mkdir /root/Desktop/GASiso
mount -o loop /<directory of iso>/oxe_sws-5.04.iso /root/Desktop/GASiso/
mkdir /root/Desktop/GASinstallfiles
cp -r /root/Desktop/GASiso/ /root/Desktop/GASinstallfiles/
umount /<directory of iso>/oxe_sws-5.04.iso
rm /root/Desktop/GASiso/
//THIS FILE IS USED FOR CONFIGURING OXE SOFTWARE SERVER FOR SILENT POST-INSTALLATION
//**********************************************************************************
//Below given parameters are applicable only for SPATIAL redundancy mode
TWIN_GATEWAY_IP_ADDRESS=
TWIN_GATEWAY_NAME=
TWIN_MAIN_NAME=
TWIN_MAIN_IP_ADDRESS=
Champ Value
OXE configuration details
COUNTRY_CODE Votre code pays (exemple : FR pour la France).
Champ Value
REDUNDANCY Entrez la configuration redondante :
• NO: pas de redondance
• LOCAL : redondance locale
• SPATIAL: redondance spatiale
OMS IP ADDRESS Adresse IP OXE-MS (si le champ NUMBER OF OMS est défini sur
1)
WebRTC GW configuration details
IP Adresse IP de la passerelle Rainbow WebRTC
NETMASK Masque réseau
GATEWAY Adresse IP de la passerelle par défaut
HOSTNAME Nom d'hôte de la passerelle Rainbow WebRTC
HOSTDOMAIN Nom de domaine de la passerelle Rainbow WebRTC
Champ Value
DNS Adresse IP du serveur DNS utilisé par la passerelle Rainbow
WebRTC pour la résolution des noms
NTP Adresse IP du serveur NTP utilisé par la passerelle Rainbow
WebRTC pour la synchronisation de l'heure et de la date
PROXY Adresse du proxy utilisé par la passerelle Rainbow WebRTC pour
la communication (par exemple : http://10.2.3.252:8080/)
MPROXY Protocole utilisé pour les flux multimédia échangés par le biais du
proxy. La valeur est off, tcp ou tls
PBXID Identifiant unique de votre OmniPCX Enterprise dans
l'infrastructure Rainbow Cloud (par exemple :
PBXa1b1-2wxy-3c3d-6789-4e4f-g556-7h89-10i9)
PBX_DOMAIN Adresse IP OmniPCX Enterprise (ou nom de domaine complet ou
FQDN d'OmniPCX Enterprise en cas de redondance spatiale)
RAINBOW_DOMAIN Nom de domaine de l'infrastructure Rainbow Cloud
RAINBOW_HOST Nom d'hôte de l'infrastructure Rainbow Cloud
TURN_SERVER Adresse du serveur TURN utilisé par la passerelle Rainbow
WebRTC pour le relais du flux média (par exemple : turn-
eu1.openrainbow.com)
SSH Option permettant de se connecter à la passerelle Rainbow
WebRTC via SSH. La valeur est true ou false
Note :
• Pour plus d'informations sur les paramètres OmniPCX Enterprise, reportez-vous au chapitre sur la gestion de
netadmin dans 8AL91011FRBA.
• Pour plus d'informations sur la passerelle Rainbow WebRTC, consultez Rainbow Help Center.
Post-installation via l'interface graphique
Pour réaliser la post-installation :
1. Trouvez le fichier oxeswsposinst.bin et donnez des droits exécutables à ce fichier à l'aide de la
commande :
#./chmod +x oxeswsposinst.bin
2. Exécutez la commande :
#./oxeswsposinst.bin
3. Une fois le message de bienvenue affiché, cliquez sur le bouton Next.
4. Sur la page des paramètres locaux, sélectionnez votre code de pays (pour la base de données et le
fuseau horaire OmniPCX Enterprise)
Champ Value
PBXID Saisissez l'identifiant unique de votre OmniPCX Enterprise dans
l'infrastructure Rainbow Cloud (par exemple :
PBXa1b1-2wxy-3c3d-6789-4e4f-g556-7h89-10i9)
PBX_DOMAIN Saisissez l'adresse IP de l'OmniPCX Enterprise (ou le nom de domaine
complet ou FQDN de l'OmniPCX Enterprise en cas de redondance
spatiale)
RAINBOW_DOMAIN Saisissez le nom de domaine de l'infrastructure Rainbow Cloud Le nom
de domaine Rainbow est initialisé sur openrainbow.com. Le nom de
domaine Rainbow est initialisé sur openrainbow.com. Il s'agit de la
valeur par défaut
RAINBOW_HOST Saisissez le nom d'hôte de l'infrastructure Rainbow Cloud
MPROXY Si un proxy a été déclaré dans le champ PROXY, utilisez le menu
déroulant pour sélectionner le protocole (tcp ou tls) utilisé pour les flux
multimédia échangés via le proxy
Enable SSH Si nécessaire, cochez la case pour permettre la connexion à la
passerelle Rainbow WebRTC via SSH
Attention :
Un message d'erreur pour mémoire vive insuffisante s'affiche lors de la sélection de composants
optionnels (OXE-MS et/ou de la passerelle Rainbow WebRTC). Pour plus de détails sur les exigences
matérielles minimales (voir : Vérification du matériel, des fichiers ISO et des licences à la page 298).
10. Cliquez sur le bouton Next pour fournir les détails de la licence OXE.
En général, les fichiers de licence ont déjà été installés ou sont stockés sur un support de données.
• Lorsque les fichiers de licence sont installés : tous les fichiers doivent être copiés dans un seul
répertoire. Les fichiers aux extensions .zip, .swk, hardware.mao, software.mao, .ice sont
disponibles via le chemin : /opt/sws_lic
Les données capturées grâce aux pages post-installation sont enregistrées dans un fichier de
configuration. Le fichier de configuration est utilisé pour passer aux étapes suivantes de
configuration à l'aide des scripts :
• Configuration du réseau :
Tous les paramètres du réseau tels que OXE IP, le nom de la CPU, le numéro du réseau, les
détails du routeur, sont extraits du fichier de configuration et mis à jour dans le fichier Netadmin
afin de permettre la configuration du réseau
• Configuration de base de données vide :
Une base de données vide est créée en fonction du pays choisi au cours de la post-installation
• Configuration de la licence .
Les fichiers de licence .zip, hardware.mao, software.mao, .swk, .ice sont enregistrés dans le
répertoire OXE /usr4/BACKUP/OPS pour installation ultérieure
Le fichier .ice est enregistré dans le répertoire /opt/Alcatel-Lucent.data/licenses/ du
système d'exploitation Suse à l'usage du serveur FlexLM
• Configuration du réseau pour OXE-MS :
Les paramètres de réseau d'OXE-MS, tels que OXE-MS IP, CS IP et masque de sous-réseau
sont mis à jour dans le fichier oms.cfg pour activer la configuration du réseau dans OXE-MS
Après une configuration réussie, l'OmniPCX Enterprise démarre en même temps que l'OXE-MS.
13. À la fin de la post-installation, vérifiez l'état de l'installation affiché sur la page Install
Complete :
• En cas de réussite, cliquez sur le bouton Done.
• En cas d'échec, le message d'erreur correspondant présentant les informations du fichier journal
s'affiche, voir : Procédure de désinstallation à la page 341
Après avoir corrigé les erreurs, réessayez la procédure de post-installation.
14. Une fois l'installation terminée, vous pouvez vérifier les versions du Generic Appliance Server, des
patches, d'OXE-MS et du serveur FlexLM à partir du fichier sws_release disponible sur le
chemin /etc
15. Configurez la machine virtuelle OXE et les machines virtuelles OXE-MS
Connectez-vous aux machines virtuelles d'une des manières suivantes
• À partir d'un terminal Telnet
• À partir de la console KVM :
1. Ouvrez une session sur la console KVM
2. Démarrez l'interface graphique via la commande :
systemctl start display-manager
3. Allez à : Activities
4. Cliquez sur l'icône Show Applications puis sur l'icône Yast.
La fenêtre Administrator Settings s'affiche.
5. Sélectionnez l'icône Virtual Machine Manager.
La fenêtre Virtual Machine Manager s'ouvre pour accéder aux VM.
6. À partir de la page d'accueil Gestionnaire des machines virtuelles, ouvrez une des machines
virtuelles en cliquant sur son nom.
7. Lorsque les informations nécessaires ont été fournies, cliquez sur Next
La page de Configuration Project settings s'ouvre
8. Effectuez les opérations suivantes :
1. Saisissez un Project name.
2. Remplissez les autres champs avec les paramètres de réseau de la LAN du client.
Note :
Le champ Description n'est pas obligatoire.
13. Si vous lancez immédiatement le déploiement à l'aide du bouton Deploy, patientez environ
15 secondes pour vous assurer que S.O.T. est prêt à recevoir la requête du serveur hôte sur lequel
le logiciel Generic Appliance Server doit être déployé, puis lancez le démarrage PXE sur le serveur
hôte.
Le serveur hôte effectue un démarrage réseau, se connecte à S.O.T. et charge le bootDVD et le
logiciel Generic Appliance Server. L'installation démarre automatiquement sur le serveur hôte.
Surveillez la progression de l'installation du Generic Appliance Server à partir de l'interface de
S.O.T.
Après l'installation, un assistant de post-installation démarre sur le serveur hôte.
14. Dans la console connectée au serveur hôte, complétez les réglages des composants du Generic
Appliance Server (OmniPCX Enterprise, OXE-MS et passerelle Rainbow WebRTC)
Pour plus de détails, voir la procédure de Post-installation via l'interface graphique à la page 310 (à
partir de l'étape 3).
2. Inclusion de l'interface de liaison dans l'interface de pont par défaut (br0) à la page 326
Toute la configuration s'effectue sur le système d'exploitation hôte (SLES). Il n'y a aucun changement
de configuration sur les machines virtuelles d'IMM/ILO, de l'hyperviseur KVM et d'OXE/d'OXE-MS/de la
passerelle Rainbow WebRTC.
Note :
• Les IMM/ILO sont configurés sur le BIOS et sont liés à une carte Ethernet spécifique.
• Les VM sont déjà configurées pour utiliser l'interface br0 pour la communication.
11.6.1.2 Configuration d'une interface de liaison comprenant toutes les interfaces Ethernet
1. Depuis l'interface KVM, démarrez l'interface graphique, puis allez à : YaST2 > Network Settings
2. Sélectionnez l'onglet Overview pour accéder à la liste d'appareils Ethernet.
3. Si nécessaire, supprimez les interfaces Ethernet de l'interface pont par défaut (br0) :
1. Sélectionnez l'interface br0 et cliquez sur Edit.
2. Désélectionnez les interfaces Ethernet dans l'onglet Bridged Devices.
4. Si un appareil de liaison n'est pas disponible, cliquez sur Add et sélectionnez Bond dans le champ
Device Type, puis Next.
5. Pour la configuration IP, sélectionnez No Link and IP Setup (Bonding Slaves).
6. Sélectionnez l'onglet Bond Slaves et les périphériques Ethernet cibles à inclure dans l'interface
de liaison.
7. Vérifiez le champ Bond Driver Options présent en bas de l'onglet Bond Slaves. Il est
recommandé de définir l'option sur : mode=balanced-rr miimon=100.
11.6.1.3 Inclusion de l'interface de liaison dans l'interface de pont par défaut (br0)
1. À partir de l'outil YaST2, sélectionnez l'interface de pont br0 et cliquez sur Edit.
2. Vérifiez que le paramètre IP est correctement configuré pour l'interface de pont (statique ou
dynamique, selon les besoins).
3. Dans l'onglet Bridged Devices, sélectionnez la nouvelle interface de liaison.
4. Cliquez sur Next pour revenir à Network Settings.
5. Vérifiez les détails dans l'onglet Routing, et assurez-vous qu'une passerelle par défaut valide est
configurée pour l'interface de pont.
6. Cliquez sur OK pour enregistrer votre configuration et quittez l'outil.
L'hôte est désormais configuré avec la liaison Ethernet.
Vérifiez que la connectivité réseau n'est pas perturbée lors de la mise hors tension d'une interface
Ethernet.
Attendez la fin du redémarrage. Le marquage VLAN au niveau de l'hôte est maintenant terminé.
5. Arrêtez complètement l'OXE et les VM OXE-MS (le redémarrage ne fonctionne pas)
6. Démarrez l'OXE et les VM OXE-MS
Après l'installation réussie de l'OS SLES, en plus du compte root, le compte admin (sans droits
root) est fourni à des fins générales (p. ex. : connexion à distance). Le login pour ce compte est
admin et le mot de passe par défaut est letacla1.
L'utilisateur admin n'a pas la permission d'effectuer des opérations de l'utilisateur root telles que
l'installation/désinstallation du Generic Appliance Server, la gestion des machines virtuelles, etc. Pour
effectuer de telles opérations, cet utilisateur doit basculer sur root.
3. Lorsque vous y êtes invité, entrez le mot de passe qui sera utilisé par le client VNC pour la
connexion
Vous devrez saisir un mot de passe pour accéder à vos ordinateurs fixes.
Password:
Vérifiez :
4. Il vous est demandé d'entrer un mot de passe (facultatif), puis le nom du fichier journal s'affiche,
gas:2.log dans notre exemple
Souhaitez-vous entrer un mot de passe de visualisation seulement (y/n) ? n
Le nouveau bureau 'gas:2 (root)' est gas:2
Créer un script de démarrage par défaut /root/.nvc/xstartup
Création de la configuration par défaut /root/.vnc/.vnc/config
Démarrage des applications spécifiées dans /root/.vnc/xstartup
Le fichier journal est /root/.vnc/gas:2.log
5. Entrez les commandes suivantes pour vérifier les journaux
ll /root/.vnc/gas.phisa.com\:2.log
cat /root/.vnc/gas.phisa.com\:2.log
6. Vérifiez que la ligne suivante est présente, indiquant que le serveur VNC est activé :
vncext : A l'écoute des connexions VNC sur toutes les interfaces, port 5902
2. Saisissez l'adresse IP du site Generic Appliance Server et indiquez le port défini dans le serveur
VNC, par exemple :
10.69.201.130:2 si le port 5902 est utilisé
3. Cliquez sur Connect et entrez le mot de passe défini lors de l'activation de VNC sur Generic
Appliance Server
La connexion est établie et vous avez accès au système d'exploitation SLES sur le site Generic
Appliance Server.
Outre la connexion d'alimentation, une connexion de données relie l'onduleur à GAS. Cette liaison
fournit l'état de l'onduleur. GAS peut générer des alarmes et arrêter le système proprement lorsque les
batteries sont faibles.
Pour configurer les rapports d'état de l'onduleur, se reporter à la rubrique swinst du document
8AL91011FRBA.
UPS
GAS
Câble de signal
Note :
• Utilisez swinst pour configurer les ports. Pour plus d'informations, reportez-vous au chapitre swinst du
document 8AL91011FRBA.
• Contacter Alcatel-Lucent Enterprise pour obtenir la liste complète des onduleurs supportés par GAS.
Commande Signification
$ gasups start Démarrer les services d'onduleur sur GAS
Note :
En cas d'échec du démarrage d'une commande ou d'un service, un message
d'erreur est affiché et un journal est disponible dans le répertoire suivant :
/var/log/gasups.log
Figure 11.27 : Exemple d'un service Flex-LM hors service (aucun fichier de licence trouvé)
11.9.8 Rehosting
Il n'existe pas de commande spécifique pour réhéberger OmniPCX Enterprise, OXE-MS ou la
passerelle Rainbow WebRTC.
• Pour réhéberger l'OmniPCX Enterprise :
1. Ouvrez un terminal sur la machine virtuelle OmniPCX Enterprise
2. Saisissez les commandes : netadmin
• Pour réhéberger l'OXE-MS :
1. Ouvrez un terminal sur la machine virtuelle OXE-MS
1. Exécutez la commande :
#./webrtc.bin
L'assistant d'installation du logiciel démarre et la page d'accueil s'affiche.
L'assistant d'installation vérifie la configuration du serveur. Un message d'erreur s'affiche si une
passerelle Web RTC est déjà disponible ou si une machine virtuelle OXE n'est pas disponible.
2. Cliquez sur Next.
La page Pre-Installation Summary apparaît.
Cette page fournit des détails sur le composant à installer (passerelle WebRTC), la taille du
disque dur et le temps prévu pour l'installation.
3. Si la configuration de la passerelle WebRTC est correcte, cliquez sur Install
La pré-installation démarre. Une barre de progression vous permet de suivre la pré-installation.
Attention :
Une fois lancée, la pré-installation ne peut plus être arrêtée.
Lors de la pré-installation, les fichiers de la passerelle Rainbow WebRTC sont extraits et copiés
sur le serveur.
À la fin du processus, la page Install Complete s'affiche.
4. Cliquez sur Done pour quitter l'assistant.
Pour plus de détails sur les paramètres de la passerelle Rainbow WebRTC, voir : Post-installation
en mode silencieux à la page 307.
2. Trouvez le fichier oxeswsposinst.bin et donnez des droits exécutables à ce fichier à l'aide de la
commande :
#./chmod +x oxeswsposinst.bin
3. Saisissez la commande :
#./oxeswsposinst.bin -i Silent –f /home/OmniPCXEnterpriseSoftwareServer/
Installation_Folders/scripts/PostInstall.cfg
Le message d'état de l'installation s'affiche à l'écran à la fin de la post-installation silencieuse. Vous
pouvez également contrôler l'état de la post-installation à partir du fichier /etc/
sws_postinstall.inf.
Note :
Pour plus d'informations sur la passerelle Rainbow WebRTC, ouvrez un navigateur web et entrez l'URL suivante :
Rainbow Help Center.
Champ Value
PBX_DOMAIN Saisissez l'adresse IP de l'OmniPCX Enterprise (ou le nom de domaine
complet ou FQDN de l'OmniPCX Enterprise en cas de redondance
spatiale)
RAINBOW_DOMAIN Saisissez le nom de domaine de l'infrastructure Rainbow Cloud Le nom de
domaine Rainbow est initialisé sur openrainbow.com. Le nom de domaine
Rainbow est initialisé sur openrainbow.com. Il s'agit de la valeur par
défaut
RAINBOW_HOST Saisissez le nom d'hôte de l'infrastructure Rainbow Cloud
MPROXY Si un proxy a été déclaré dans le champ PROXY, utilisez le menu déroulant
pour sélectionner le protocole (tcp ou tls) utilisé pour les flux multimédia
échangés via le proxy
Enable SSH Si nécessaire, cochez la case pour permettre la connexion à la passerelle
Rainbow WebRTC via SSH
Attention :
Un message d'erreur pour mémoire vive insuffisante s'affiche lors de la sélection de composants
optionnels (OXE-MS et/ou de la passerelle Rainbow WebRTC). Pour plus de détails sur les exigences
matérielles minimales (voir : Vérification du matériel, des fichiers ISO et des licences à la page 298).
5. Cliquez plusieurs fois sur Next jusqu'à ce que la page Post-installation Summary s'affiche
avec tous les réglages définis
6. Si les réglages sont corrects, cliquez sur Install pour démarrer la configuration.
La post-installation démarre. Une barre de progression vous permet de suivre la post-installation.
7. À la fin de la post-installation, vérifiez l'état de l'installation affiché sur la page Install Complete
et cliquez sur Done
12 Configuration du Communication
server
Principal Veille
Sous-réseau IP A Sous-réseau IP B
Routeur A Routeur B
Réseau IP
Figure 12.30 : Communication Server sur Generic Appliance Server sur des sous-réseaux IP différents
Principal Veille
Routeur A Routeur B
Réseau IP
Figure 12.31 : Mise à jour et dialogue « keep alive » entre les deux Com Servers
Sous-réseau IP
Routeur Réseau IP
Figure 12.32 : Communication Servers sur cartes CPU, dans une alvéole Crystal 14 positions
Premier cas :
Surveillance et mise à
Serveur Com
jour sur liaison C1
principal Serveur Com en veille
Sous-réseau IP
Second cas :
Surveillance sur
Serveur Com
liaison C1
principal Serveur Com en veille
Alvéole Crystal à 14
emplacements
Figure 12.33 : Surveillance et mise à jour entre les deux Com Servers
• Sur hardware Crystal, le Com Server qui démarre le premier prend la position main et fournit
l'horloge.
Lorsque le Com Server stand-by devient joignable, il faut rétablir la cohérence des deux bases de
données via une opération de clonage de base de données (voir Assurer la cohérence des bases
de données par une opération de clonage à la page 362).
Les informations gérées par les commandes MAO sont les suivantes :
• Connexion/déconnexion de l'agent (Alcatel-Lucent OmniTouch Contact Center - Standard Edition)
• Configuration des paramètres définis (code secret, langue, nom d'utilisateur, touches, etc.). Cela
s'applique aux postes numériques et sans fil
• État du poste (mise en service ou hors service)
• Service inter phonie
• Application Hôtel/Hôpital
• Configuration des paramètres opérateur (et groupes opérateur)
• Configuration des paramètres d'entité
• Configuration des CDT (Call Distribution Tables)
Notes :
• Les informations sur le stockage des commandes MAO sont enregistrées dans un fichier journal iplink.log
(voir : Fichier journal lié au stockage des commandes MAO à la page 367).
• Le Com Server main ne stocke pas les commandes MAO en mode autonome.
• Cette fonction est uniquement disponible pour les Com Servers sur cartes CS-2/CS-3 (matériel commun),
serveurs Generic Appliance Server et Blade Centers.
12.1.3.4 Cas particulier du double Main (hardware commun et Generic Appliance Server
uniquement)
Il est possible que le dialogue “keep alive” soit interrompu pour un problème réseau comme le montre
la figure ci dessous :
Principal Principal
Serveur Com A Serveur Com B
Réseau IP
Routeur 1 Routeur 2
Les Com Servers ne peuvent plus dialoguer, par contre chacun peut accéder à certaines Media
Gateway. Les deux Com Server se croient seuls et prennent tous les deux le rôle Main.
Les communications sont possibles à partir de chacune des Media Gateway (dans la mesure des
capacités du réseau IP défaillant).
Une Media Gateway dite "Media Gateway de référence" peut être configurée (voir : Définition de la
Media Gateway de référence à la page 361). Cette machine unique n'a rien de particulier si ce n'est
qu'elle permet de résoudre les conflits dus à ce cas particulier.
Les commandes de gestion ne sont possibles que sur le Com Server qui peut joindre la Media
Gateway de référence. Cette restriction évite les conflits de mise à jour lors du retour à la normale. Un
forçage est possible pour sortir de situations bloquées. De même les tickets de taxation sont perdus
sur le Com Server qui ne peut pas joindre la Media Gateway de référence.
Au retour à la normale (le dialogue "keep alive" est rétabli), une négociation intervient entre les Com
Servers pour définir le rôle de chaque Com Server.
La sélection du Com Server main s'effectue tel que suit :
1. Si une Media Gateway de référence a été configurée, le Com Server qui a joint la Media Gateway
de référence conserve le rôle main.
2. Si aucune Media Gateway de référence n'a été configurée, l'interrogation du Com Server main
s'applique à l'adresse IP du Com Server de préférence (voir : Configuration du serveur de
communication principal de préférence à la page 360). Le Com Server déclaré comme Com Server
de préférence conserve le rôle main.
3. Si aucune Media Gateway de référence et aucune adresse IP de Com Server de préférence n'ont
été configurées, le Com Server présentant le plus grand nombre de liaisons avec la carte GD (ou
INTIP-B) conserve le rôle main.
4. Lorsque les deux Com Server ont le même nombre de liaisons, le Com Server ayant l'adresse IP la
plus élevée a le rôle main.
L'autre Com Server et ses périphériques associés (cartes, téléphones IP, etc.) sont réinitialisés. Les
appels en cours pour ce Com Server sont interrompus. Après réinitialisation, la fonction de duplication
est activée. Deux situations peuvent se produire lorsque ce Com Server se réinitialise :
• Si aucune commande MAO n'est envoyée à ce Com Server avant qu'il ne se réinitialise, les
commandes MAO stockées dans le Com Server main ne sont pas supprimées. Une fois réinitialisé,
le Com Server prend le rôle stand-by et met à jour sa base de données avec les commandes MAO
envoyées par le Com Server main. Pour de plus amples informations, voir : Cohérence de la base
de données à la page 346.
• Si des commandes MAO sont envoyées à ce Com Server avant qu'il ne se réinitialise, les
commandes MAO stockées sur les deux Com Server sont supprimées et une alarme (439) est
déclenchée. Après la réinitialisation, une mise à jour manuelle des deux Com Server est requise
(voir Assurer la cohérence des bases de données par une opération de clonage à la page 362)
12.1.4 Transfert
Un basculement se produit dans les cas suivants :
• Sur hardware commun et Generic Appliance Server, lorsque l'activité du Com Server main est
interrompue, par exemple en raison d'une coupure de courant ou d'un problème réseau, et que le
Communication Server main s'arrête. Le dialogue « keep alive » entre les Communication Server
est interrompu et le Communication Server stand-by ne reçoit plus de messages du Com Server
main. Après temporisation, le Com Server stand-by devient main.
Note :
La temporisation peut être vérifiée dans l'administration système, mais sa valeur ne peut PAS être modifiée.
Note :
Lorsque le dialogue "keep alive" est interrompu en raison d'un problème réseau, on peut être en présence
d'une situation "double main".
• Sur du hardware Crystal, lorsqu'il y a une interruption dans le signal d'horloge transmis par le Com
Server main. Cette interruption informe le Com Server stand-by qu'il doit prendre le rôle main.
• Un Com Server qui est arrêté volontairement pour maintenance (commande shutdown ou
bascul) envoie un message "Release" au Com Server Stand-by. Le Com Server stand-by prend
immédiatement le rôle Main.
Note :
Un arrêt sur le Com Server stand-by ne provoque pas de basculement.
Pendant un basculement, l'ancien Com Server stand-by devient le Com Server main sans
redémarrage. Il doit établir une liaison IP avec tous les périphériques IP.
L'application de basculement maintient continuellement les adresses IP de tous les périphériques IP.
Lorsqu'un basculement se produit, l'application téléphonique envoie un seul message à l'application de
basculement pour démarrer le rétablissement des liaisons IP.
Comportements système pendant un basculement :
• Les appels internes en cours sont maintenus.
• Les communications établies sur des artères classiques (de type T2) sont conservées.
• Les communications établies sur des artères hybrides peuvent être conservées, en fonction du type
de l'artère hybride et de la configuration : voir Communications sur des liaisons logiques hybrides à
la page 350
• Les communications établies externes (tous types de signalisation : analogique, T0, T2, ABC, PCM,
etc.) sont maintenues.
• Les communications en cours d'établissement sont libérées.
• Les appels en cours avec des opératrices, une opératrice automatique, un IVR, la messagerie
vocale et le mode nomade sont libérés. S'il s'agit de communications extérieures, les appels sont
redistribués.
• Une conférence à 3 devient une simple communication entre l'initiateur de la conférence et le
participant qui n'était pas en conversation avant la conférence. Le troisième participant est libéré
• Les appels externes en attente sont transférés à l'opératrice (ou aux opératrices).
• Les appels internes et réseau en attente sont libérés.
• Il n'y a pas de pertes de justificatifs de taxation
• Sur hardware Crystal, les liaisons directes sur les ports V24 sont maintenues ("ou câblé''). Sur
hardware commun et Generic Appliance Server avec boîtiers Moxa, les connexions V24 sont
perdues et rétablies après temporisation
• Les nouvelles communications ne peuvent être établies qu'après le recalcul des routes X25. Cette
opération prend environ 30 secondes
12.1.4.1.1 Conditions
Une communication sur une liaison logique hybride est maintenue après le basculement d'un Com
Server, si les conditions suivantes sont remplies :
• L'option système Hybrid Link Switchover doit être activée sur le nœud sur lequel se produit le
basculement
• L'option système Hybrid Link Switchover est activée sur le nœud relié par une artère hybride vers
le noeud sur lequel se produit le basculement
• L'option système Hybrid Link Switchover est activée sur les noeuds d'extrémité (nœuds sur
lesquels se trouvent les utilisateurs ou les joncteurs prenant part à la communication)
• L'option Phone Features COS (Catégories d'exploit. tél.) des utilisateurs concernés doit permettre
l'activation de Hybrid link comm. saved if switchover
• La communication n'est pas en QSIG-GF
• La liaison logique hybride remplit les conditions détaillées : Liaisons logiques hybrides pour
lesquelles les communications sont maintenues à la page 350
• Les terminaux impliqués les communications peuvent avoir l'un des types suivants :
• TDM, IP, DECT, postes analogiques
• Extensions distantes
• de postes SIP
• Postes DECT fonctionnant avec les stations de base IP DECT
• Postes Hôtel
• Réseaux publics
12.1.4.1.2 Liaisons logiques hybrides pour lesquelles les communications sont maintenues
Les liaisons logiques hybrides pour lesquelles les communications peuvent être maintenues après un
basculement sont les suivantes :
• Liaisons logiques hybrides avec l'un des types de signalisation suivants (en mode d'accès principal
et/ou de secours):
• signalisation sur IP
• signalisation sur canal B
• signalisation dans un canal D
• Liaisons logiques hybrides sans signalisation et pointant vers un accès possédant l'un des types de
signalisation suivants :
• signalisation sur IP
• signalisation sur canal B
• signalisation dans un canal D
8 pour plus d'informations sur le canal de signalisation de secours, voir la rubrique Signalisation de
secours dans les artères hybrides du document 8AL91049FRAA
• Liaisons logiques hybrides en mode d'établissement permanent (louées mais pas commutées)
Note :
Les communications sont maintenues selon le même principe :
• Établies en mode d'accès principal et/ou de secours au moment du basculement
• Lorsqu'un débordement VPN (H.323, RNIS ou analogique) est utilisé
Les tableaux suivants montrent des exemples de liaisons logiques hybrides pour les communications
qui sont maintenues pendant un basculement :
• Les deux premiers tableaux montrent une liaison logique hybride avec plusieurs accès
• La troisième table montre les liaisons logiques hybrides vers trois nœuds différents, ne proposant
chacun qu'un seul accès
tableau 12.1 : Premier exemple de liaison logique hybride avec plusieurs accès
Numéro d'accès 1 2 3
Type de signalisation IP Sans signalisation Sans signalisation
No. accès fournis pour sig 1 1
princip
Avec signalisation de secours Non Non Non
tableau 12.2 : Deuxième exemple de liaison logique hybride avec plusieurs accès
Numéro d'accès 1 2 3
Type de signalisation IP canal D IP
Avec signalisation de Oui Oui Non
secours
Type signalisation de canal B IP
secours
tableau 12.3 : Exemple de trois liaisons logiques hybrides avec un seul accès
Numéro d'accès 1 1 1
Type de signalisation IP canal B canal D
Avec signalisation de Non Non Oui
secours
Type signalisation de IP
secours
12.1.4.1.3 Liaisons logiques hybrides pour lesquelles les communications sont libérées
Les liaisons logiques hybrides pour lesquelles les communications ne peuvent pas être maintenues
après un basculement incluent les suivantes :
• Liaisons logiques hybrides avec l'un des types de signalisation suivants sur l'un des accès (principal
ou de secours)
• QSIG - GF
• X25
• Liaisons locales hybrides
Les tableaux suivants montrent des exemples de liaisons logiques hybrides pour les communications
qui sont libérées après un basculement :
tableau 12.4 : Exemple de liaison logique hybride avec plusieurs accès, où les types de signalisation
X25 et QSIG-GF sont utilisés
Numéro d'accès 1 2 3 4
Type de IP canal B QSIG - GF canal B
signalisation
Avec signalisation Non Non Non Oui
de secours
Type signalisation X25
de secours
tableau 12.5 : Exemple de liaison logique hybride avec plusieurs accès, où le type de signalisation X25
est utilisé
Numéro d'accès 1 2 3
Type de signalisation IP canal B X25
Avec signalisation de Non Oui Oui
secours
Type signalisation de IP Sans signalisation
secours
No. accès fournis pour 1
sig de secours
Si la liaison logique hybride n'est pas rétablie avant la fin de la temporisation « état gelé » (3 minutes
par défaut), les communications concernées sont automatiquement libérées.
Le tableau suivant indique :
• La liste des combinés et des joncteurs qui peuvent passer à l'« état gelé »
• Les actions disponibles et les actions non disponibles sur les combinés
• Les actions des participants distants qui sont acceptées ou refusées
9 Toutes les touches semblent disponibles comme elles le seraient dans une situation normale. Lorsque
vous appuyez sur une touche, un combiné IP ou TDM indique que le service n'est pas disponible.
10 RE-INVITE, REFER, UPDATE, INFO sont rejeté avec le message 403 Interdit.
Un poste « gelé » n'est pas joignable et il est vu comme étant en panne. S'il est supervisé, il est vue
comme étant occupé.
Un poste qui essaie de joindre un poste « gelé » affiche le message out of service.
Lorsqu'un utilisateur essaie d'effectuer une action qui n'est pas disponible sur un poste « gelé », ce
poste « gelé » affiche le message non available service.
11 L'indication de coût est prise en compte à des fins de comptabilité mais elle n'est pas affichée sur le
poste.
12.1.5.2.1 Généralités
Les deux Communication Servers doivent :
• être installés sur des cartes CPU identiques,
• être dans la même version logicielle.
La duplication de serveur de communication est possible dans :
• sur les meubles M2, M3 et MI :
• sur rack Crystal, 14 positions, la CPU maître est en position 6, la CPU esclave est en position
10.
• sur rack Crystal, 28 positions, la CPU maître est en position 20, la CPU esclave est en position
6.
Note :
Pour plus d'informations sur la connexion des cartes CPU, voir le document 8AL91028FRBA.
• les meubles WM1. La CPU maître est en position 1, la CPU esclave en position 7. Le raccordement
des cartes CPU est identique au raccordement des cartes CPU des meubles M2/M3. Les boîtiers
CBRMA ou BRMA sont utilisés.
Le coffret VH n'est pas compatible avec la duplication CPU.
Switch
Note :
Il est recommandé d'utiliser ce lien embarqué pour faire des échanges de données de duplication (plus
sécurisés).
• un lien Ethernet externe.
Dans cette configuration, les deux Comunication Servers sont connectés au même commutateur
externe. Le lien Ethernet embarqué doit être désactivé entre les deux Communication Servers (pour
éviter les bouclages de trame).
Switch
La désactivation de la fonction Ethernet se fait en déplaçant les cavaliers des cartes CPU, comme
montré ci-dessous :
(ajouter un ca-
valier)
CPU6 X900
CP IO CP IO
U 2 U 2
Main Main Stand-by Stand-by
Les ports A et B ne sont pas en “ou câblé''. Ils sont généralement réservés pour la télémaintenance via
modem ou pour la console système.
===============================================================
| Machine type | Local interface | Name | Address |
===============================================================
| twin | Ethernet | xb000000 | 197.158.4.21 |
| local main | Ethernet | xmb000000 | 10.253.8.2 |
===============================================================
• Option 2. 'Add' : pour ajouter un Com Server twin. Le nom, l'adresse IP et le masque de
sous-réseau sont demandés.
Si le Com Server twin et le Com Server local sont sur des sous-réseaux différents, un message
invite à mettre à jour le (ou les) routeur par défaut, les routes statiques et les trusted hosts. Ce
message s'affiche après que l'adresse du masque de sous-réseau est saisie.
• Option 3. 'Update' : pour modifier le nom et/ou l'adresse IP du Com Server twin. Le nouveau
nom et la nouvelle adresse sont demandés.
Si le Com Server twin et le Com Server local sont sur des sous-réseaux différents, un message
invite à mettre à jour le (ou les) routeur par défaut, les routes statiques et les trusted hosts. Ce
message s'affiche après que l'adresse du masque de sous-réseau est saisie.
• Option 4. 'Delete' : pour supprimer le Com Server twin. Une confirmation est demandée.
3. Après avoir configuré le Com Server twin, sélectionner 0. 'Previous menu'
Note :
Pour plus d'information sur ces options, svoir la section Redondance CPU du document 8AL91011FRBA.
• Option 3. 'Update' : pour modifier l'adresse IP main des Com Server local et twin.
• Option 4. 'Delete' : pour supprimer l'adresse IP main des Com Server local et twin. Une
confirmation est demandée.
3. Après avoir configuré les adresses par rôle, sélectionner 0. 'Previous menu'
Attention :
après une configuration des adresses IP par rôle pour les Com Server twin et local, il faut rebooter
complètement pour que ces modifications soient prises en compte.
Note :
Pour plus d'information sur ces options, voir la section netadmin du document [13].
Taille Fenêtre Valeur de la fenêtre d'acquittement pour les échanges inter Com Ser-
ver.
Vérifiez que la valeur est : 1 (valeur par défaut).
Attention :
cette valeur ne doit pas être modifiée.
UDP Keep Alive Entrer la durée de la temporisation de surveillance d'une trame “Keep
Alive”.
Vérifiez que la valeur est : 1s (valeur par défaut).
Attention :
cette valeur ne doit pas être modifiée.
UDP Lost Reinit Délai avant que le dialogue inter-Com Server ne soit déclaré inter-
rompu.
Vérifiez que la valeur est : 7s (valeur par défaut).
Attention :
cette valeur ne doit pas être modifiée.
Updates storage time li- Durée limite (en minutes) au cours de laquelle le Com Server main
mit stocke des commandes MAO (utilisées pour mettre à jour sa base de
données) lorsque le Com Server stand-by n'est pas accessible. Si la
durée de stockage est définie sur la valeur 0, les commandes MAO
ne sont pas stockées lorsque le Com Server stand-by n'est pas ac-
cessible.
Valeur par défaut : 120. Cette valeur est également la valeur maxi-
mum.
3. Confirmez votre saisie
12.1.6.7.2 Assurer la cohérence des bases de données par une opération de clonage
L'outil swinst permet la mise en cohérence des Com Server. La rubrique permet la copie des
informations du Com Server twin sur le Com Server local (celui où la commande est lancée). Le
téléphone doit être arrêté sur le Com Server sur lequel on lance la commande cloning.
Le cloning peut aussi être activé par la commande mastercopy.
Chemin : swinst > 2 Expert menu > 3 Cloning & duplication operations > 1 CPU cloning
• les informations de gestion (informations entrées par mgr ou un autre outil OmniVista 4760),
• tickets de taxation,
• données CCD,
• données Linux (informations entrées par netadmin),
• données d'observation de trafic,
• fichiers Actis (verrous),
• guides vocaux.
Attention :
Lorsqu'une opération de clonage doit être effectuée, le téléphone doit être arrêté sur le Com Server
concerné.
12.1.6.10 Mise à jour d'un patch dynamique ou statique sans interruption de service
Il est possible d'utiliser le Com Server stand-by pour effectuer une mise à niveau du logiciel. Procéder
comme suit :
1. Stoppez l'application téléphonique sur le Com Server stand-by.
2. charger la nouvelle version logicielle sur ce Com Server. Un message informe le gestionnaire d'une
différence de version logicielle entre les Com Server,
3. redémarrer ce Com Server,
4. Mettez à jour les bases de données (outil swinst : Cloning databases).
5. redémarrer le téléphone sur ce Com Server.
6. Basculer sur le serveur de communication (commande bascul).
7. arrêter le téléphone sur le second Com Server,
8. charger la nouvelle version logicielle sur ce second Com Server,
9. redémarrer ce Com Server,
10. Mettez à jour les bases de données (outil swinst : Cloning databases).
Hybrid Link Switchover • True (valeur par défaut) : les communications établies sur une
artère hybride peuvent être maintenues après le basculement
d'un Com Server.
• false : les communications établies sur une artère hybride sont
libérées après le basculement d'un Com Server.
Note :
Cette option système doit être configurée de façon identique sur tous les
nœuds du réseau.
3. Validez.
Hybrid link comm. saved 1 (valeur par défaut) : une communication par artère hybride impli-
if switchover quant l'utilisateur peut être maintenue dans le cas d'un basculement.
0 : une communication par artère hybride impliquant l'utilisateur est
libérée dans le cas d'un basculement.
3. Validez.
12.1.6.11.3 Temporisations
1. Sélectionnez Installation > Temporisation
2. Renseignez les attributs suivants :
No Temporisation 374
No Temporisation 376
Unités tempo. Délai au bout duquel les messages sont envoyés (état gelé/état nor-
mal) pour garantir que les deux côtés de la liaison sont prêts pour en-
voyer/recevoir des messages.
Valeur par défaut : 30 (3 secondes).
Réservé au support technique
4. Validez.
12.1.7 Maintenance
12.1.7.1 Commande bascul
Cette commande permet de forcer le changement d'état : pour passer de l'état Main (principal) à l'état
Standby (secours) et vice-versa. Le Server Com principal reboote ; le Server Com standby prend le
rôle de Main.
Note :
le basculement n'est possible que s'il y a duplication effective des Call Server.
Redundancy State:
Texte d’information
Numéro de message système
Niveau de gravité
Lorsque le rôle du Server Com est « UNDEFINED », les incidents émis sont stockés sur ce Server
Com. Lors du passage à l'état Standby, les incidents sont transmis au Server Com Main.
Save MAO msg because Serveur Com princi- Le lien IP entre les deux Server Com est rom-
Sdby CPU is not avai- pal pu. La base de données du Server Com prin-
lable cipal a été modifié. Les messages MAO sont
stockés par le Server Com principal et trans-
mis au Server Com standby lorsqu'il redevient
disponible.
MAO is ON on the remo- Serveur Com princi- Le Server Com principal a reçu le message
te CPU pal MAO_IS_ON transmis par le Server Com
standby. En conséquence, le Server Com
standby est prêt à traiter des messages MAO
stockés par le Server Com principal.
MAO is ON on the local Server Com standby Le Server Com de secours a reçu le message
CPU MAO_IS_ON_ACK transmis par le Ser-
ver Com principal. Par conséquent, le Server
Com principal reconnaît que le Server Com
standby est prêt à traiter des messages MAO.
Le Server Com principal commence à trans-
mettre des messages MAO stockés.
Stop saving MAO msg Serveur Com princi- Le Serveur Com principal a arrêté de stocker
after X minutes pal des messages MAO au bout de X minutes,
tandis que le Server Com de secours n'était
pas joignable. Tous les messages MAO archi-
vés sont supprimés. Une mise à jour manuelle
du Server Com standby doit être exécutée.
Serveur Serveur
d'appels d'appels en
principal veille
2
IP 1
PCS1
IP
IP
PCS2
Media Gateway 1
Media Gateway 2
Passerelle
Domaine 3
externe SIP
Domaine 1
Domaine 2
Dans la Figure : Exemple de configuration d'un PCS à la page 368, lorsque le lien IP 1 est perdu, le
PCS 1 vient secourir les domaines 1 et 2. Lorsque le lien IP 2 est perdu, le PCS 2 vient secourir le
domaine 3. Lorsque les deux Call Server, main et standby, tombent, chaque PCS vient secourir les
domaines associés.
Note :
chaque PCS soit être configuré pour secourir au moins une Media Gateway.
• Les PCS peuvent être de type carte matérielle commune CS, un Generic Appliance Server ou un
Blade Server.
La configuration mémoire (RAM) d'un PCS doit être supérieure ou égale à un CS : si les UC du site
central sont des Generic Appliance Server, tous les PCS de type matériel commun doivent disposer
de 256 Mo de mémoire.
Note :
Un Generic Appliance Server peut agir sans limite comme un PCS.
La carte CS-2 d'un hardware commun peut agir sans limite comme un PCS.
La carte CS d'un hardware commun peut agir comme un PCS avec certaines limites. Cette carte peut secourir
1000 usagers et 20 passerelles média au maximum.
• Les PCS peuvent gérer 1000 domaines IP.
• Les PCS ne peuvent pas être dupliqués.
• Les PCS peuvent fonctionner en mode actif pendant un maximum de 30 jours consécutifs.
• Les domaines ne peuvent pas être secourus à la fois par un secours de lien de signalisation et un
PCS. Cependant le débordement privé vers public est possible de façon transparente.
• Il n'y a pas de tickets de taxation réseau sur un PCS.
• Certains fichiers de configuration relatifs à plusieurs fonctions ne sont pas copiés sur le PCS (voir :
Cohérence des données à la page 371)
Les équipements et services suivants ne sont pas pris en charge :
• Serveurs de fax SIP
• Messageries vocales SIP
• Serveur DHCP
• Service e-RMA
• Liaison IP de secours pour la passerelle multimédia
• Équipement IP de secours, avant udp-lost-reinit si la liaison avec le PCS a été perdue
• Services réseau ABC-F
12.2.3.1.2 Exploitation
Lorsqu'un PCS démarre, il établit une signalisation IP avec l'UC principale du Communication Server.
Cette liaison de signalisation est utilisée pour les communications entre le Communication Server et le
PCS.
• Le Communication Server envoie des ordres au PCS.
• Le PCS informe le Communication Server de son état.
Le PCS enregistre l'adresse IP physique du Communication Server principal et du Communication
Server de secours dans son fichier hosts.
Principal Veille
Routeur A Routeur B
Réseau IP
Figure 12.39 : Mise à jour et dialogue "keep alive" entre le PCS et le Communication Server
Un dialogue “keep alive” permet la surveillance mutuelle entre les Communication Server et les PCS.
Les PCS envoient en permanence des messages "keep alive" à leurs Communication Servers
associés. Les Communication Servers répondent à ces messages. Chaque échange est contrôlé par
une temporisation. Un Communication Server ou un PCS détecte l'interruption de l'échange avec
l'autre serveur lorsque la durée de validité des temporisations de contrôle est dépassée. En
conséquence, le PCS détermine l'action à entreprendre. Le PCS devient alors actif.
Note :
Cette méthode ne permet pas aux PCS de distinguer les problèmes de Communication Server des problèmes de
réseau.
• Configuration NTP
• Utilisateurs Radius
• Date, heure et fuseau horaire
• Statistiques CCD : lorsque l'option système PCSCOPY without CCD statistics est définie sur True
(sélectionnez System > Other system parameters > System parameters)
Note :
Par défaut, la valeur de l'option système est False
Ces données doivent être configurées manuellement sur chaque PCS à l'aide de netadmin ou
swinst.
12.2.3.2.1 Exploitation
Lorsque la liaison de signalisation entre un Communication Server et un PCS est perdue, le PCS
passe en mode actif :
• Une alarme est générée au niveau du Communication Server et du PCS. Elle indique que la liaison
de signalisation est perdue.
• Une autre alarme est générée au niveau du PCS pour indiquer combien de temps le PCS peut
rester en mode actif.
Pour des informations plus détaillées sur les alarmes éventuelles, voir : Alarmes à la page 390.
12.2.3.2.2 Database
Lorsqu'un PCS est en mode actif, il n'y a pas de mise à jour de la base de données du Communication
Server vers le PCS.
Attention :
La base de données du PCS peut être modifiée. Cependant, lorsque la liaison de signalisation entre le
Communication Server et le PCS est rétablie, ces modifications ne sont pas copiées vers la base de
données du Communication Server : elles sont perdues.
12.2.3.3.1.1 Processus de secours pour les cartes GD, les cartes INTIPB/IOIP, les postes IP Touch et
les combinés WLAN
Le secours des équipements fonctionne comme suit :
1. Le périphérique est en service (connecté au Communication Server principal)
2. La liaison entre le périphérique et le Communication Server principal est perdue.
3. Au bout de 7 secondes (valeur par défaut de la temporisation UDP Lost), le périphérique remarque
que la liaison est perdue.
Note :
La valeur de la temporisation UDP Lost est configurable dans le menu des paramètres IP.
Veuillez vous référer au chapitre Redondance IP du document 8AL91028FRBA et au TC1437 pour des
exemples de cas exceptionnels de modifications UDP LOST du domaine IP.
N'oubliez pas que la modification UDP LOST nécessite un redémarrage du serveur d'appel pour être prise en
compte globalement (un double basculement des serveurs d'appel n'est pas suffisant).
4. Le périphérique patiente pendant 7 secondes (valeur par défaut de la temporisation UDP Lost
Reinit) pour s'assurer que la liaison est perdue et qu'il ne s'agit pas d'un basculement entre le
Communication Server principal et le Communication Server de secours.
Note :
La valeur de la temporisation UDP Lost Reinit est configurable dans le menu des paramètres IP.
5. Au bout de 7 secondes, si le Communication Server n'est toujours pas joignable :
Dans le cas de... Alors...
une carte GD-4 la carte lance la réinitialisation logicielle et utilise l'adresse IP de secours
pour se connecter au PCS. Cette adresse est entrée de manière statique
dans la GD-4 (voir Configuration de l'adresse du PCS sur une carte GD à
la page 386).
une carte INTIPB/IOIP la carte redémarre deux fois avant d'utiliser l'adresse IP de secours pour
initialiser. Cette adresse est entrée en statique dans la carte INTIPB/IOIP
(voir : Configuration de l'adresse du PCS sur les cartes INTIP à la page
386).
une carte INT-IP3 la carte lance la réinitialisation logicielle et utilise l'adresse IP de secours
pour initialiser. Cette adresse est entrée de manière statique dans la
(type B) carte INT-IP3 (voir : Configuration de l'adresse du PCS sur les cartes
INTIP à la page 386).
un combiné IP Touch l'IP Touch redémarre, passe en mode capacité de survie et se connecte
au PCS en utilisant l'adresse IP de secours envoyée par le Communica-
tion Server à l'initialisation du poste.
Note :
Si l'option Keep RTP flow est activée, le poste ne redémarre pas tant qu'une
communication est active : le poste redémarre à la fin de la communication. Pour
plus d’informations, reportez-vous au document 8AL91024FRBA.
Note :
Les agents CCD sont déconnectés lors du basculement du Communication Server vers le PCS.
Le PCS devient ACTIF et envoie la requête REGISTER/OPTIONS pour ses propres passerelles
externes. Les appels entrants et sortants sont possibles, comme d'habitude, à partir du PCS.
12.2.3.3.2 Débordement privé vers public entre les passerelles média IP sur le même nœud
Le débordement privé vers public peut être utilisé entre un Communication Server et un PCS, ou entre
deux PCS.
Lorsqu'un IP Touch est en mode capacité de survie, il peut malgré tout contacter un autre IP Touch
appartenant à un autre domaine via le réseau RTPC. Ceci n'est possible que si ces domaines IP Touch
sont rattachés à des PCS (ou Communication Server) distincts.
Note :
Un domaine ne peut pas être secouru à la fois par une liaison de signalisation de secours et un PCS.
Table de débordement pour
N2
4202 => 155664202 N° local = 4202
N° public = 155664202
RTPC
PCS DDI TG
DDI TG
Bob
WAN N2
Marie
Domaine X
12.2.3.3.3 Exemples
Site central
Site de secours
Serveur de Serveur de
communication communication
principal de secours PCS
WAN
Domaine 3
Domaine 1 Domaine 2
WAN
PCS
PCS PCS
Domaine 1
Domaine 2 Domaine 3
Serveur de Serveur de
communication communication
principal de secours
WAN PCS2
PCS1
• Si le PCS est programmé pour se réinitialiser dans moins de deux minutes (période non
modifiable), ils ne se réinitialisent pas et restent associés au Communication Server
• Si le PCS est programmé pour se réinitialiser dans plus de deux minutes, ils se réinitialisent pour se
réassocier eux-mêmes au PCS.
Domaine 0
Serveur de
communication
Domaine 1 Domaine 2
PCS 1 PCS 2
IP local
Passerelle
Passerelle externe 0 Passerelle
externe 1 externe 2
Opérateur SIP 1
Figure 12.44 : Configuration des accès SIP pour le Communication Server et le PCS
Seul le faisceau entre le Communication Server et l'opérateur SIP doit être configuré. L'adresse IP du
PSC de la passerelle externe SIP associée doit être configurée via l'option Global address. Lorsque
l'option .Global address est utilisée, un faisceau et une passerelle SIP sont automatiquement
associés à chaque PCS ainsi qu'au Communication Server. Ceci simplifie la procédure de
configuration lorsque plusieurs PCS sont utilisés.
Domaine 0
Serveur de
communication
Liaison CS-
PCS1 en service
Domaine 1
Domaine 2
PCS 1 PCS 2
IP local
Poste appelé
Opérateur SIP 1
Poste appelant
Figure 12.45 : Appel entrant en mode normal
En cas d'appels sortants, le Communication Server achemine les appels vers le faisceau local.
Domaine 0
Serveur de
Liaison CS-PCS1 communication
hors service
Domaine 1
1 Domaine 2
PCS 1 3
PCS 2
IP local
2
Poste appelé
Opérateur SIP 1
Poste appelant
Figure 12.46 : Appel entrant en mode de secours
12.2.3.7 Services
Le certificat PCS (et sa clé privée) doit être généré sur le Communication Server et envoyé au PCS
automatiquement à une heure définie (voir : Configuration d'un PCS sur le Communication Server à la
page 383), ou manuellement via la commande pcscopy (voir : pcscopy à la page 390).
Note :
Toute la configuration FSNE doit être réalisée sur le Communication Server. Pour plus d'informations, reportez-
vous à la section FSNE du document [7].
12.2.3.7.3 Taxation
Les PCS présentent les particularités de taxation suivantes.
• Les tickets de taxation des Communication Servers ne sont pas copiés vers les PCS.
• Les tickets générés par un PCS en mode actif ne sont pas effacés après mise à jour de la base de
données.
• Après le basculement d'un PCS vers un Communication Server, les tickets de taxation et les fichiers
d'observation de trafic générés sur le PCS, lorsqu'il était en mode actif, ne sont pas copiés vers le
Communication Server.
12.2.4.2 Ports IP
Configurez le pare-feu de manière à permettre l'accès aux ports utilisés par le serveur de
communication et PCS. Pour obtenir la liste complète, reportez-vous au document [49].
Note :
Les demandes "ping" et "port inaccessible" ICMP doivent être autorisées dans les deux sens.
La base de données MAO du répertoire / copie cette base de données sur le PCS sans
DHS3dyn/BACKUP/IMMED est valide. interrompre la MAO et l'application de taxation
Type de mise à jour Peut s'appliquer aux paramètres du PCS lorsqu'ils sont
customisés.
Jour de mise à jour
Heure de mise à jour
12.2.4.5 Configuration d'une passerelle externe SIP pour le Communication Server et le PCS
Seules les options spécifiques associées au PCS sont présentées dans cette section. Pour la
configuration complète des accès SIP, voir la documentation IP-PCX.
1. Sélectionnez : SIP > SIP Ext Gateway
2. Vérifiez/Modifiez les attributs suivants :
• Dans les paramètres système, activez le débordement pour l'extension Hors service :
1. Sélectionnez Système > Autres param. système > Paramètres système
2. Vérifiez/modifiez l'attribut suivant :
Overflow on OoS Extension Sélectionnez : Oui
3. Confirmez votre saisie
12.2.5 Maintenance
12.2.5.1 Les traces
12.2.5.1.1 IPLINK
Pour afficher les traces du lien PCS :
1. Activer le champ pcs de l'outil ipltrace en tapant :
>ipltrace pcs=on
2. Utiliser l'outil traced pour afficher les traces
12.2.5.1.2.1 Trace GD
Effectuer ces 4 étapes pour obtenir la trace appropriée dans le GD :
1. Se connecter au GD.
Depuis le Call Server ou le Passive Communication Server, effectuer les opérations suivantes :
telnet « GD_IP_Address », identifiant : admin, mot de passe : admin
2. Droits racines appropriés
Saisir la commande : « su - »
3. Extraire les fichiers journaux de la mémoire. Ceci concerne les journaux depuis le dernier
redémarre.
Saisir : commande « ll » pour afficher la date de dernière modification des fichiers.
Saisir : « cd /var/log » pour accéder au répertoire /var/log.
Récupérer les fichiers du répertoire /var/log via le FTP ou les lire et copier l'objet de cette lecture
dans un fichier de sauvegarde : « messages », « mglog », « *monitor* ».
Note :
« *monitor*» désigne toutes les fichiers dont le nom comporte le terme « monitor ». Par ex. : « monitor.log » ou
« monitor2.log »
4. Extraire les fichiers journaux de la mémoire flash. Ceci concerne les journaux avant le dernier
redémarre.
Saisir : commande « ll » pour afficher la date de dernière modification des fichiers.
Saisir : « cd /mnt/flash/info » pour accéder au répertoire /mnt/flash/info.
Récupérer les fichiers du répertoire /mnt/flash via le FTP ou les lire et copier l'objet de cette lecture
dans le fichier de sauvegarde : « messages_tail.log », « messages_head.log », « *monitor* ».
Note :
« *monitor*» désigne toutes les fichiers dont le nom comporte le terme « monitor ». Par ex. : « monitor.log » ou
« monitor2.log »
12.2.5.1.3 MAO
Pour afficher les traces MAO :
12.2.5.1.4 pcscopy
Pour afficher les traces pcscopy :
1. Activer les traces pcscopy en saisissant :
>pcscopy +tr
2. Utiliser l'outil traced pour afficher les traces
Note :
Lorsque le service FSNE est activé sur le Communication Server, il est recommandé d'activer SSH sur le
Communication Server et PCS pour sécuriser le transfert de données au PCS via la commande pcscopy.
Utiliser... pour...
pcscopy mettre à jour manuellement la base de données du PCS avec celle du Call Server
Cet outil permet également de consulter le journal des opérations de copie.
Note :
avec la commande Config 0, les informations du PCS suivantes sont également affichées :
• name
• adresse IP
• état
12.2.5.2.1 pcsview
+------------------------+------------------+-------------------+---------------
PCS Nom | Adresse | État | Réinitialisation Type
|------------------------|------------------|-------------------|---------------
+------------------------+------------------+-------------------+---------------
• INACTIF: le lien de signalisation entre le PCS et le Call Server est actif et le PCS est à l'état inactif.
• ACTIVE: le lien de signalisation entre le PCS et le Call Server est hors service et le PCS devrait
être en service
• INACTIF *: le lien de signalisation entre le PCS et le Call Server est rétabli, mais le PCS est
toujours à l'état actif (le PCS redémarre à l'expiration de la temporisation).
• UNDEF: le lien de signalisation entre le PCS et le Call Server n'a jamais été établi. Le PCS n'est
pas à même de passer à l'état actif.
12.2.5.2.2 pcscopy
La commande pcscopy propose deux options :
Pcscopy
1 - PCS update
2 - PCS log file
0 - Exit
Choice [0 - 2] :
• Une mise à jour PCS : : cette option permet de synchroniser un PCS. Entrer l'adresse IP du PCS à
synchroniser. pscopy vérifie que le PCS est joignable et que sa version logicielle correspond à celle
du Call Server et envoie ensuite une archive de la base de données du Call Server au PCS. Si le
transfert échoue, la cause de l'échec est affichée.
• Fichier journal PCS :: cette option permet de voir le contenu du fichier log.pcs. Le fichier
log.pcs contient le résultat des dernières synchronisations (jusqu'à 1000 synchronisations/ 2 000
lignes).
Note :
le résultat des précédentes synchronisations est contenu dans le fichier oldlog.pcs. Les fichiers log.pcs et
oldlog.pcs sont placés dans le répertoire /usr4/mao (également accessible par le répertoire /DHS3dyn/
mao).
Seul log.pcs peut-être affiché par pcscopy.
Exemple :
2006/03/23 13:43:52 - PCS 192.40.64.27 Update => Start
2006/03/23 13:47:09 - PCS 192.40.64.27 Update => End OK
2006/03/23 14:05:51 - PCS 192.40.64.27 Update => Start
2006/03/23 14:05:52 - PCS 192.40.64.27 Update => End NOK: Bad PCS soft. release
Note :
Si vous utilisez pcscopy pour resynchroniser manuellement un PCS, l'archive de base de données est
automatiquement reconstruite sur le Communication Server (le MAO et l'application de taxation sont par
conséquent interrompus pendant la reconstruction de l'archive de la base de données.)
12.2.5.3 Alarmes
Les alarmes diffusées sur le Call Server sont mappées à un objet sur le PCS dans la topologie 4760.