NON URGENTE TEMPORAIRE DEFINITIVE OBJET : MIGRATION DES POSTES MOBILES IP TOUCH DE RELEASE 1.X VERS RELEASE 2.0

Transcription

1 COMMUNICATION TECHNIQUE N TC0781 Ed. 01 OmniPCX Enterprise Nb de pages : 12 Date : URGENTE NON URGENTE TEMPORAIRE DEFINITIVE OBJET : MIGRATION DES POSTES MOBILES IP Ce document décrit les étapes nécessaires, dans la gestion du Call Server, du SVP Server et des postes Mobile IP Touch (MIPT) pour migrer un système VoWLAN Release vers Release

2

3 MIGRATION DES POSTES MOBILES IP OmniPCX Enterprise SOMMAIRE 1. GÉNÉRALITÉS PRÉ-REQUIS À LA MIGRATION Licence type Verrou logiciel Versions logicielles ETAPES DE LA MIGRATION Préparation du serveur TFTP Binaires des MIPT Fichier lanpbx-mipt.cfg Préparation du serveur DHCP Paramètres relatifs aux postes Sans cradle Avec cradle Paramètres système Gestion sur le SVP Server RESTRICTIONS ET REMARQUES Restrictions de l'offre VoWLAN Release Ed. 01 / TC0781

4 OmniPCX Enterprise MIGRATION DES POSTES MOBILES IP TC Ed. 01 /

5 MIGRATION DES POSTES MOBILES IP OmniPCX Enterprise 1. GÉNÉRALITÉS Ce document décrit les étapes nécessaires, dans la gestion du Call Server, du SVP Server et des postes Mobile IP Touch (MIPT) pour migrer un système VoWLAN Release vers Release 2.0. RAPPEL La Release de l'offre VoWLAN a été libérée en parallèle de la Release de l'omnipcx Enterprise. Elle est basée sur une architecture de type Aruba, ainsi que sur l'utilisation de la fonctionnalité "Remote Extension" pour les postes Mobile IP Touch, considérés par le Call Server comme des terminaux H323. La Release 2.0 de l'offre VoWLAN, prévue dans le cadre de la Release 7.0 de l'omnipcx Enterprise, est toujours basée sur une architecture de type Aruba, mais les postes Mobile IP Touch intègrent désormais le protocole NOE (New Office Environment), ce qui leur assure le même niveau d'intégration dans l'omnipcx Enterprise, ainsi que le même niveau de fonctionnalité que les postes IP Touch de la série 8. Le terme migration est donc à nuancer, car la gestion des postes Mobile IP Touch dans le Call Server change radicalement entre les deux releases : les postes MIPT, qui étaient, dans les Releases 1.x de l'offre VoWLAN, des terminaux H323 bénéficiant de la fonctionnalité "Remote Extension", deviennent à partir de la Release 2.0 des postes de la gamme IP Touch à part entière. Cette procédure va donc s'attacher d'une part à lister les éléments de gestion devenus obsolètes et qui doivent donc être supprimés de façon à partir sur des bases saines pour la Release 2.0, et d'autre part à décrire ce qui doit être géré sur le Call Server, le SVP Server et les MIPT (nouvelle gestion ou conservation d'éléments de la gestion précédente). 2. PRÉ-REQUIS À LA MIGRATION 2.1. Licence type Les binaires des postes Mobile IP Touch sont différents selon que l'on utilise ces postes en mode "Remote Extension" ou en mode "NOE". Le paramètre Licence type dans les postes va permettre de spécifier quel binaire doit être utilisé: Type 11 mode "Remote Extension" (donc VoWLAN R1.x) Type 15 mode NOE (VoWLAN R2.0) Avant de débuter toute modification de gestion, il faut veiller à ce que les postes, dans leur configuration actuelle (VoWLAN R1.x), disposent du choix 15 parmi les options disponibles dans le champs Licence type. Cela doit être systématiquement le cas, à l'exception des systèmes sur lesquels la version de binaire des postes MIPT a été utilisée au cours de la vie du système. Ce cas ne devrait concerner que certains des sites bêta-test de l'offre VoWLAN R1.x. Pour vérifier ce point, accéder au menu d'administration du poste MIPT et, dans le paramètre Phone Config / License Option, vérifier que la valeur 015 est bien sélectionnée (par "*"). Ed. 01 / TC0781

6 OmniPCX Enterprise MIGRATION DES POSTES MOBILES IP Dans le cas où l'option 15 n'est pas proposée, il faut effectuer sur les postes MIPT concernés la migration intermédiaire suivante : Migration des postes en version (version disponible sur demande auprès du Support Technique) Note Suivant la configuration des postes (ex. WPA), il se peut que ces derniers ne se remettent pas en service, suite à ce passage en version Ils retrouveront cependant leur fonctionnement normal lors de leur retour à une version minimum. Migration des postes dans une version au moins égale à la version De façon à sécuriser la migration du système (mise à jour en R7.0, puis migration de la partie VoWLAN), il est fortement conseillé d'effectuer une sauvegarde de la base de données du Call Server avant la migration. Cela permettra, en cas de problème, un retour en arrière plus aisé Verrou logiciel Il faut veiller, par ailleurs, à ce que, dans les nouveaux fichiers de licence de l'omnipcx Enterprise, le verrou logiciel 330 Advanced Mobile IP-Touch Users, soit positionné à une valeur au moins égale à l'ensemble des postes MIPT à migrer Versions logicielles Se reporter à la communication technique TC0774 Note de libération technique de l'offre VoWLAN Release 2.0 pour connaître avec exactitude les versions à utiliser pour les différents éléments de la solution (Call Server, MIPT, SVP Server, OmniAccess Wireless). Actuellement, les versions suivantes sont utilisées : MIPT : (disponible sur le Call Server depuis le patch F ) SVP Server : 17x.027 OAW : ETAPES DE LA MIGRATION 3.1. Préparation du serveur TFTP Binaires des MIPT Ce paragraphe n'est à prendre en compte que dans le cas de l'utilisation d'un serveur TFTP externe pour fournir aux postes MIPT leurs binaires. Cette configuration n'est pas conseillée par Alcatel, qui recommande fortement de laisser les binaires MIPT sur le Call Server et donc d'utiliser le serveur TFTP interne pour les distribuer. Cependant, une restriction dans les versions bêta-test inférieures au patch F (binaire MIPT ) imposait l'emploi d'un serveur TFTP externe. Cette dernière est maintenant levée. TC Ed. 01 /

7 MIGRATION DES POSTES MOBILES IP OmniPCX Enterprise Note En mettant à jour le Call Server dans ce patch, ne pas oublier de mettre à jour la police, relative aux postes MIPT, du Firewall embarqué dans le switch OmniAccess WLAN, de façon à y spécifier l'adresse(s) main du (des) Call Server comme serveur(s) TFTP. Télécharger les binaires relatifs aux postes MIPT dans le répertoire adéquat sur serveur TFTP. Cela concerne les fichiers suivants : slnk_cfg.cfg fichier de configuration ascii pd11ald3.bin code MIPT binaire pd11ald.bin chargeur intermédiaire binaire pd11gl3.bin chargeur binaire pi11000?.bin polices et fichier de phrase binaire Cet aspect est radicalement différent de ce qui était en vigueur lors des releases précédentes de l'offre VoWLAN, où l'utilisation d'un serveur TFTP externe était obligatoire pour des raisons de tenue de charge Fichier lanpbx-mipt.cfg Les postes MIPT, comme tout poste IP Touch série 8, a besoin du fichier de configuration lanpbx.cfg de façon à récupérer l'adresse IP du Call Server. Cependant, du fait de la capacité mémoire limitée de ces derniers, le fichier de configuration, qui sera stocké dans le poste, doit impérativement être de taille inférieure à 1 Ko. Il faut néanmoins noter que, dans la majorité des configurations, c'est le cas. Cette limitation a entraîné la nécessité d'un fichier nommé lanpbx-mipt.cfg, dont le contenu est, dans la majorité des cas, identique à celui du fichier lanpbx.cfg et, dans les autres cas, un sousensemble du contenu du fichier lanpbx.cfg, de façon à limiter la taille du fichier résultant à 1 Ko maximum. Trois cas peuvent être observés : 1 Si le Call Server est capable de construire, sur demande et à la volée, le fichier lanpbx.cfg avec les informations présentes dans ses rémanents, alors il pourra en faire de même avec le fichier lanpbx-mipt.cfg. Ce fonctionnement est rencontré dans la plupart des cas. 2 Si le fichier lanpbx.cfg doit être créé manuellement (cas spécifiques) et si le fichier résultant est de taille inférieure à 1 Ko, alors le fichier lanpbx-mipt.cfg peut être créé en utilisant la nouvelle entrée de l'outil lanpbxbuild (7, Copy lanpbx to lanpbx-mipt). Cette entrée va réaliser une opération classique de copie de fichier. Les deux fichiers auront donc le même contenu. 3 Si le fichier lanpbx.cfg doit être créé manuellement (cas spécifiques) et si le fichier résultant est de taille supérieure à 1 Ko, alors le fichier lanpbx-mipt.cfg doit être créé via l'outil lanpbxmipt. Cet outil dispose de la même interface que l'outil lanpbxbuild, à l'exception du fait que le fichier résultant sera nommé lanpbx-mipt.cfg au lieu de lanpbx.cfg. Pour éviter de dépasser le seuil fatidique de 1 Ko, le contenu de ce fichier devra être un sousensemble du contenu du fichier lanpbx.cfg. Ed. 01 / TC0781

8 OmniPCX Enterprise MIGRATION DES POSTES MOBILES IP Lors de leur initialisation, garder en tête cette différence clé entre les postes IP Ethernet Alcatel et les postes Mobile IP Touch : Un poste IP Ethernet (IP Touch ou IP Phone), après avoir récupéré sa configuration IP, va contacter le serveur TFTP de façon à obtenir le fichier lanpbx.cfg. Dans ce fichier est mentionné le serveur TFTP qui pourra fournir au poste ses binaires. Un poste Mobile IP Touch, après avoir récupéré sa configuration IP, va contacter le serveur TFTP de façon à récupérer (si nécessaire) ses nouveaux binaires (champs TFTP Server IP), et seulement ensuite le fichier lanpbx-mipt.cfg (champs TFTP1 IP et TFTP2 IP). Ce fichier sera utilisé pour récupérer l'adresse IP du Call Server. Noter que le poste MIPT va récupérer la valeur du champs IP_DOWNLOAD (et optionnellement IP_DOWNLOAD_RD) comme valeur des paramètres TFTP1 IP (resp. TFTP2 IP) et CPU1 (PBX) IP (resp. CPU2 (PBX) IP). Note Seules quelques configurations spécifiques (réseau d'omnipcx Enterprise se partageant le même lanpbx.cfg, utilisation de la fonctionnalité "IP Touch Security",...) requièrent expressément la création manuelle du fichier lanpbx.cfg. Ainsi, dans la majorité des cas, les fichiers lanpbx.cfg et lanpbx-mipt.cfg seront créés à la volée par le Call Server. lanpbx.cfg supérieur à 1 Ko, quelle donnée peut être supprimée dans le fichier lanpbxmipt.cfg? Les lignes de sécurité (liée à la fonctionnalité "IP Touch Security") peuvent être supprimées sans problème, étant donné que les postes MIPT ne bénéficient pas de cette fonctionnalité. Dans le cas où plusieurs lignes sont présentes dans le fichier lanpbx.cfg (fichier partagé par plusieurs noeuds PBX), supprimer des lignes dans ce fichier, en conservant en priorité les lignes relatives aux noeuds auxquels sont rattachés les postes MIPT. Comme spécifié précédemment, chaque ligne du fichier peut contenir de nombreux paramètres, mais seuls TYPE, VERSION, IP_DOWNLOAD et IP_DOWNLOAD_RD sont réellement pris en compte par les postes MIPT Préparation du serveur DHCP Ce point ne doit être pris en considération que si la configuration IP des postes MIPT est gérée via DHCP. Avec la Release 2.0 de l'offre VoWLAN, il est désormais possible d'utiliser le serveur DHCP interne de l'omnipcx Enterprise. Concernant la procédure de gestion du serveur DHCP interne de façon à ce qu'il puisse servir les clients MIPT, il n'y a pas de différences par rapport au cas IP Touch, à l'exception de l'adresse IP du serveur SVP qui doit être communiquée en sus des paramètres "classiques". Cette information peut être gérée à deux niveaux : Au premier niveau de la hiérarchie de l'objet DHCP Dans ce cas, la même adresse IP sera utilisée pour tous les postes MIPT. Cela correspond, par exemple, aux topologies avec un unique serveur SVP. TC Ed. 01 /

9 MIGRATION DES POSTES MOBILES IP OmniPCX Enterprise Consultation/Modification: Configuration DHCP No noeud-réseau (réservé soft) : 21 Configuration DHCP : 1 Configuration + Serveur DHCP Peripheriques Alcatel uniquement + Oui Serveur SVP pour MIPT : Dans le sous-objet Tous Les Sous-Réseaux Ce cas doit être utilisé lorsque le serveur DHCP doit servir des postes MIPT localisés dans des zones différentes, chacune de ces zones étant "contrôlée" par un serveur SVP spécifique. Consultation/Modification: Tous Les Sous-Réseaux No noeud-réseau (réservé soft) : 21 Configuration DHCP : 1 Sous-réseau Adresse de sous-réseau : Masque de sous-réseau : Adresse de broadcast : Adresse du routeur par défaut : Adresse du serveur TFTP : VLan ID : ---- VLan Adresse : Serveur SVP pour MIPT : Note Une classe DHCP spécifique pour les postes MIPT a, par ailleurs, été créée. Consultation/Modification: Classes No noeud-réseau (réservé soft) : 21 Configuration DHCP : 1 Nom : MIPT Vendor id : alcatel.mipt.0 Adresse du serveur TFTP : Temps de bail par défaut (mn) : 60 Temps de bail maximum (mn) : 1440 Fichier de configuration : En sus de la solution présentée ci-dessus, il est toujours possible d'utiliser un serveur DHCP externe. La configuration de ce dernier est la même que celle préconisée pour la Release 1.x, à l'exception du fait que l'adresse IP du Gatekeeper est désormais inutile. Ed. 01 / TC0781

10 OmniPCX Enterprise MIGRATION DES POSTES MOBILES IP 3.3. Paramètres relatifs aux postes Afin de permettre une migration la plus souple possible, il est possible d'utiliser simultanément sur le même système des postes MIPT gérés en mode "Remote Extension", et d'autres, gérés en terminaux IP Alcatel. Cela permet de migrer les postes un à un, en fonction des possibilités. Il existe cependant une limitation à cette possibilité si le même serveur TFTP est utilisé pour les deux catégories de postes. Le poste MIPT, géré dans un mode ou l'autre, a besoin du fichier slnk-cfg.cfg; or ce dernier a un contenu différent suivant le mode (tout en conservant le même nom). Sur le serveur TFTP ne se trouveront donc que les fichiers correspondants au mode "NOE", avec comme corrolaire, dans le cas du redémarrage d'un poste en mode "Remote Extension", une impossibilité pour ce dernier de redémarrer (à moins de lui supprimer le serveur TFTP dans le menu d'administration... ce qui entraînera cependant une impossibilité pour ce dernier de télécharger le menu des services). L'autre possibilité est d'utiliser, au cours de cette migration, deux serveurs TFTP différents, un pour chaque mode. Dans ce cas, ne pas oublier de mettre à jour la gestion du Firewall intégré de l'omniaccess WLAN de façon à autoriser le flux TFTP entre les postes MIPT et ce nouveau serveur TFTP Sans cradle Pour chaque poste MIPT à migrer du mode "Remote Extension" au mode "NOE", effectuer les opérations suivantes : Supprimer le poste de type "Remote extension", ainsi que du numéro abrégé correspondant au poste. Créer le poste MIPT, comme un poste IP Touch série 8, mais de type "Mobile IP Touch". Dans le poste, accéder au menu administrateur afin de positionner le type de licence à la valeur 15. Redémarrer le poste afin qu'il se mette à jour avec le binaire IP Touch, spécifique aux postes MIPT. Suite à la mise à jour du poste, un message d'erreur relatif à la gestion du serveur TFTP apparaît: accéder au menu d'administration du poste pour positionner le champs TFTP1 (et optionnellement TFTP2) avec l'adresse IP du serveur TFTP en charge de fournir le fichier lanpbx-mipt.cfg. Redémarrer le poste. Identifier ce dernier comme tout poste IP Touch série 8 (MCDU / mot de passe utilisateur) Avec cradle Si vous disposez du cradle, une méthode alternative est possible. Sauvegarder la configuration d'un poste MIPT en mode "Remote Extension" et y modifier les paramètres suivants : licence Key 15 TFTP1 IP adresse IP du serveur fournissant le lanpbx-mipt.cfg TFTP2 IP (optionnel) adresse IP du serveur secondaire pour le lanpbx-mipt.cfg TC Ed. 01 /

11 MIGRATION DES POSTES MOBILES IP OmniPCX Enterprise Ne pas oublier de sauvegarder l'ensemble. Puis pour chaque poste MIPT à migrer du mode "Remote Extension" au mode "NOE", effectuer les opérations suivantes : Supprimer le poste de type "Remote Extension", ainsi que du numéro abrégé correspondants au poste. Créer le poste MIPT, comme un poste IP Touch série 8, mais de type "Mobile IP Touch". Mettre le poste dans le craddle et lui injecter la configuration qui a été sauvegardée précédemment, en n'oubliant pas de modifier les paramètres propres à chaque poste, comme "Extension", "IP address" (si statique). Redémarrer le poste afin qu'il se mette à jour avec le binaire IP Touch, spécifique aux postes MIPT. Identifier ce dernier comme tout poste IP Touch série 8 (MCDU / mot de passe utilisateur) Paramètres système A ce stade, tous les postes ont été migrés en mode "NOE", il est donc désormais possible de supprimer les paramètres "système" relatifs à la gestion précédente. Cela concerne : Un ensemble d'usagers de type "Ghost". Un préfixe de type Remote Extension DISA. Une entrée dans la table de rappels extérieur, spécifique aux postes MIPT. Un faisceau de type IP, pour lequel le paramètre Faisceau DISA était validé, ainsi que les données de discrimination correspondantes (Nombre de chiffres à émettre ou gestion d'un discriminateur spécifique) Un GateKeeper et une liste E164, tous deux mentionnés dans la gestion de la carte IP gérant le faisceau IP. L'ensemble de ces éléments devient inutile et doit donc être supprimé, à l'exception du faisceau IP, s'il est utilisé pour une autre fonctionnalité (IP Touch, inter-noeud, H323,...). Dans ce cas, deux cas se présentent : Le GateKeeper n'était nécessaire que pour les postes MIPT. Il faut alors veiller à supprimer le GateKeeper et la liste E164, gérés dans le Call Server, ainsi que leurs références dans la carte IP qui gérait le faisceau IP utilisé pour le VoWLAN (un reset de cette carte est alors nécessaire pour actualiser ses données). Le GateKeeper n'était pas utilisé que pour le VoWLAN. Il faut alors uniquement modifier la liste E164, pour y supprimer l'entrée correspondant au préfixe Remote Extension DISA. Ed. 01 / TC0781

12 OmniPCX Enterprise MIGRATION DES POSTES MOBILES IP 3.5. Gestion sur le SVP Server Cette partie est peu impactée par le passage de l'offre VoWLAN à la Release 2.0. Tout ce qui concerne la gestion IP du SVP Server, ainsi que la plage d'adresses IP alias, demeure. Seule la partie GateKeeper est à modifier. En effet, les postes Mobile IP Touch n'étant plus, dans la Release 2.0, des terminaux H323, l'utilisation d'un GateKeeper devient obsolète. Il faut donc, une fois que tous les postes auront été "migrés", désactiver dans le SVP Server le paramètre GateKeeper. ATTENTION Cette modification active, dans le SVP Server, le paramètre Administrative Lock avec toutes ses conséquences sur le trafic utilisateur! Cette modification est donc à réaliser hors trafic, de façon à pouvoir aisément redémarrer le SVP Server pour supprimer l'administrative Lock. Note Si pour des raisons spécifiques (trafic en particulier) un GateKeeper externe était utilisé, il peut être retiré du réseau client sans problème. 4. RESTRICTIONS ET REMARQUES 4.1. Restrictions de l'offre VoWLAN Release Le fichier lanpbx-mipt.cfg doit être de taille 1 Ko maximum. 2 Bien que faisant partie de la gamme des postes IP Touch série 8, les postes MIPT ne bénéficient pas des fonctionnalités "IP Touch Security" et "Survivabilité". Se reporter à la "Feature list" de l'omnipcx Enterprise pour obtenir des informations détaillées sur ce que les postes MIPT peuvent faire et quelles fonctionnalités ne sont pas disponibles. 3 Les postes MIPT ne peuvent être placés dans un domaine non IP. 4 Un poste MIPT ne peut pas communiquer avec une entité IP utilisant le codec G723. En conséquence le "type de compression" système doit être G729 et le booléen Algorithmes Mult. Pour Compression doit être désactivé (sinon le système n'autorisera pas la création d'usagers de type "Mobile IP Touch"). 5 Les postes MIPT requièrent une temporisation UDP_LOST avec la valeur 20. Etant donné que ces postes ne peuvent être mis dans un domaine IP spécifique, par rapport aux postes IP filaires Alcatel (pour des raisons de CAC), il en résulte que la valeur de la temporisation UDP_LOST (dans la "Catégorie de qualité de service IP") de tous les postes IP (filaires ou non) doit être positionnée à Un poste MIPT ne peut pas communiquer avec un poste TSC-IP V1S, si le framing est positionné à 20 ms. TC Ed. 01 /