NON URGENTE TEMPORAIRE DEFINITIVE

COMMUNICATION TECHNIQUE N TC0537 Ed. 01 OmniPCX Enterprise Nb de pages : 25 Date : 14-05-2004 URGENTE NON URGENTE TEMPORAIRE DEFINITIVE OBJET : PROCÉDURE TECHNIQUE DE FUSION DE Veuillez trouver ci-après la "Procédure technique de fusion de nœuds de PABX". Elle a pour but de conseiller les techniciens pour la préparation et la mise en service d'une migration d'un réseau OmniPCX 4400 en OmniPCX Enterprise R5.1 avec modification de la topologie existante. 1

PROCÉDURE TECHNIQUE DE FUSION DE OmniPCX Enterprise SOMMAIRE 1. INTRODUCTION...3 1.1 But du document... 3 1.2 Définition du processus Installed Base Leverage... 4 1.2.1 Objectif...4 1.2.2 Définition...4 1.3 Présentation du programme Fusion... 5 1.3.1 Définition...5 1.3.2 Avantages du programme...5 1.3.3 Limites et restrictions...5 2. LES CARACTÉRISTIQUES DE FUSION...6 2.1 Migration via INTIP... 6 2.2 Migration via INTOF (TDM)... 6 2.3 Caractéristiques matérielles... 7 2.4 Caractéristiques applicatives... 8 2.4.1 Messagerie vocale 4635...8 2.4.2 DECT/PWT...8 2.4.3 Outil d administration...9 2.4.4 Application OmniTouch Contact Center...10 2.4.5 Autres applications...10 2.4.6 Répercussions sur les licences...10 2.5 Topologie... 12 2.5.1 Crescendo II : Migration 2 nœuds 4400 vers 2 nœuds R5.1...12 2.5.2 Fusion type 1 : Migration 2/3 nœuds 4400 vers un nœud maître R5.1...12 2.5.3 Fusion type 2 : Migration n nœuds OmniPCX 4400 vers n-x nœuds OmniPCX Enterprise R5.1...13 2.6 Temps d'installation... 13 Ed. 01 / 14-05-2004 1 TC0537

OmniPCX Enterprise PROCÉDURE TECHNIQUE DE FUSION DE 3. MÉTHODOLOGIE...14 3.1 Étapes à suivre... 14 3.2 Collecte de données... 15 3.2.1 Introduction...15 3.2.2 Check list (identification des ressources concernées)...15 3.2.3 Récupération des données...18 3.3 Liste de commandes utilisables pour extraire les données de la base et les exploiter par la suite avec un tableur... 19 3.3.1 Gestion des postes et des touches programmables...19 3.3.2 Plan de numérotation...19 3.3.3 Groupements de postes...19 3.3.4 Entités...19 3.3.5 Gestion réseau...19 3.4 Mise en œuvre... 19 3.4.1 Gestion sur le(s) nœud(s) maître(s)...20 3.4.2 Gestion sur le(s) nœud(s) périphérique(s) transformés en ACT Media Gateway (ACT-IP ou ACT derrière INTOF)...21 3.4.3 Gestion sur le(s) nœud(s) conservé(s)...23 3.4.4 Implémentation sur le site...23 3.4.5 Synchronisation du système...23 3.4.6 Retour clé matérielle...24 3.4.7 Impact opérationnel pour les utilisateurs finaux...24 TC0537 2 Ed. 01 / 14-05-2004

PROCÉDURE TECHNIQUE DE FUSION DE OmniPCX Enterprise 1. INTRODUCTION 1.1 But du document Le but de ce document est de conseiller les techniciens pour la préparation et la mise en service d'une migration d'un réseau OmniPCX 4400 en OmniPCX Enterprise R5.1 avec modification de la topologie existante. Cette opération peut être délicate, car elle demande préparation et méthode. En effet la R5.1 ne supporte pas la migration d'un certain nombre d'applications internes, d'applications externes, et hardwares "phase out" qui étaient autorisés dans les releases antérieures. Il faudra s'efforcer de procéder au remplacement de tous ces éléments pour le jour où la R5.1 sera mise à disposition du client. Ce document fait référence à la procédure de mise en service de la version vers laquelle les nœuds seront migrés. Il ne traite pas les adjonctions simultanées, les nouvelles fonctionnalités et les nouveaux matériels, excepté lorsqu'il s'agit d'applications ou matériels "phase-out" (non supportés par le support technique). Ceci devra être traité séparément. 1.1.1.1 Public concerné Ce document s adresse aux techniciens sous la responsabilité d un chef de projet expert de niveau ACSE sur les produits OmniPCX 4400, OmniPCX Enterprise et applications associées (CCD, 4760, etc.). Un cursus de formation permet au Business Partner d acquérir ce niveau. Pour plus de détails veuillez vous rendre à l adresse www.businesspartner.alcatel.com. Section Formation Cependant, les phases de "collecte de données" : architecture audit et network design, de "déploiement" : deployement et project management, ou d assistance technique peuvent être réalisées à la demande par les services professionnels d Alcatel (professional.services@alcatel.fr). Pour plus de détails, veuillez vous rendre à l adresse www.businesspartner.alcatel.com. Section Services professionnels Ed. 01 / 14-05-2004 3 TC0537

OmniPCX Enterprise PROCÉDURE TECHNIQUE DE FUSION DE 1.2 Définition du processus Installed Base Leverage 1.2.1 Objectif Sachant qu'environ la moitié des systèmes Alcatel installés sont soit des OmniPCX 4400 avec une version inférieure à la Release 3.2 ou soit des modèles de PABX plus anciens (4300, 5200, 4600, 5400, 5625 et 5630), le programme Installed Base Leverage est spécialement conçu pour le renouvellement de ces systèmes. 1.2.2 Définition Le programme Installed Base Leverage se décline en 3 offres commerciales : - Renaissance : Proposer au client de nouvelles solutions via l OmniPCX Enterprise (Offre privilégiée avec renouvellement complet du matériel). Se référer au document Presales. - Crescendo II : Faire évoluer le système OmniPCX 4400 via l OmniPCX Enterprise sans modifier la topologie existante (réductions au niveau du prix des licences). Se référer au document Presales. - Fusion : Faire évoluer le système via l OmniPCX Enterprise tout en réduisant la topologie existante (réductions au niveau du prix des licences). Topologie Stand-Alone 4300, 5200, Network 4300, 4600 Stand-Alone 4400 Network 4400 4600, 5400 5625, 5630 Sans modification de la topologie existante Avec modification de la topologie existante Migration ISO/AS Migration «Node Merge» Programme Renaissance Crescendo II Fusion Remarque Si le client possède déjà une configuration OmniPCX Enterprise avec une Release 5.1, le client peut migrer mais en dehors du programme Fusion. Le service "Move", accessible sous contrat avec Alcatel, permet de répondre à cette demande. TC0537 4 Ed. 01 / 14-05-2004

PROCÉDURE TECHNIQUE DE FUSION DE OmniPCX Enterprise 1.3 Présentation du programme Fusion 1.3.1 Définition Fusion est un programme permettant de transformer des réseaux OmniPCX 4400 en une solution OmniPCX Enterprise en réduisant le nombre de nœuds/systèmes. Cette modification de topologie passe par l identification d un nœud maître, de l identification éventuelle d autres nœuds maîtres dans le cas de réseau importants, et par la transformation de nœuds (nœuds périphériques) ou ACT (TDM) en ACT Media Gateway. 1.3.2 Avantages du programme La fusion de systèmes est conditionnée par des facteurs économiques principalement engendrés par les architectures VoIP: Le déploiement de l infrastructure réseau pour l informatique de l entreprise est optimisée puisqu elle est utilisée également pour le transport de la voix et de la signalisation téléphonique. Les coûts opérationnels sont diminués puisque les systèmes (Communication Servers) à gérer, à maintenir et à faire évoluer sont moins nombreux. C est donc pour ces raisons économiques que le programme Fusion est le plus justifié. Par conséquent, le programme se focalise sur des évolutions d architectures vers l IP. Remarque Il n est pas interdit d effectuer une fusion en gardant une architecture TDM ou de réaliser un mixte d architecture VoIP / TDM. Cependant, cette solution n est pas privilégiée. 1.3.3 Limites et restrictions La fusion de systèmes ne modifie en rien les limites produits de l OmniPCX Enterprise. Exemple pour un nœud : - nombre maximum d usagers : 5000 (800 par zone périphérique) dont 4000 IP Phones, - nombre d opératrices (50), nombre de groupement d opératrices (10), - nombre maximum de Media Gateway : 90, - nombre maximum de joncteurs : 2000. Pour les limites contrôlées au niveau de l outil ACTIS, se reporter à la "Features List" de la version utilisée pour la migration. Pour plus de détails veuillez vous rendre à l adresse www.businesspartner.alcatel.com Section Presales Cependant, certains services requièrent des licences logicielles. En fonction des besoins client, vérifier que celles-ci sont bien validées au niveau des OPS. Pour plus de détails, se reporter à l'annexe 2 des procédures de mises en service de version ( R5.1). Il existe également des restrictions au niveau du matériel et des applications. Pour plus de détails, se reporter aux procédures de mises en service de version ( R5.1). Ed. 01 / 14-05-2004 5 TC0537

OmniPCX Enterprise PROCÉDURE TECHNIQUE DE FUSION DE 2. LES CARACTÉRISTIQUES DE FUSION Une étude "Presales" définira la solution optimale à mettre en œuvre. L équipe en charge du déploiement devra néanmoins connaître les différents scénarios envisageables afin de mettre en évidences les caractéristiques matérielles et applicatives. 2.1 Migration via INTIP Après étude de la topologie initiale, un nouvelle topologie sera définie, prenant en compte les différents nœuds ou ACT qui seront migrés et ceux qui seront transformés en ACT Média Gateway. Dans la suite du document, nous appellerons nœud maître le nœud principal, et nœud périphérique un nœud qui sera transformé en ACT Média Gateway. Les ACT Media Gateway seront liées au Call Server via IP comme décrit ci-dessous : OmniPCX 4400 existants Fusion OmniPCX Enterprise CPU INTIP Appliance Server * Lien ABC Migration IP CPU Lien Inter-ACT Noeud 2 (Multi-crystal) Modifications Transformation d un noeud multi-crystal en plusieurs ACT Media Gateway INTIP INTIP * Appliance Server + IOIP ou CPU Les cartes INTIP offriront jusqu à 120 ressources de compression (2 INTIP avec 2 GIP6/carte). 2.2 Migration via INTOF (TDM) Il n est pas interdit d effectuer une fusion en gardant une architecture TDM ou de réaliser un mixte d architecture VoIP / TDM. Cependant, cette solution n est pas privilégiée. TC0537 6 Ed. 01 / 14-05-2004

PROCÉDURE TECHNIQUE DE FUSION DE OmniPCX Enterprise OmniPCX 4400 existants Fusion OmniPCX Enterprise IOIP Appliance Server* INTOF CPU Migration IP INTOF Nœud 1 (Multi-Crystal) * Appliance Server + IOIP ou CPU ATTENTION: Une architecture à plusieurs niveaux n est pas possible derrière une INTIP. Pour cela, il est nécessaire de déclarer une carte INTIP en mode IOIP. Dans ce cas, cette carte permettra de connecter des ACT sur un deuxième niveau, mais cette carte ne pourra pas avoir de compresseurs. Un lien INTOF peut offrir jusqu à 400 canaux voix entre deux ACT. 2.3 Caractéristiques matérielles Types de bâtis supportés comme IP Cristal Media Gateway : Type de châssis WM1 / Voice Hub / M2 / M3 / MI M1 Supporté (oui / non) Oui Non Cartes réutilisables dans ces meubles : Type de carte Z12 / Z24 / Z32 UA16 / UA32 NDDI / NDDI2 ACEM / EMTL PRA / PRA2 / NPRA-E / BRA / BRA2 / PCM / PCM2 / DPT1 GPA2 DECT4HB / DECT8 INTIP / INTIP2 (carte VoIP) Besoins correspondants dans ACTIS Abonnés analogiques Abonnés Reflexes (direct) Joncteurs analogiques publics Joncteurs analogiques privés Joncteurs numériques publics T2 / T1/ T0 / PCM Guides vocaux / conférence Abonnés DECT IP Phones / Joncteurs IP Ed. 01 / 14-05-2004 7 TC0537

OmniPCX Enterprise PROCÉDURE TECHNIQUE DE FUSION DE Remarques Cartes non supportées dans les IP Cristal Media Gateway : Type de carte Besoins correspondants dans ACTIS Remarque Z20 VG Abonnés analogiques Remplacé par ez32 + GPA2 A4300 hardware : Ligne louée 4U Réseau privé analogique Remplacé par ACEM ou EMTL SU VG Guides vocaux Remplacé par GPA2 GPA Guides vocaux / conférence Remplacé par GPA2 DECT2 / DECT4 Abonnés DECT Remplacé par DECT8 TSC LIOE / LIOE Abonnés IP Phones / Faisceaux IP Remplacé par INTIP2 2.4 Caractéristiques applicatives 2.4.1 Messagerie vocale 4635 Avec une architecture réseau d OmniPCX 4400, la messagerie vocale peut être centralisée (localisée sur un OmniPCX 4400 mais accessible par tous les usagers du réseau) ou distribuée sur plusieurs OmniPCX 4400. Seules les 4635H/J sont supportées dans l offre OmniPCX Enterprise basée sur du hardware Crystal. Lorsqu il y a fusion des OmniPCX 4400, il est nécessaire de redimensionner les accès simultanés et la durée d enregistrement de la messagerie vocale. Il faut donc vérifier via les OPS que ces modifications correspondent aux besoins du client. Dans le cas de messagerie distribuée, la migration avec Node Merge aura un impact sur le mode opératoire de l'utilisateur si la nouvelle configuration est faite avec une messagerie centralisée : ceci implique pour les utilisateurs la perte des messages, les BAL seront recrées sur la messagerie centrale et les utilisateurs devront personnaliser à nouveau leur BAL. 2.4.2 DECT/PWT La fonction de Handover est disponible entre les bornes radio qui sont connectées dans la même Media Gateway (même Crystal ou différents Crystal interconnectés par des liens INTOF). La fonction Handover n est pas disponible entre Media Gateways connectées à travers un réseau IP. De plus, afin d éviter les problèmes de synchronisation radio, les Media Gateways doivent être localisées dans des zones géographiques distinctes pour éviter le chevauchement des zones de couverture radio. TC0537 8 Ed. 01 / 14-05-2004

PROCÉDURE TECHNIQUE DE FUSION DE OmniPCX Enterprise OmniPCX 4400 existants Fusion OmniPCX Enterprise Zone Centrale ACTIS Liens INTOF CPU Nœud 1 (Multi-Crystal) Migration INTIP CPU IP Liens INTOF CPU Noeud 2 (Multi-crystal) Modifications Transformation d un noeud multi-crystal en plusieurs Media Gateway INTIP INTIP Zone périphériques ACTIS : Couverture DECT : Base radio : Configuration interdite. Autorisée si les couvertures radio sont disjointes 2.4.3 Outil d administration Dans une architecture réseau d OmniPCX 4400, des stations de management (type 4715, 4730) peuvent être localisées sur certains sites pour offrir des services de management localisés. Après fusion de ces systèmes, seule l application OmniVista 4760 peut être utilisée pour administrer le nouveau Communication Server. Les applications de management localisées (4715 et 4730) sont donc remplacées par un serveur centralisé 4760 et des clients 4760 répartis sur les différents sites. Les données de taxation et d observation de trafic étaient liées à un objet d un ou plusieurs nœuds OmniPCX 4400. Compte tenu de la nouvelle topologie (les nœuds périphériques deviennent ACT Media Gateway), les anciennes entités (postes, ) apparaissent comme historisés (inactives), les tickets associés sont également historisés. Penser à la synchronisation avant l arrêt du nœud périphérique Dans l annuaire Entreprise, des liens existaient entre les entrées et les ressources. Si un lien entre une personne et un poste d un nœud périphérique existait, il sera supprimé. Après création de ce poste sur le nœud principal, le lien primaire peut être recréé automatiquement par une synchronisation. Les liens secondaires, fax et divers ne sont pas recréés automatiquement, il est possible de recréer ces liens manuellement (ou en utilisant les fonctions export/import de l annuaire LDAP). Ed. 01 / 14-05-2004 9 TC0537

OmniPCX Enterprise PROCÉDURE TECHNIQUE DE FUSION DE 2.4.4 Application OmniTouch Contact Center Toutes les applications OmniTouch Contact Center CCD se définissent au niveau du Communication Server. Lors de la fusion de systèmes, il est nécessaire de reconfigurer ces applications (paramétrage, matrice de distribution et guides vocaux) au niveau du nouveau Communication Server. Les statistiques des objets CCD sont stockées avec le numéro de l objet (dans le fichier catalogue). Le fait de recréer un objet d un nœud périphérique sur le nœud maître lui attribue un nouveau numéro et une date de création. Les statistiques précédentes ne sont plus récupérables. Penser à la récupération de ces données avant l arrêt du nœud périphérique. Attention aux Remote GT qui "reviennent" sur le nœud principal. 2.4.5 Autres applications Toutes les applications de type CSTA, TAPI, TSAPI, AHL, se définissent au niveau du Communication Server. Lors de la fusion de système, il est nécessaire de reconfigurer ces applications au niveau du nouveau Communication Server. 2.4.6 Répercussions sur les licences Certains services téléphoniques de l OmniPCX Enterprise requièrent des licences logicielles. Il est indispensable pour le technicien de vérifier les fichiers OPS pour répondre aux besoins client. Ci après 2 exemples ou la fusion des licences donnera un résultat différent de ce qui était disponible avant la fusion. Exemple 1 Dans le cas ci-dessous, il n y a pas d impact. Avant fusion Après fusion Licences annuaire Licences annuaire Nœud 1 100 ACT 1 100 Nœud 2 100 ACT 2 100 Exemple 2 Ci-dessous, il faudra apporter une attention particulière afin de garantir les mêmes services : Avant fusion Licences abrégés Nœud 1 1000 ACT 1 Nœud 2 800 ACT 2 Après fusion Licences abrégés 1800 TC0537 10 Ed. 01 / 14-05-2004

PROCÉDURE TECHNIQUE DE FUSION DE OmniPCX Enterprise Liste des verrous à vérifier particulièrement pour le programme Fusion : Accès simultanés au service DISA. Accès simultanés au service standard téléphonique. Canaux voix sur IP H323 pour réseau ABC. Canaux voix sur IP H323 pour terminaux / faisceaux H323. Canaux voix sur IP pour réseau SIP. Groupes de MLA avec numéro d appel sur terminaison fictive. Accès appel par nom et mini messagerie. Agents télémarketing sur lien BCA. Canaux B pour détection de la voix. Clip Z. Taille du Phone book. Alarmes pour serveur de notification. Conférences avec N participants : conférences à 6, conférences à 29, conférences dirigées. Langues utilisées pour les guides vocaux. Multi compagnies. Appel prioritaire. Restriction d appel. Services S0 supplémentaires : groupement fermé d usagers, interception d appel dans un groupement de postes S0, groupement d usagers locaux, acheminement d appel sur abonné occupé. Service sécurité supplémentaire permettant le verrouillage du Phone book sur les postes des usagers à l'aide d'un code à 4 chiffres. Protocole T2 D-REX. Hôtel / Hôpital : nombre de postes de chambre, consoles hôtel, imprimantes, lient AHL. Opératrices (4059 SBC, ). Accès VPS : accès simultanés sur équipement analogique, sur équipement numérique, Remarque : Par défaut, ACTIS créera une carte GPA correspondante dans la "zone centrale". Applications de l A4760. Pour plus de détails concernant la comparaison des licences entre l OmniPCX 4400 et l OmniPCX Enterprise, se reporter aux procédures de mises en service de version ( R5.1). Ed. 01 / 14-05-2004 11 TC0537

OmniPCX Enterprise PROCÉDURE TECHNIQUE DE FUSION DE 2.5 Topologie Chaque cas de figure est un cas unique, dans le document ci-après, trois cas de figures sont présentés : Crescendo II : Migration 2 nœuds 4400 vers 2 nœuds R5.1 Fusion type 1 : Migration 2 ou 3 nœuds 4400 vers un nœud R5.1 Fusion type 2 : Migration n nœuds 4400 vers n-x nœuds R5.1 2.5.1 Crescendo II : Migration 2 nœuds 4400 vers 2 nœuds R5.1 Ce cas de figure consiste à migrer l ensemble OmniPCX 4400 vers une solution OmniPCX Enterprise sans modification de topologie. Chaque nœud fera l objet d une attention particulière afin d éviter tout problème de compatibilités. ou AS. Se reporter à la procédure de mise en service de la version, pour une migration de type ISO En fin de migration, il est recommandé de faire un audit général. 2.5.2 Fusion type 1 : Migration 2/3 nœuds 4400 vers un nœud maître R5.1 Ce cas de figure consiste à migrer un des nœuds OmniPCX 4400 en OmniPCX Enterprise R5.1 (nœud maître), les autres nœuds (nœuds périphériques) sont soit intégrés sur ce même nœud (exemple : plusieurs nœuds 4400 sur un même site géographique avec usagers sur un même lieu géographique, à proximité du nœud maître), ou sont traités en ACT Média Gateway. 2.5.2.1 Migration du nœud "maître" ou AS. Se reporter à la procédure de mise en service de la version pour une migration de type ISO Note: les Add-on seront créés après la phase de migration. 2.5.2.2 Migration des nœuds "périphériques" Une étude précise de la configuration actuelle est nécessaire avant la migration (voir audit). En fonction de la topologie actuelle (type de liens ABC, type de services centralisés ou non, ), une nouvelle topologie doit être précisée : le nœud s intègre dans le nœud maître (alvéoles existantes) où il devient alors alvéole périphérique (ACT Média Gateway) en fonction de la configuration faite par ACTIS. Soit le matériel est recréé dans les alvéoles existantes du nœud principal, soit il est déclaré dans une (ou des) alvéole(s) périphérique(s) : Créer la (ou les) carte(s) interface pour la (ou les) ACT Média Gateway. Création des ACT Média Gateway correspondantes en fonction de la topologie résultant de l audit. TC0537 12 Ed. 01 / 14-05-2004

PROCÉDURE TECHNIQUE DE FUSION DE OmniPCX Enterprise 2.5.3 Fusion type 2 : Migration n nœuds OmniPCX 4400 vers n-x nœuds OmniPCX Enterprise R5.1 OmniPCX 4400 existants Fusion OmniPCX Enterprise N1 N2 INTIP Appliance Server Nœud 2 (Multi-Crystal) Migration IP N3 N4 Migration ABC Appliance Server IP N5 Ce cas de figure doit se décomposer en plusieurs étapes. Dans un premier temps, il faudra migrer séparément les nœuds maîtres et fusionner leurs ACT Media Gateway rattachées. Enfin, il est recommandé de faire un audit général. 2.6 Temps d'installation ACTIS fournit des temps d'installation pour les opérations correspondant à un Add-on sur le nœud maître. Même si la totalité des articles commerciaux ne sont pas commandés (exemple cas de la ré-utilisation d'une carte), il faut prendre en compte le temps d'installation total. Toutefois, ce temps n'intègre pas les opérations de démontage des anciens nœuds. ATTENTION: Ces temps sont donnés à titre indicatif, en fonction de la nature du réseau à migrer et de la complexité des systèmes et applications, ils peuvent varier. Ed. 01 / 14-05-2004 13 TC0537

OmniPCX Enterprise PROCÉDURE TECHNIQUE DE FUSION DE 3. MÉTHODOLOGIE 3.1 Étapes à suivre Collecte de données Préparation à effectuer en collaboration avec le chef de projet Identification du nœud Maître Migration du nœud Maître Configuration ACTIS (Préparation Presales) Transformation du nœud périphérique en ACT Media Gateway Formulaire Discount Chiffrage Passage de la commande (Préparation Presales) Déploiement Phase opérationnelle Renvoi des clés hard TC0537 14 Ed. 01 / 14-05-2004

PROCÉDURE TECHNIQUE DE FUSION DE OmniPCX Enterprise 3.2 Collecte de données 3.2.1 Introduction Le descriptif ci-après n est pas une procédure universelle, en effet chaque réseau est unique de part sa configuration, sa topologie ou ses exploitations. Cette description doit être utilisée comme guide pour les experts réalisant la migration, elle propose une liste non exhaustive des objets concernés lors de la migration "Node Merge". Attention, dans le cas de réseaux complexes, il est recommandé d effectuer ces opérations en laboratoire, à partir de sauvegarde des sites clients. On notera que dans ce cas, toutes les modifications apportées sur les sites entre cette sauvegarde et le basculement en R5.1.x seront perdues. 3.2.2 Check list (identification des ressources concernées) Ci après une liste non exhaustive des objets qui devront retenir l attention lors de la migration. 3.2.2.1 Liens ABC - Liens T0/T2. - Liens hybrides. - Faisceaux ABC. 3.2.2.2 Configuration matérielle - Matériel compatible supprimé. - Matériel compatible récupéré. - Matériel non compatible. - Nouveau matériel. 3.2.2.3 Plan de Numérotage - Préfixes. - Annuaire. - Plan de numérotation data / X25. - Plan de numérotation externe. Ed. 01 / 14-05-2004 15 TC0537

OmniPCX Enterprise PROCÉDURE TECHNIQUE DE FUSION DE 3.2.2.4 Exploitations réseau - Groupements. - Multi-ligne et supervision de postes. - DECT. - Messagerie vocale. - Conférence. - Débordement privé public. - ARS / ARS serveur. - Abrégés. - Sorties de proximité. - Entités/OP-GROP/Distribution d appel. - CCD : GT Remote et Pilotes dédiés. 3.2.2.5 Faisceaux - Liens publics. - Faisceaux distribués / VPN. - Liens privés. 3.2.2.6 Applications - CCD / CCX : postes pro-acd, agents, GT, - Guides vocaux. - Hôtel/Hôpital, - Réseau de messageries vocales. - A4980. 3.2.2.7 NMC / 4760 - Gestion centralisée / Incidents. TC0537 16 Ed. 01 / 14-05-2004

PROCÉDURE TECHNIQUE DE FUSION DE OmniPCX Enterprise - Annuaire. - Taxation. - Performance. - Topologie. - Management local, gestion des profils administrateur client. 3.2.2.8 VoIP - Serveur DHCP. - Terminaux H323. - Domaines IP. - QoS. 3.2.2.9 Synchronisation Le nouveau plan de synchronisation du réseau doit être défini avant la migration. La gestion des différents accès numériques (création / suppression / localisation en ACT IP) sera très probablement modifiée et devra donc faire l objet d une étude approfondie préalable. Se reporter à l'annexe 4 "Synchronisation d'un OmniPCX Enterprise après migration" des procédures de mises en service de version ( R5.1). 3.2.2.10 Routes statiques IP Si des routes statiques IP existent, utilisant les tunnels ou non, elles devront être mises à jour en tenant compte de la nouvelle topologie du réseau. Ed. 01 / 14-05-2004 17 TC0537

OmniPCX Enterprise PROCÉDURE TECHNIQUE DE FUSION DE 3.2.3 Récupération des données Une étude est réalisée afin de récupérer les données existantes. Le technicien doit travailler en collaboration avec le chef de projet pour suivre la procédure suivante : - a/ Sur les différents nœuds du réseau, réaliser une sauvegarde de la base de données après avoir effectué un fichges force_recover_dico (ou fichges recover all selon la version de départ). - b/ Récupérer sur site les informations suivantes : Le plan de numérotation. La gestion des débordements Privé-Public, les traducteurs SDA et SDA-Nœud. La configuration des postes UA et des touches. La configuration des ensembles de filtrage (si les nœuds diffèrent). La gestion des artères. La gestion des faisceaux. La gestion ARS. Les groupements de postes. Les entités avec les CDT. Les groupes d opératrices, les postes opératrice et la distribution d appel. Les terminaux et domaines IP. Le contenu du fichier lanpbx.cfg s il existe. La gestion X25 (tunnel, nœuds du réseau). La liste des terminaux en et hors service en fonctionnement normal. La gestion du DECT (synchro, PARI, postes et coquilles). Les terminaisons de données (TA, S0, Nx64). Les données Hôtel / Hôpital. Les données CCD. Le plan de synchronisation du réseau. TC0537 18 Ed. 01 / 14-05-2004

PROCÉDURE TECHNIQUE DE FUSION DE OmniPCX Enterprise 3.3 Liste de commandes utilisables pour extraire les données de la base et les exploiter par la suite avec un tableur 3.3.1 Gestion des postes et des touches programmables Grille d édition avec utilisation des filtres éventuellement. Outil multitool pour récupérer la liste des postes superviseurs et supervisés. (il n y a pas de commande capable de sortir directement les postes supervisés en réseau). Si la base de données est conséquente, le temps de réponse de l outil peut l être aussi. Les informations peuvent être récupérées dans un fichier (en plus de l écran) en transférant via FTP le fichier /usr3/mao/multi_tool.out. 3.3.2 Plan de numérotation Utiliser ednump avec les options dir/mean/info/digits. Le fichier de résultat se nomme /usr4/tmp/mcsedition.tmp. 3.3.3 Groupements de postes Grille d édition. 3.3.4 Entités La commande usedentity permet de lister tous les objets affectés à une même entité. 3.3.5 Gestion réseau Les commandes lkvisu all et hybvisu all Les données des sauts VPN avec lookvpn test Type de faisceaux et préfixes de prise : Utiliser trkvisu all 3.4 Mise en œuvre Trois options de migration se présentent en fonction de la version initiale des nœuds du réseau : - La version des nœuds est inférieure à la R2.1 Il est nécessaire de procéder la migration en 2 étapes en passant par une version intermédiaire avant de migrer en R5.x. La version des nœuds du réseau est égale ou supérieure à la R4.2. Ed. 01 / 14-05-2004 19 TC0537

OmniPCX Enterprise PROCÉDURE TECHNIQUE DE FUSION DE Ces versions sont compatibles avec la R5.x. Cela permettra de bénéficier de la fonction "diffusion" du système, et donnera le choix de migrer nœud par nœud, sans contrainte de temps. - La version des nœuds du réseau est comprises entre la R2.1 et la R4.1. Il ne sera pas possible d utiliser la fonction "diffusion" et "audit" du système. Cependant les fonctionnalités téléphoniques en réseau resteront compatibles. L arrêt de la diffusion sur chaque nœud ne permettra pas de déployer la migration sur une trop longue période ( mouvements d usagers etc.). Ce cas sera réservé pour les sites de petites capacités (mono-act, peu d usagers et sans application type CCD, etc.). Les opérations ci-dessous peuvent être réalisées sur sites ou préalablement préparées sur maquettes en laboratoire avant implémentation sur site. Pour plus de précision sur la compatibilité des versions dans un réseau, se reporter au paragraphe "conditions d installation en réseau" de la procédure de mise en service de la version. 3.4.1 Gestion sur le(s) nœud(s) maître(s) Récupération des verrous logiciels via BPWS/eLP. Appliquer les procédures de migration vers la version. ATTENTION : La diffusion doit être arrêtée sur le nœud maître et les nœuds périphériques si la version du réseau est comprise entre la R2.1 et la R4.2. Modifier les préfixes réseaux à destination du nœud remplacé pour les faire pointer vers le nœud supportant l ACT Média Gateway. Supprimer les données de ce nœud dans X25 / Nœuds du réseau. Supprimer les faisceaux liés à ce nœud. Il faudra les recréer soit par audit, soit manuellement (données globales). Vérifier que les faisceaux locaux ne débordent pas vers les faisceaux qui seront supprimés. Si nécessaire, modifier les préfixes MEVO, les titulaires MEVO. Contrôler la gestion ARS en cas de modification des numéros de faisceaux. Supprimer les préfixes VPN distants éventuels liés à ce nœud et la gestion spécifique au VPN dans les tables ARS. Supprimer le débordement privé-public éventuel. Contrôler les filtrages Patron/Secrétaire réseau. Les touches de supervision seront à contrôler ensuite par un audit. Supprimer les artères allant vers ce nœud. Corriger le plan de synchronisation du nœud selon les règles du nouveau plan. TC0537 20 Ed. 01 / 14-05-2004