Installation, Administration et Maintenance de la solution DECToverIP using SIP Release 1.7

Transcription

1 Installation, Administration et Maintenance de la solution DECToverIP using SIP Release 1.7 Document ID: depl-0900 Version: 0.4 Aastra Zeughofstr Berlin, Allemagne Juin Tous droits réservés Nulle partie de ce document ne pourra être reproduite ou transmise sous quelque forme que ce soit, électronique ou mécanique, y compris la photographie, l'enregistrement, ou les systèmes de stockage et de récupération de données, pour quelque raison que ce soit, sans l'accord express

2 Table des matières 1 PRÉSENTATION GÉNÉRALE OBJECTIF DÉCLARATION DE CONFORMITÉ ABRÉVIATIONS ET DÉFINITIONS Abréviations Définitions RÉFÉRENCES INTRODUCTION A PROPOS DE DECTOVERIP USING SIP LA SOLUTION A PROPOS DES POINTS D'ACCES (RFP) OPENMOBILITY MANAGER SIGNAL IP ET FLUX MÉDIA SYNCHRONISATION RFP CAPACITÉ CANAUX RFP A PROPOS DES PARTIES PORTABLES CAPACITÉS SYSTÈME INSTALLATION ET CONFIGURATION DÉMARRAGE OPENMOBILITY Démarrage des RFPs Description du Boot Démarrage du OpenMobility Manager Booteur Client DHCP Requête DHCP Offre DHCP Répétition Client TFTP Application Mise à jour Booteur Sélection du serveur DHCP adéquat Statut LED du RFP Graphique d'état des phases de démarrage CONFIGURATION LOCALE STATIQUE D'UN RFP CONFIGURATION DE OPENMOBILITY MANAGER Procédure de Connexion Service System Configurations système Redémarrage du OMM Encryptage Domaine Règlementaire SIP Compte Utilisateur Fuseaux Horaires Gestion de la base de données Importation manuelle de la base de données Exportation manuelle de la base de données Importation automatique de la base de données Exportation automatique de la base de données Configuration RFP Créer et modifier des RFP Touche Nouveau, Modifier et Effacer Importation par le biais de fichiers de configuration Capture de RFP Etats d'un RFP Type de matériel du RFP Vérification de version OMM / RFP SW Configuration des Parties Portables Créer et modifier des portatifs Touche Nouveau, Modifier et Effacer Importation par le biais de fichiers de configuration...57 Aastra depl-0900/0.4 Page: 2 (108)

3 Inscription Inscription avec IPEI configurés Inscription par caractère de substitution Recherche dans la liste des portatifs Configuration WLAN (RFP L42 WLAN uniquement) Optimiser le WLAN Sécuriser le WLAN avec Radius Spécifications pour le WLAN Caractéristiques système Configuration centrale de l'accès LDAP Traitement des chiffres Codes d'accès aux fonctionnalités SÉCURITÉ LE CONCEPT DE SÉCURITÉ TYPES DE COMPTES MODIFIER LES DONNÉES DU COMPTE PIÈGES POTENTIELS RÉSILIENCE DE L OMM FONCTIONNEMENT DE LA RÉSILIENCE OMM INTRODUCTION CONFIGURER LA RÉSILIENCE DE L OMM SITUATIONS DE RELAYAGE SITUATIONS DE DÉFAILLANCE DE RELAYAGE SITUATIONS DE RÉSILIENCE SPÉCIFIQUES Comment un OMM résilient devient-il actif? Procédure quand aucun des deux OMM n est synchronisé Deux interfaces aériennes DECT TÉLÉCHARGEMENT OTA COMMENT FONCTIONNE LE TÉLÉCHARGEMENT OTA CONFIGURATION DU TÉLÉCHARGEMENT OTA MAINTENANCE EQUIPEMENT DE MESURE ET D'EXPERTISE DU SITE VERIFICATION DE LA VERSION LOGICIELLE DU COMBINE AASTRA DECT 142 / AASTRA 142D DIAGNOSTIQUE Mode expertise site de l'aastra DECT 142 / Aastra 142d Mode test appel automatique Aastra DECT 142 / Aastra 142d Mode test réponse automatique de l'aastra DECT 142 / Aastra 142d Syslog shell utilisateur ssh Ouverture de session Vue d ensemble des commandes Commandes de la console RFP Commandes de la console OMM Core file captchering Suivi DECT ANNEXE INFORMATION SUR LA REGLEMENTATION DES COMMUNICATIONS POUR AASTRA DECT 142 US INFORMATION SUR LA REGLEMENTATION EN MATIERE DE COMMUNICATIONS POUR LES RFP 32 OU RFP 34 (NA) REGLES POUR LES FICHIERS DE PRE-CONFIGURATION Fichier de configuration portatif (base de données OMM) Instructions supportées Champs sections données Exemple Fichier de configuration RFP/ conf. centrale (base de données OMM) Instructions supportées Champs sections données Exemple Fichier de configuration RFP/ conf. centrale (OM Configurator) Instructions supportées Champs sections données Aastra depl-0900/0.4 Page: 3 (108)

4 Exemple PROTOCOLES ET PORTS Aastra depl-0900/0.4 Page: 4 (108)

5 1 Présentation Générale 1.1 Objectif Ce document décrit l'installation, la configuration et la maintenance de la solution.dectoverip using SIP 1.2 Déclaration de conformité Le sigle CE apposé sur le produit atteste sa conformité aux directives techniques sur la sécurité de l'utilisateur et sur la compatibilité électromagnétique, en vigueur au moment de l'établissement de la déclaration correspondante de conformité selon la directive européenne 99/5/EC. La déclaration de conformité peut être consultée sur la page d'accueil Aastra. 1.3 Abréviations et définitions Abréviations AC ADPCM DECT DHCP DSP FCC GAP IPEI HTTP OMM PARK PP SNMP TFTP RFP RTCP RTP Authentication Code Adaptive Differential Pulse Code Modulation Digital Enhanced Cordless Telecommunication Dynamic Host Configuration Protocol Digital Signal Processor Federal Communications Commission Generic Access Profile International Portable Equipment Identity Hyper Text Transfer Protocol OpenMobility Manager Portable Access Rights Key Portable Part (DECT handset) Simple Network Management Protocol Trivial File Transfer Protocol Radio Fixed Part (Access Point) Real Time Control Protocol Real Time Protocol Définitions Aastra DECT 142 Handset / Aastra 142d Aastra DECT 142 Handset / Aastra 142d Dans le contexte de cette solution DECToverIP using SIP, un Aastra DECT 142 Handset, un Aastra 142d et un Portatif sont interchangeables. En raison des différences de règlementation entre Aastra depl-0900/0.4 Page: 5 (108)

6 l'amérique du Nord et les autres régions du monde, il existe deux variantes PP utilisant des bandes de fréquences et des puissances de champ différents: Aastra DECT 142 Pour l'utilisation en Amérique du Nord. Aastra 142d Pour l'utilisation dans le reste du monde. Point Accès Asterisk DECT Point Accès Dans le contexte de la solution DECToverIP using SIP, un Point d'accès et un Radio Fixed Part (RFP) sont interchangeables. Asterisk Asterisk est un Open Source PBX complet en logiciel. Il tourne sous Linux, BSD et MacOSX et offre de nombreuses possibilités. Asterisk permet le voice over IP dans de nombreux protocoles, et peut inter opérer avec presque tous les équipements de téléphonie s'appuyant sur des normes. Digital Enhanced Cordless Telecommunication La norme (ETS ) précise l'interface air, appelée interface radio. La voix et les donnés peuvent être transmis via cette interface. Ses caractéristiques techniques clés pour l'europe sont: Gamme de fréquence: MHz (bande passante de 20 MHz environ) 10 fréquences porteuses (espacement1728 khz ) avec 12 intervalles de temps chacun Doublement du nombre d'intervalles de temps (jusqu'à 24) en utilisant le procédé TDMA Taux de données net par canal de 32 kbps (pour transmission de voix utilisant ADPCM) Codage voix utilisant la méthode ADPCM Ses caractéristiques techniques clés pour l'amérique du Nord sont: Gamme de fréquence: MHz (bande passante de 10 MHz environ) 5 fréquences porteuses (espacement1728 khz ) avec 12 intervalles de temps chacun Doublement du nombre d'intervalles de temps (jusqu'à 24) en utilisant le procédé TDMA Aastra depl-0900/0.4 Page: 6 (108)

7 Taux de données net par canal de 32 kbps (pour transmission de voix utilisant ADPCM) Codage voix utilisant la méthode ADPCM GAP Generic Access Profile GAP est l'abréviation de Generic Access Profile La norme GAP (ETS ) se fonde sur la même technologie que DECT, mais se limite aux caractéristiques basiques les plus importantes. Cette norme a été créée pour permettre aux téléphones de différents fournisseurs d'être utilisés sur n'importe quel type de système DECT. Elle représente donc le plus petit dénominateur commun de toutes les variantes spécifiques aux fournisseurs de la norme DECT. le fait que transfert externe n'est pas possible est une limite importante de la norme GAP. Pour cette raison on utilise le transfert connexion, s'appuyant sur les terminaux GAP. L'opération des téléphones GAP-capables est comparable à celle des terminaux analogiques. Par exemple, certaines fonctions peuvent être enclenchées grâce à des procédures * et #. Transfert IPEI Transfert Le transfert est similaire au roaming, mais il se produit en cours d'appel. Un transfert se produit généralement "en arrière plan", sans interrompre l'appel (transfert fluide). International Portable Equipment Identity Code d'identification à 13 chiffres pour portatif Exemple: (le chiffre final est le total de contrôle). Le code est représenté sous forme décimale. Ce code est globalement unique. PARK Portable Access Rights Key Code d'accès pour la Partie Portable. Ce code détermine si oui ou non un PP peut accéder à un système DQECT en particulier. Utilisé pour la sélection unique d'un système dédié depuis un combiné au moment de l'immatriculation/inscription du combiné. Etiqueté sur le CD OpenMobility et unique à chaque déploiement SIP- DECT. Aastra depl-0900/0.4 Page: 7 (108)

8 Roaming Roaming Lorsqu'elle est en mouvement, la PP effectue des mesures pour déterminer la réception RFP optimale. Celle offrant la meilleure réception est définie en tant que RFP active. Pour éviter que le portatif alterne rapidement entre deux RFP lorsque celles-ci présentent un signal de puissance équivalente, certains seuils sont appliqués. 1.4 Références /1/ RFC 1350, The TFTP Protocol, Revision 2, July 1992 /2/ RFC 1889, RTP: A Transport Protocol for Real-Time Applications, January 1996 /3/ RFC 2030, Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, October 1996 /4/ RFC 2131, Dynamic Host Configuration Protocol, March 1997 /5/ RFC 2327, SDP: Session Description Protocol, April 1998 /6/ RFC 2474, Definition of the Differentiated Service Field (DS Field) in the IPv4 and IPv6 Headers, December 1998 /7/ RFC 2617, HTTP Authentication: Basic and Digest Access Authentication, June 1999 /8/ RFC 3164, The BSD Sys Log Protocol, August 2001 /9/ RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, May 2000 /10/ RFC 3261, Session Initiation Protocol (SIP), June 2002 /11/ RFC 3264, An Offer/Answer Model with Session Description Protocol (SDP), June 2002 /12/ RFC 3420, Internet Media Type message/sipfrag, November 2002 /13/ RFC 3515, The Session Initiation Protocol (SIP) Refer method, April 2003 /14/ RFC 3665, The Session Initiation Protocol (SIP) Basic Call Flow Examples, December 2003 /15/ RFC 3842, A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP), August 2004 /16/ RFC 3891, The Session Initiation Protocol (SIP) Replaces Header, September 2004 /17/ RFC 3892, The Session Initiation Protocol (SIP) Referred-By Mechanism, September 2004 Aastra depl-0900/0.4 Page: 8 (108)

9 2 Introduction 2.1 A propos de DECToverIP using SIP la solution La DECToverIP using SIP solution comprend les composants suivants: Points d'accès Aastra SIP-DECT (également appelés Radio Fixed Parts (RFP)) distribués sur un réseau IP et offrant des interfaces DECT sans fil et IP. Une plateforme SIP Call Manager/IP PBX/Media Server (par ex. Asterisk). Aastra DECT 142 Handset / Aastra 142d (également appelés portatifs) OpenMobility Manager (OMM): Interface de gestion pour la solution DECToverIP using SIP, qui opère sur une des Radio Fixed Parts. La figure suivante donne une vue d ensemble graphique de l'architecture de la solution sans fil DECT IP: Les PBX IP /serveur media/passerelle media, OMM et les RFP communiquent à l aide de l'infrastructure IP. Les RFP et les portatifs communiquent par voie aérienne, en utilisant le protocole DECT GAP ou DECT GAP avec améliorations propriétaires. Aastra depl-0900/0.4 Page: 9 (108)

10 2.2 A propos des Points d'accès (RFP) Aastra DeTeWe fournit 3 types de points d accès: - RFP L32 Point d accès DECT modèle intérieur - RFP L34 Point d accès DECT modèle extérieur - RFP L42 WLAN Point d accès DECT + WLAN modèle intérieur Les RFP 32 et RFP 34 présentent généralement les mêmes capacités matérielles et logicielles. Prenez note des différences de régulations existant entre l'amérique du Nord et le reste du monde. Ces différences se traduisent par différentes variantes de RFP 32/34 utilisant des bandes de fréquences et des puissances de champs spécifiques: RFP 32 NA ou RFP 34 NA (NA) - Bande de Fréquence 1920 à 1930 MHz - 5 fréquences porteuses - Puissance de Transmission 20 dbm RFP L32 IP ou RFP L34 IP (EMEA) - Bande de Fréquence 1880 à 1900 MHz - 10 fréquences porteuses - Puissance de Transmission 24 dbm Le RFP L42 WLAN est disponible uniquement pour la zone EMEA. Un RFP avec une installation SIP-DECT doit être déclarée comme opérant en tant que OpenMobility Manager (OMM). Le RFP agissant en tant que OMM peut également agir comme un RFP normale si elle est comprise dans un Cluster DECT. Aastra depl-0900/0.4 Page: 10 (108)

11 Mode RFP uniquement Dans ce mode, le RFP convertit le protocole IP en DECT puis transmet le trafic depuis et vers les combinés à travers une intervalle de temps DECT. En émission, les RFP disposent de 12 créneaux horaires, 8 pouvant posséder des ressources DSP associées pour des flux média. Les 2 créneaux horaires restants sont utilisés pour les signaux de contrôle entre les RFP et les portatifs tandis que 2 créneaux horaires sont réservés pour des besoins de transfert. Des groupes de RFP peuvent être créés. On les appelle des grappes ou clusters. A l'intérieur d'une grappe, les RFP sont synchronisés pour permettre une passation fluide lorsqu'un utilisateur passe d'une zone de couverture RFP à une autre. Il n'est pas nécessaire pour la synchronisation que les RFP communiquent directement avec tous les autres RFP du système. Chaque RFP doit seulement être capable de communiquer avec le RFP suivant de la chaîne. Mais il est préférable pour un RFP de voir plus d'un RFP afin de garantir la synchronisation en cas de défaillance d'un RFP. Les deux canaux de contrôle de signal sont également utilisés pour porter des signaux de support qui commandent au combiné d'effectuer le processus de transfert. Si le signal radio d'un autre RFP est plus puissant que le RFP actuel, alors le combiné enclenche le processus de transfert vers le RFP avec le signal le plus puissant pendant que l'utilisateur se déplace à l'intérieur du site. Mode OpenMobility Manager Dans ce mode, les RFP fonctionnent comme des RFP normaux. De plus ils sont responsables des signaux SIP entre le système IP DECT et le serveur téléphonie ou média. Ensuite, ils prennent en charge la partie gestion de la solution IP DECT. Un RFP est désigné comme OMM en lui assignant une adresse IP dans la plage DHCP (voir chapitre 3) ou en définissant les données via l'om Configurator (voir 3.2). Après que le RFP ait été désigné en tant que OMM, il démarre les nouveaux services à bord (par exemple, le service web supportant l'interface de gestion). Tous les RFP téléchargent le même firmware à partir d'un serveur FFTP, mais un seul RFP active les services OMM. Note: Il est possible de désactiver la partie DECT d'un RFP. Si l'interface DECT est désactivée, toutes les ressources (UC et mémoire) sont disponibles pour l OMM. Aastra depl-0900/0.4 Page: 11 (108)

12 RFP 32 NA / RFP L32 IP Unused LED LED green (Application) LED orange (Application) LED red (Booter) Ethernet jack Power supply in line with Power over Ethernet standard IEEE 802.3af Power jack (120 V/230 V AC adapter) RFP L42 WLAN LED for WLAN LED green (Application) LED orange (Application) LED red (Booter) Ethernet jack Power supply in line with Power over Ethernet standard IEEE 802.3af Power jack (120 V/230 V AC adapter) Aastra depl-0900/0.4 Page: 12 (108)

13 2.3 OpenMobility Manager Le OpenMobility Manager (OMM) assure les taches suivantes: Signal passerelle(sip <-> DECT). Gestion de flux média. Gestion des fonctions sync-over-air entre RFP. Facilite modifications configuration système. Fournit des services supplémentaires, p. ex. - Annuaire d entreprise (basé sur LDAP) L OpenMobility Manager (OMM) opère sur l'un des RFP. 2.4 Signal IP et flux média Pour établir une communication entre un Téléphone IP et un portatif (Aastra DECT 142 Handset / Aastra 142d), les flux IP suivants doivent être établis: Un canal de signal depuis et vers le téléphone SIP. Un canal de signal depuis et vers le OMM. Une interface de contrôle entre le OMM et le RFP possédant une connexion au PP (appelé RFP primaire). Une connexion Real Time Protocol (RTP) / Real Time Control Protocol (RTCP) entre le téléphone SIP e RFP primaire. Le schéma suivant illustre ce scénario. Aastra depl-0900/0.4 Page: 13 (108)

14 Pour établir une communication entre deux portatifs, les mêmes flux IP que dans le scénario précédent doivent être établis, à la différence près que le téléphone IP n intervient pas. Le schéma suivant illustre ce scénario. Un appel passé d'une PP vers une autre résidant sur le même RFP sera renvoyé en boucle à l'intérieur du RFP, si aucune passerelle média n'est impliquée. L'appel ne passera donc pas par le Local Area Network (LAN). Bien que les paquets de voix n'influeront pas sur le trafic LAN, les paquets de signaux, eux, auront un impact. Aastra depl-0900/0.4 Page: 14 (108)

15 Si l'utilisateur PP est en mouvement, le PP détecte un autre RFP avec un signal plus puissant et commence donc le processus de transfert. Le flux média à partir du téléphone IP ne peut se déplacer vers le RFP secondaire, donc le RFP primaire utilise le LAN pour diriger la voix vers le RFP secondaire, comme indiqué dans le schéma suivant. Lorsque l'utilisateur PP passe dans la prochaine zone de couverture, le PP détecte que le RFP possède un signal plus puissant. Ici encore, le flux média du téléphone SIP ne peut se déplacer vers le RFP secondaire, donc le RFP primaire utilise le LAN pour diriger la voix vers le nouveau RFP secondaire. Aastra depl-0900/0.4 Page: 15 (108)

16 2.5 Synchronisation RFP Une synchronisation efficace des RFP est nécessaire pour garantir une passation fluide lorsqu'un utilisateur se déplace d'une zone de couverture RFP à une autre. Les RFP sont synchronisés par le biais de l'interface aérienne. Le premier RFP qui démarre transmet un signal par voie aérienne pour que le second RFP se synchronise. Si un RFP se synchronise, il transmet alors un signal par air et devient donc la source de synchronisation pour le RFP suivant. Seuls les RFP capables de recevoir un signal de synchronisation peuvent être synchronisés. Pour que deux RFP se synchronisent, la puissance de signal ne doit pas être inférieure à 70 dbm. Ce paramètre doit être pris en compte lors de l'étude de site. Aastra depl-0900/0.4 Page: 16 (108)

17 Tant qu'un RFP n'est pas synchronisé, aucun appel utilisant ce RFP ne pourra être passé. Si un RFP perd la synchronisation, il n'accepte plus d'appels ("occupé"). Il existe un délai maximum de 3 minutes jusqu'à que se terminent les appels actifs sur ce RFP. Il essaye ensuite à nouveau de se synchroniser. Une installation IP DECT est plus fiable si un RFP peut recevoir le signal à partir de plus d'un RFP, car les autres signaux sont également utilisés pour la synchronisation. La solution sync-over-air est tr[es fiable, car tous les chemins redondants existants sont utilisés pour la synchronisation. Donc les tolérances hardware n'ont que peu d'influence. Aucun RFP n'est en position clé. Seuls les configurations défavorables sans synchronisation redondante peuvent causer des problèmes. Parfois les RFP ne nécessitent pas de synchronisation, notamment s'ils sont situés dans des bâtiments différents. Ces RFP peuvent être placés dans des grappes différentes. Les RFP de grappes différentes ne se synchronisent pas entre eux. Les différents clusters démarrent indépendamment au même moment. 2.6 Capacité canaux RFP Les RFP ont 12 intervalles de temps disponibles: 8 intervalles peuvent avoir des ressources DSP associés pour les flux média. Les 4 intervalles restants sont utilisés par exemple pour le contrôle de signal entre RFP et portatif, ainsi que pour le transfert. Aastra depl-0900/0.4 Page: 17 (108)

18 Si les 8 canaux de flux média sont utilisés le RFP annonce un signal "occupé". Dans ce cas les portatifs recherchent un autre RFP offrant une puissance de signal appropriée. Si cela est le cas, le PP transfert vers le RFP en question. Une fois le transfert effectué, le RFP baissera le signal "occupé". Lorsque le statut occupé est annoncé, une entrée est effectuée dans le journal système. Si le signal occupé se produit dans une zone spécifique, un RFP supplémentaire devrait y être installé pour doubler le nombre de flux médias disponible pour les appels. Aastra depl-0900/0.4 Page: 18 (108)

19 2.7 A propos des Parties Portables La désignation de Portatif correspond à une terminologie standard DECT et dans le contexte de la solution DECToverIP using SIP, ce terme est interchangeable avec combiné. Aastra propose les combinés suivants : - 142d - 610d - 620d - 630d 142d 610d 620d 630d Attention aux différences de règlementation existant entre l'amérique du Nord et le reste du monde. Ces différences entraînent des variants 142d différents utilisant des bandes de fréquences et des puissances de champs spécifiques: Aastra DECT 142 (NA) - Bande de Fréquence 1920 à 1930 MHz - 60 canaux duplex mw (sortie maximale par canal actif) - 5 mw (sortie moyenne par canal actif) Aastra 142d (zone EMEA) - Bande de Fréquence 1880 à 1900 MHz canaux duplex mw (sortie maximale par canal actif) - 10 mw (sortie moyenne par canal actif) Aastra depl-0900/0.4 Page: 19 (108)

20 Les modèles 610d / 620d / 630d répondent aux exigences des réglementations en vigueur en Amérique du nord (NA) et dans la zone EMEA. En plus des Aastra DECT 142 / Aastra 142d, des téléphones DECT GAP standard de tiers peuvent fonctionner avec la solution DECToverIP using SIP. Cependant la fonctionnalité peut être limitée par les caractéristiques du téléphone DECT tiers. 2.8 Capacités Système Il n'existe qu'un seul OpenMobility Manager (OMM) actif dans le système. Les capacités OMM sont: Jusqu'à 256 RFP (points d'accès) peuvent être contrôlés. Jusqu'à 512 portatifs (combinés) sont traités. Il est possible de désactiver la partie DECT d'un RFP. Si l'interface DECT est désactivée, alors les ressources (CPU et mémoire) sont disponibles pour le OMM uniquement. Aastra depl-0900/0.4 Page: 20 (108)

21 3 Installation et configuration L'établissement et la maintenance d'une installation IP DECT suppose une infrastructure réseau comprenant au moins les composants suivants: RFP Portatif IP PBX/serveur media (e.g. Asterisk) Serveur TFTP Selon les modes de fonctionnement, les services suivants sont fournis: DHCP SNTP DNS LDAP Syslog daemon Note: En NA, les RFP extérieurs doivent être installés uniquement avec les antennes livrées par le fabricant. Aucune autre antenne ni câblage n est admis. En zone EMEA, les RFP extérieurs sont livrés sans antennes et vous devez utiliser ces unités avec une antenne optionnelle (référence à part). 3.1 Démarrage OpenMobility Démarrage des RFPs Pour booter un RFP, il doit y avoir au moins un serveur TFTP sur le réseau attaché pour charger le logiciel d'application OMM/RFP. Les paramètres réseau essentiels peuvent être l'un des suivants Communiqués par un serveur DHCP au moment du démarrage Configurés sur le RFP avec l'outil OM Configurator. Les paramètres effectués par OM Configurator seront sauvegardés de manière permanente dans la mémoire flash interne de OMM/RFP. Le RFP reçoit le fichier image de boot à partir d'un serveur TFTP. Le serveur TFTP utilisé doit supporter Section 1.3 référence. /1/ Un serveur DCP utilisé doit prendre en charge la Section 1.3 référence /4/. Le serveur TFTP et DHCP ne résident pas nécessairement sur le même hôte Description du Boot Le boot s'effectue en deux étapes: 1. Démarrage du processus de boot. 2. Démarrage de l'application. Booteur Aastra depl-0900/0.4 Page: 21 (108)

22 Le RFP ne possède qu'une petite application autonome installée dans le flash. Ce logiciel effectue le processus de boot net. Au démarrage, chaque RFP tente de déterminer sa propre adresse IP et les autres paramètres de l'interface IP à partir des paramètres de configuration dans la mémoire flash interne. Si aucun paramètre n'est disponible ou ces paramètres sont désactivés, le RFP tente de déterminer ces paramètres via DHCP. Le RFP reçoit l'image d'application à partir du serveur TFTP. Application Après le démarrage de l'image d'application, le RFP vérifie une nouvelle fois les paramètres réseau local dans sa mémoire flash interne. Si aucun paramètre n'est disponible ou si tous les paramètres sont désactivés, il démarre un DHCP client pour déterminer l'adresse IP du OMM ainsi que d'autres paramètres de démarrage Démarrage du OpenMobility Manager Il n'y a aucune différence entre le boot du RFP opérant en mode OMM et le boot de ceux opérant uniquement en mode RFP. La décision est motivée par l'adresse IP du OMM, qui est lue dans les paramètres de réseau local, s'ils sont activés. via requête DHCP. Le logiciel OMM opère sur le RFP possédant une adresse IP identique à celle du OMM dédié Booteur Client DHCP Dans le processus initial de boot le client DHCP supporte les paramètres suivants: Adresse IP obligatoire Masque de réseau obligatoire Passerelle obligatoire Nom de fichier Boot obligatoire Serveur TFTP obligatoire Option Publique 224: OpenMobility obligatoire Requête DHCP Identifiant classe fournisseur (code 60) Le client DHCP envoie l'identifiant classe fournisseur OpenMobility Liste de requête paramètre (code 55) Aastra depl-0900/0.4 Page: 22 (108)

23 Le client DHCP dans le booteur demande les options suivantes dans la liste de requête paramètre: Subnet mask option (code 1) Router option (code 3) Public option 224 (code 224) Public option 225 (code 225) Public option 226 (code 226) Aastra depl-0900/0.4 Page: 23 (108)

24 Offre DHCP Le client DHCP sélectionne le serveur DHCP selon les règles suivantes: Les public options (code 224) possèdent une valeur égale à la chaîne OpenMobility. ou le champ fichier dans le message DHCP possède une sous-chaîne égale à ip_rfp.cnt. Si aucune des deux règles ci-dessus ne s'applique alors l'offre DHCP est ignorée. Informations recherchées dans l'offre DHCP: L'adresse IP à utiliser provient du champ yiaddr du message DHCP. Le netmask IP provient du subnet mask option (code 1). La passerelle par défaut provient du router option (code 3). L'adresse IP du serveur TFTP provient du champ siaddr dans le message DHCP. Le nom de fichier de l'image de boot provient du champ file du message DHCP; si ce champ est vide, c'est le nom de fichier par défaut "iprfp.bin qui est utilisé Répétition Si le client DHCP ne reçoit pas d'offre DHCP adéquate, une nouvelle requête est envoyée après un délai d'une seconde. Après 3 tentatives de requête, le client DHCP se met en veille pendant 60 secondes. Pendant ce temps, le booteur accepte une configuration locale à l'aide de l'om Configurator (OMC). Ce cycle se répétera toutes les 3 minutes, soit jusqu'à ce que TOUTES les options DHCP requises soient fournies, ou bien jusqu'à ce que le système soit configuré manuellement à l'aide de l'outil Configurator Client TFTP Le client TFTP télécharge l'image d'application du serveur TFTP. Le serveur TFTP comme le nom de l'image d'application sont fournis via le client DHCP. L'image d'application est protégée par somme de contrôle Application Après avoir téléchargé et démarré l'application avec succès le RFP détermine l'adresse IP du OMM du DHCP. Le client DHCP est capable de recevoir des réponses DHCP broadcast et unicast. Le champ flags est donc 0x0000. La requête DHCP contient le cookie bien connu (0x ) ainsi que l'option de fin(0xff). Aastra depl-0900/0.4 Page: 24 (108)

25 Les paramètres suivants sont supportés lors de cette étape: Option / Champ Définition Obligatoire yiaddr Adresse IP du IP-RFP oui siaddr file Paramètre appelé Nom d'hôte Serveur de Boot possédant une valeur identique à l'adresse IP du serveur TFTP Paramètre appelé Nom Bootfile possédant la valeur du chemin (optionnel) et le nom de l'image d'application. Par exemple omm_ffsip.tftp. code 1 Masque subnet oui code 3 Passerelle par Défaut oui code 6 Server Nom de Domaine Non code 15 Nom de Domaine Non code 42 Adresse IP d'un serveur NTP Non code 43 Options Spécifiques au Fournisseur oui public option 224 Paramètre appelé magic_str doit être fixée à la valeur "OpenMobility". oui oui oui Les Options Spécifiques au Fournisseur sont composées de: Option Spécifique au Fournisseur option 10 Définition Longueur Obligatoire ommip1: Utilisé pour sélectionner le IP- RFP où devrait résider le OpenMobility Manager (OMM) 4 oui option 14 syslogip: Adresse IP d'un Syslog 4 Non Daemon option 15 syslogport: Port d'un Syslog Daemon 2 Non option 17 Pays: Utilisé pour sélectionner le pays 2 Non où l OMM est situé. Ce paramétrage autorise des tonalités spécifiques au pays (tonalité d'occupation, de numérotation...) option 18 ntpservname: Nom d'un Serveur NTP x Non option 19 Ommip2: Utilisé pour sélectionner un 4 Non RFP IP secondaire qui devrait abriter l'openmobility Manager (OMM) résilient ou en veille. Cette option doit être spécifiée si la fonctionnalité de résilience de l OMM doit être utilisée (voir chapitre 5 ). option 24 rsturl: Restaurer URL URL pour l'importation automatique de la base de données de l'omm (voir chapitre ) x Non Un exemple de contenu minimum pour le paramètre Option 43 serait: 0a 04 C0 A où C0 A représente pour l'omm IP. L'option 43 contient une chaîne de codes en hexadécimal; le format est numéro de l'option longueur valeur, dans cet exemple Aastra depl-0900/0.4 Page: 25 (108)

26 0a = option 10 (ommip1) 04 = la valeur suivante a une longueur de 4 blocs C0 A = S'il y a plus d'une option, l'option suivante doit être ajoutée à la suite de la précédente. Selon le serveur DHCP, vous devez terminer l'option 43 avec FF. Les tonalités pour les pays suivants sont supportées: code pays pays 1 Allemagne 2 Royaume Uni 3 Suisse 4 Espagne 6 Italie 7 Russie 8 Belgique 9 Pays Bas 10 Tchèque 11 Autriche 12 Danemark 13 Slovaquie 14 Finlande 15 Hongrie 16 Pologne 17 Biélorussie 18 Estonie 19 Lettonie 20 Lituanie 21 Ukraine 22 Norvège 24 Suède 25 Taiwan 100 Amérique du Nord 101 France 102 Australie Mise à jour Booteur Chaque application SW est livrée avec la dernière version de booteur SW. Le logiciel application actualisera automatiquement le booteur. AVERTISSEMENT :Après une mise à niveau d'une version 1.1.x à la version 1.7.x OpenMobility, le Booter des RFP sera mis à jour à la version 3.3.x. L'outil OpenMobility Configurator 1.7.x doit être installé pour configurer les RFP avec cette nouvelle version du Booter. Si vous repassez à une version antérieure du RFP, le Booter ne repassera pas automatiquement à un niveau inférieur Sélection du serveur DHCP adéquat Le client DHCP demande sa propre adresse IP à l'aide du code 50. Le client DHCP sélectionne le serveur DHCP offrant l'adresse IP actuellement utilisée. De plus, les options obligatoires doivent être proposées, faute de quoi l'offre DHCP est ignorée par le client DHCP. Aastra depl-0900/0.4 Page: 26 (108)

27 Si aucune réponse adéquate n'est reçue, le client DHCP renvoie la requête 2 fois au bout d'une seconde. Ensuite le client DHCP attend 1 minute avant d'envoyer 3 requêtes supplémentaires. Si le client DHCP ne peut accepter d'offre dans un délai de 3 minutes le RFP sera rebooté Statut LED du RFP Les schémas suivants montrent l'état des DEL d'un RFP pour les différents états du démarrage. Le RFP L32 IP possède 3 DEL distinctes, rouge, orange et vert, pour indiquer les différents états lors du démarrage. RFP 32 NA / RFP L32 IP Unused LED LED green (Application) LED orange (Application) LED red (Booter) Ethernet jack Power supply in line with Power over Ethernet standard IEEE 802.3af Power jack (120 V/230 V AC adapter) Etat Etat LED Remarques Booter (Start up) Rouge allumé Attente de connexion Booter DHCP Rouge clignotant 0,5 Hz Lancement d'une requête DHCP et attente d'une offre DHCP Booter (TFTP) Rouge clignotant 2.5 Hz Téléchargement de l'image d'application Application (DHCP) Orange allumé Lancement d'une requête DHCP et attente d'une réponse DHCP Application (init) Vert clignotant 0,5 Hz RFP initialise ses composants internes Application (init) Vert clignotant 1 Hz RFP tente de se connecter au OMM Aastra depl-0900/0.4 Page: 27 (108)

28 Etat Etat LED Remarques Application (init) Vert clignotant (2 sec allumé, 0.5 sec éteint) La partie DECT du RFP ne fonctionne pas (soit elle n est pas configurée, soit elle n est pas synchronisée avec les autres RFP) Application (init) Vert RFP fonctionne Le RFP L42 WLAN dispose d une DEL supplémentaire indiquant l état WLAN: Etat Module WLAN introuvable WLAN désactivé parce que l OMM est actif WLAN désactivé par configuration WLAN désactivé en raison de 10 Mbps 1 WLAN actif Etat DEL WLAN Rouge allumé Off Off Vert clignotant 1 Hz Vert On RFP L42 WLAN LED for WLAN LED green (Application) LED orange (Application) LED red (Booter) Ethernet jack Power supply in line with Power over Ethernet standard IEEE 802.3af Power jack (120 V/230 V AC adapter) 1 Le RFP L42 WLAN doit être raccordé à un connecteur Ethernet 100BaseT pour le service WLAN. Aastra depl-0900/0.4 Page: 28 (108)

29 3.1.6 Graphique d'état des phases de démarrage LED RED ON Start-up wait for link up LED RED ON Wait for 6 seconds; listen for local configuration BOOTER yes Local configuration LED red flashing 0,5 Hz DHCP no wait for reply DHCP no answer / offer not o.k. LED red flashing 0,25 Hz retry Wait for 60 seconds; listen for local configuration LED red flashing 2,5 Hz TFTP File download TFTP failed Local configuration yes no Kernel Listen for local configuration in every state LED orange Local conf. Start-up LED orange DHCP wait for reply DHCP no answer; offer not o.k. (try 3 minutes) LED green flashing (0,5 Hz) Application Init Init failed LED green flashing 1 Hz Application Connect to OMM Connection attempt to OMM failed LED green flashing 2 seconds on / 50ms off Application Synchronize DECT Failure, i.e. connection to OMM lost LED green Application Up & running Failure, i.e. connection to OMM lost * Change of the local configuration Aastra depl-0900/0.4 Page: 29 (108)

30 3.2 Configuration locale statique d'un RFP En lieu et place de la configuration DHCP, les RFP/OMM peuvent être configurés de manière individuelle et statique grâce à l'outil OM Configurator. L'OM Configurator requiert Java Runtime Environment, version 1.6 ou supérieure. Les paramètres, configurés sur le RFP grâce à l'outil OM Configurator, seront sauvegardés de manière permanente dans la mémoire flash interne du RFP. Les paramètres configurables via OM Configurator sont conformes à l'option DHCP. Voir section pour plus de détails. Si une configuration locale statique a été effectuée, DHCP n'est plus utilisé. La figure ci-dessous montre OM Configurator. Sur les systèmes comprenant des adaptateurs Ethernet multiples, vous devez sélectionner l interface à utiliser pour la configuration des RFP.Pour configurer un RFP, il faut spécifier au moins l'adresse MAC ainsi que toutes les options obligatoires (voir tableau ci-dessous). L'adresse MAC doit être saisie sous la forme xx-xx-xx-xx-xx-xx. Si le RFP possède déjà une adresse IP, entrez cette dernière dans le champ adresse IP. Dans ce cas, il est possible de joindre le RFP de l'extérieur du segment local LAN. Optionnel. Pour définir des paramètres supplémentaires, cliquez sur le bouton " Ajouter Paramètre" et choisissez le paramètre souhaité. Aastra depl-0900/0.4 Page: 30 (108)

31 IMPORTANT: Sélectionnez la case "oui" pour "Utiliser configuration locale" avec le RFP, sinon DHCP sera utilisé. Cliquez sur " Envoyer Configuration" pour transmettre les paramètres à un RFP. Paramètre de boot (conforme aux options DCHP) Paramètre Type Définition Utiliser locale Adresse IP configuration Masque de réseau obligatoire Les paramètres précisent s'il faut oui ou non utiliser au démarrage les réglages de la configuration locale. obligatoire Adresse IP du RFP obligatoire Masque sous-réseau du réseau IP Adresse Serveur TFTP obligatoire Adresse IP du serveur TFTP Nom de Fichier TFTP Adresse IP OMM obligatoire Au démarrage, le fichier de boot sera lu depuis le serveur TFTP. obligatoire Adresse IP de l'openmobility Manager Adresses de routeur facultatif Adresse IP de la passerelle par défaut Adresses DNS facultatif Adresse IP du serveur DNS Domaine DNS facultatif Nom de domaine du réseau Adresses de diffusion facultatif L'adresse de diffusion pour ce réseau 2ème adresse IP OMM facultatif Adresse IP de l OMM en veille/résilient Pays: facultatif Spécifiez le pays dans lequel se trouve l'omm afin de traiter les tonalités de progression d'appel spécifiques du pays. Adresse Serveur NTP facultatif Adresse IP d'un serveur NTP Nom du serveur NTP facultatif Nom d'un Serveur NTP ID du VLAN facultatif Identifiant du VLAN Adresse IP Syslog facultatif Adresse IP de destination pour le syslog Port Syslog facultatif Port de destination pour le syslog Restaurer URL facultatif URL pour l'importation automatique de la base de données de l'omm (voir chapitre ) OMM en mode proxy facultatif Mode expert Aastra depl-0900/0.4 Page: 31 (108)

32 La configuration ne peut être définie uniquement après le démarrage ou pendant la phase de répétition (LED clignotant 0,25 Hz) ou en mode kernel (voir section 3.1 pour plus de détails). L'outil de configuration attend 2 secondes et re-tente de transmettre les données 3 fois. Si vous souhaitez lire les paramètres de configuration d'un RFP, définissez l'adresse MAC et l'adresse IP puis cliquez sur "Lister Configuration". L'ensemble des paramètres sera listé dans l'outil OM Configurator. Cliquez sur " Réinitialiser Configuration" pour supprimer les champs et les paramètres supplémentaires. A partir de la version OpenMobility 1.5, un verrouillage par mot de passe peut être mis en place pour prévenir toute modification non autorisée de la configuration. Lorsque la protection est active, sélectionnez la case Login» puis entrez le nom d utilisateur et le mot de passe dans les champs Utilisateur et «Mot de passe». Ce configurateur OM est compatible vers le bas avec les versions OpenMobility sans protection par mot de passe. Un mot de passe oublié ne peut être retrouvé mais doit être effacé à l aide du bouton Données d'usine». Envoyez le cookie affiché au service d assistance du fabricant OpenMobility. Une fois que vous avez reçu du service d assistance la clé de réinitialisation du mot de passe, vous pouvez l entrer dans l invite Entrez clé de réinitialisation". Ceci effacera également toutes les configurations locales dans la mémoire flash interne du RFP! AVERTISSEMENT : lors de la réinitialisation du mot de passe, toutes les configurations locales, y compris les éventuelles configurations OpenMobility, seront effacées. Un RFP extérieur au segment LAN local peut aussi faire office de proxy. Cochez la case Proxy» pour activer cette fonctionnalité. L adresse MAC est alors utilisée pour l adressage d un RFP dans le segment LAN du RFP Proxy. La recherche de RFP disponibles et la configuration de RFP multiples à l aide d un fichier de configuration sont aussi accessibles avec le mécanisme du proxy. Aastra depl-0900/0.4 Page: 32 (108)

33 Appuyez le bouton Scan» pour rechercher les RFP disponibles dans le segment LAN local ou dans les segments LAN extérieurs par le biais du mécanisme de proxy. Toutes les adresses MAC des RFP détectés seront affichées dans la liste RFP de gauche. Les DEL d état et le bouton de mise à jour sont désactivés après la recherche de RFP. La liste de RFP peut être enregistrée à l aide du bouton «Enregistrer RFP». Ceci permet à un administrateur d éditer les données de configuration de RFP multiples à l aide d un éditeur de texte ou d un tableur comme cela est décrit au chapitre Aastra depl-0900/0.4 Page: 33 (108)

34 Le fichier de configuration préparé peut être chargé à l aide du bouton «Charger config". Les fichiers journaux (Log) recueillant les informations provenant de l analyse et de l exécution de fichier de configuration ainsi que les données sont enregistrées dans le même répertoire. Appuyez sur le bouton «Exécuter config» pour lancer le processus itératif de configuration de RFP multiples à l aide du fichier de configuration préparé et chargé. Les DEL s allumeront autant en cas de succès que d échec de la configuration. Voir le fichier journal pour de plus amples informations. En cas d échec de la configuration pour un RFP, l opération de configuration peut être renouvelée à l aide du bouton Mise à jour à côté des DEL. Précisions que les données de connexion et de proxy seront utilisées pour la totalité du fichier de configuration. Aastra depl-0900/0.4 Page: 34 (108)

35 3.3 Configuration de OpenMobility Manager Le OMM tourne sur un RFP désigné au sein d'un déploiement SIP-DECT. Le OMM est désigné via les options DHCP ou bien déclaré statiquement via l'outil OM Configurator. Les autres RFP déployés sont configurés pour se tourner vers le OMM dans le déploiement. L'OMM peut être configuré via HTTP/HTTPS. L'OMM opère comme un serveur HTTP/HTTPS. Par défaut, le serveur HTTP se couple au port 80 et le serveur HTTPS au port 443. Les données de configuration seront lues depuis la mémoire flash interne. La configuration est enregistrée dans un fichier ASCII lisible par l'homme. Il est interdit de changer le fichier de configuration hors du OMM. Le fichier de configuration peut être téléchargé et uploadé via l'interface web. L'accès de service est limité à une session active à la fois et est protégé par un mot de passe. Le navigateur utilisé pour l'accès de service doit être au moins Microsoft Internet Explorer 6.0 ou Mozilla Firefox 1,5, et doit avoir le support trame, JavaScript et les cookies en service Procédure de Connexion Service OMM ne permet qu'à un seul utilisateur à la fois de configurer le système. L'utilisateur doit être authentifié grâce à un nom d'utilisateur et à un mot de passe. Les deux sont susceptibles à la casse. Suite à l'installation initiale, ou à la suppression du fichier de configuration, le service OpenMobility est accessible via un compte utilisateur interne par défaut, avec utilisateur omm et mot de passe omm. Aastra depl-0900/0.4 Page: 35 (108)

36 Lors de la première ouverture de session avec une nouvelle version d'openmobility, l'utilisateur doit accepter les termes d'utilisation du contrat de licence (End User Licence Agreement, (EULA). Si le compte utilisateur intégré par défaut est actif, l administrateur doit changer le mot de passe pour les comptes "Accès complet" et root. La signification des différents types de compte est décrite aux chapitres 4.2 et 4.3. Aastra depl-0900/0.4 Page: 36 (108)

37 Suite à la connexion, les options suivantes sont disponibles: Affichage de l'état du système Configuration de paramètres système SIP-DECT généraux. Administration des RFP rattachés. Administration des portatifs. Configuration des paramètres du WLAN Gestion des caractéristiques système telles que traitement des chiffres et annuaire Affichage du contrat de licence d utilisateur final (EULA) Si aucune action utilisateur n'est effectuée, le OMM se déconnecte après 5 minutes. Pour se déconnecter du système, cliquer sur "Déconnexion". Aastra depl-0900/0.4 Page: 37 (108)

38 Note: Si le navigateur est fermé sans procédure de déconnexion, l'accès service sera bloqué pour d'autres clients pendant 5 minutes System Configurations système Les configurations système comprennent les paramètres généraux pour OpenMobility Manager tels que: Nom Système Accès à distance Commute sur En/Hors l'accès ssh à tous les RFP du système DECT. Code Authentification DECT. Le code d'authentification est utilisé en tant qu'option de sécurité pendant l'inscription PP initiale (voir chapitre 3.3.4). Un code introduit ici constitue un code d'authentification DECT par défaut pour chaque nouveau PP créé (voir chapitre ). Il est optionnel. PARK Chaque réseau DECT nécessite une clé PARK unique. Entrez la clé PARK telle qu'elle est étiquetée sur le CD OpenMobility. Elle est obligatoire. Encryptage tel qu'il est décrit au chapitre Domaine Règlementaire tel qu'il est décrit au chapitre Suivi DECT Pour le suivi du comportement système DECT du OpenMobility Manager une application distincte sera fournie. Cet outil requiert un accès au OpenMobility Manager qui est désactivé par défaut et peut être activé sur la page système. Pour des raisons de sécurité, le flag de surveillance DECT n'est pas enregistré de manière permanente dans la mémoire flash interne de l'omm/rfp. Après une réinitialisation, le flag de surveillance DECT est toujours désactivé. Paramètres ToS et TTL Pour permettre la priorisation des Paquets Vocaux et/ou des Paquets de Signaux à l'intérieur du réseau utilisé, le paramètre IP ToS (Type of Service) doit être configuré. Paramètres Syslog Le gestionnaire OpenMobility Manager et les RFP sont en mesure de propager des messages syslog. Cette fonctionnalité, ainsi que l'adresse IP d'un hôte collectant ces messages, peut être configurée. Paramètres Date et Heure Aastra depl-0900/0.4 Page: 38 (108)

39 Si SNTP n'est pas utilisé, la date et l'heure peuvent être configurés dans le OMM. Ceci est nécessaire pour fournir la date et l'heure au DECT 142 Handset / Aastra 142d. Les règles pour un fuseau horaire, tel que représenté sur cette page web, peuvent être configurées dans la section Fuseaux horaires du service web (voir chapitre ). Veuillez noter que au cas où le SNTP n'est pas utilisé, la date et l'heure doivent être configurés après chaque redémarrage de RFP, dans lequel fonctionne OpenMobility Manager. La date et l'heure sont fournies par OpenMobility Manager au DECT 142 Handset / Aastra 142d si le combiné initie un enregistrement de cellule DECT. Ceci se produira dans les cas suivants: Enregistrement au OMM Nouvelle entrée dans le réseau suite à la perte du signal DECT Allumage Fonctionnalité chargement silencieux actif sur le téléphone et le téléphone est sorti du chargeur Après une période spécifique nécessitant une mise à jour de la date et l'heure Please, enter the PARK key as labelled on the OpenMobility CD Aastra depl-0900/0.4 Page: 39 (108)

40 Redémarrage du OMM Pour redémarrer le OMM sélectionnez Configuration Système dans l'arbre de navigation puis sélectionnez "Redémarrer". Il existe également une option pour la réinitialisation des données de configuration. Une page web de réinitialisation se charge affichant une barre de progrès et la page web de connexion se charge automatiquement si le OMM est joignable à nouveau Encryptage Le cryptage est disponible uniquement sur les produits RFP32/34/42. l peut donc être activé sur la page web "Configuration Système" s'il n'existe aucune autre variante RFP Aastra connectées au OMM. Si l'encryptage est activé et une autre variante RFP se connecte au OMM, son interface air DECT ne sera pas activée. Note: Les portatifs doivent prendre en charge le cryptage DECT, ce qui n'est pas une fonctionnalité obligatoire Domaine Règlementaire SIP Pour définir où le IP DECT est utilisé, il faut configurer le paramètre de domaine règlementaire. Les installations existantes sont mises à jour avec la valeur par défaut EMEA (ETSI). Pour paramétrer une installation conforme FCC Amérique du Nord, la valeur attribuée doit être US (FCC/CI). Dans un déploiement Amérique du Nord USA (FCC/CI), les RFP conformes ETSI sont rendus inactifs et ne peuvent être activés si le domaine règlementaire choisi est US (FCC/CI). Le contraire est également vrai. Seul les combinés US (FCC/CI) DECT 142 peuvent être connectés aux RFP/OMM destinés au marché US et configurés pour utiliser le domaine règlementaire US (FCC/CI). Aastra depl-0900/0.4 Page: 40 (108)

41 Les paramètres SIP comprennent tous les paramètres correspondant au signal SIP et les flux de voix RFP. Serveur Proxy Adresse IP ou nom du serveur proxy SIP. En cas d'utilisation d'un nom d'hôte et d'un domaine pour le paramètre de serveur proxy assurez-vous qu'un serveur DNS et un domaine soient spécifiés pour votre système DECT SIP via DHCP ou via l'outil OM Configurator. Port Proxy Numéro de port du serveur proxy SIP. La valeur par défaut est Pour permettre le support DNS SRV pour les recherches proxy, utilisez la valeur 0 pour le port proxy. Registraire Serveur Adresse IP ou nom du registraire SIP. Permet aux portatifs d'être enregistrés avec un serveur d enregistrement. En cas d'utilisation d'un nom d'hôte et d'un domaine pour le paramètre de serveur proxy assurez-vous qu'un serveur DNS et un domaine soient spécifiés pour votre système DECT SIP via DHCP ou via l'outil OM Configurator. Port Registraire Numéro de port du Registraire SIP. La valeur par défaut est Pour permettre le support DNS SRV pour les recherches proxy, utilisez la valeur 0 pour le port registraire. Période d'enregistrement La période d'enregistrement requise, en secondes à partir du registraire. La valeur par défaut est Proxy Externe L'adresse du serveur proxy externe. Tous les messages SIP émanant du OMM sont envoyés à ce serveur. Par exemple, si votre réseau est équipé d'un contrôleur de session en périphérie (Session Border Controller), alors son adresse serait normalement configurée à cet endroit. Optionnel. Port Proxy Externe Le port proxy du serveur proxy auquel le OMM envoie tous les messages SIP. Optionnel. Souscription MWI Explicite Certains Serveurs Média tels que Asterisk supportent des Indications de Message en Attente (Message Waiting Indication: MWI) basé sur /15/. Une icône MWI apparaît sur les Aastra DECT 142 Handset / Aastra 142d si l'utilisateur a reçu un message vocal sur sa boîte vocale prise en charge par le Serveur Média. Si la Souscription MWI Explicite est activée, le OMM envoie un message explicite de Souscription MWI pour chaque PP au Proxy ou au Serveur Proxy Externe. Info agent utilisateur Si cette fonctionnalité est active, l OMM envoie des informations sur sa version dans les en-têtes SIP User-AgentServer. Aastra depl-0900/0.4 Page: 41 (108)

42 Envoyer caractère de fin de numérotation Si actif, l'omm n'utilise pas le caractère "#" pour détecter si les entrées de numérotation d'un utilisateur sont complètes. En lieu et place, l'omm attend pendant 4 secondes que l'utilisateur fasse une entrée supplémentaire après avoir actionné un chiffre de numérotation. S'i le paramètre est actif, le caractère #" peut faire partie de l information de numérotation. Temporisation de nouvelle tentative d enregistrement Définit le délai en secondes d attente de l OMM entre des tentatives d enregistrement lorsque l enregistrement est rejeté par le serveur d enregistrement. Temporisation des transactions Temps en millisecondes que l OMM alloue à un serveur d appels (proxy/serveur d enregistrement) pour répondre aux messages SIP envoyés. Si l OMM ne reçoit pas de réponse dans le délai spécifié pour ce paramètre il considère que le temps imparti pour le message est dépassé. Dans ce cas, le serveur d appels est placé en liste noire. Valeurs admises : de 4000 à Valeur par défaut : Temps limite pour liste noire Durée en minutes durant laquelle un serveur d appels qui ne répond pas peut rester dans la liste noire. Valeurs admises : de 0 à Valeur par défaut : 5. Base Port RTP Chaque RFP nécessite une zone continue de port de 68 ports UDP pour le streaming vocal RTP. La Base Port RTP est le numéro de port de départ de cette zone. La valeur par défaut est Codec 1 5 Préférés Spécifie une liste personnalisée de codecs de préférence permettant l'utilisation des Codecs préférés. Codec 1 possède le degré de priorité le plus élevé, Codec 5 étant le moins élevé. Suppression Silencieuse Utilisé pour configurer si la Suppression Silencieuse est préférée ou non. DTMF Hors Bande Utilisé pour configurer que le DTMF Hors Bande est privilégié (ou non). Méthode DTMF L'OMM prend en charge les méthodes DTMF hors bande suivantes: o RFC 2833 Transmet le DTMF sous forme d'événements RTP conformément au RFC 2833 ( /9/) après négociation du type de champ de données via SIP/SDP. "En bande" est Aastra depl-0900/0.4 Page: 42 (108)

43 automatiquement utilisé si le type de champ de données n'est pas négocié. o INFO La méthode SIP INFO est utilisée pour transmettre des tonalités DTMF sous forme d'événements téléphoniques (application/dftmf-relay). Ce réglage peut être utilisé si le RFC 2833 n'est pas pris en charge. o BOTH Les événements téléphoniques DTMF sont envoyés à la fois conformément au RFC 2833 et selon la méthode SIP INFO. Nota Bene : il est possible que l'autre partie reconnaisse deux fois les événements. Type de Champ de Données DTMF Si Hors Bande est activé, le Type de Champ de Données spécifie le type de champ de données utilisé pour envoyer les événements DTMF basé sur Section 1.3 référence /9/. Aastra depl-0900/0.4 Page: 43 (108)

44 Compte Utilisateur Suite à l'installation initiale, ou à la suppression du fichier de configuration, le service OpenMobility est accessible via un compte utilisateur interne, avec utilisateur omm et mot de passe omm. Ces paramètres, sensibles à la casse, peuvent être modifiés sur la page web "Compte Utilisateur". Aastra depl-0900/0.4 Page: 44 (108)

45 La signification des différents types de compte est décrite aux chapitres 4.2 et Fuseaux Horaires Le chapitre décrit la re-synchronisation de la date et de l heure des Aastra DECT 142 / Aastra 142d. Dans la section fuseaux horaires, le OpenMobility Manager fournit tous les fuseaux horaires disponibles. Ils s'affichent avec les règles d'heure avancée ajustées au Temps Universel Coordonné (UTC) par défaut. La différence avec l'heure UTC est indiquée dans la colonne "Différence UTC". Dans le cas de règles d'heure avancée configurées, celles-ci sont également marquées pour chaque fuseau horaire. Il est possible de modifier les règles de fuseau horaire pour un maximum de cinq fuseaux horaires. Les règles modifiées sont marquées avec le nom de fuseau horaire en gras dans le tableau. Les modifications sont sauvegardées dans le fichier de configuration et sont restituées après chaque démarrage de OpenMobility Manager. Le bouton "Par Défaut" restitue les fuseaux horaires à leur valeur par défaut et supprime les modifications de règles de fuseau horaire dans le fichier de configuration. Aastra depl-0900/0.4 Page: 45 (108)

46 Avec la boîte de dialogue "Configuration Fuseau Horaire", l'heure standard ainsi que les heures avancées (daylight savings time: DST) peuvent être modifiées. Si le fuseau horaire ne possède pas de DST, seule la différence UTC pourra être configurée. Pour DST, les deux moments (début d'heure standard et début d'heure avancée) doivent être spécifiés avec précision. Donc, une date d'un mois ou bien un jour dans le mois peuvent être utilisés. Voir les captures d'écran ci-dessous comme exemple: Aastra depl-0900/0.4 Page: 46 (108)

47 Gestion de la base de données La gestion de la base de données permet une gestion plus souple de la sauvegarde et de la restauration de la base de données de l'omm. La base de données de l'omm contient tous les paramètres de configurations, qui peuvent être configurés via l'interface de service Web. La base de données de l'omm peut être - Importée manuellement depuis le système de fichiers du navigateur Web ou d'un serveur externe - importée automatiquement depuis un serveur externe - Exportée manuellement vers le système de fichiers du navigateur Web ou un serveur externe - Exportée automatiquement vers un serveur externe en cas de modification de la configuration. Aastra depl-0900/0.4 Page: 47 (108)

48 La base de données de l'omm sera sauvegardée dans un fichier compressé, dans un format propriétaire. Toute modification apportée à ce fichier en dehors de l'omm est interdite. Le système prend en charge les protocoles de transfert suivants, vers ou à partir d'un serveur externe : - FTP - TFTP - FTPS - HTTP - HTTPS Importation manuelle de la base de données Pour importer une base de données à partir du système de fichiers du navigateur Web, vous devez sélectionner le FICHIER du protocole. Saisir le chemin d'accès et le nom du fichier qui contient la base de données OMM et appuyer sur le bouton "Charger". Avant que l'omm n'accepte la Aastra depl-0900/0.4 Page: 48 (108)

49 base de données, un contrôle de validation est effectué. Si après vérification, la base de données se révèle valide, l'omm sera réinitialisé pour activer la nouvelle base de données. Après cette réinitialisation, toutes les configurations de la base de données restaurée sont validées, tandis que les paramètres du compte utilisateur ne le sont pas. Les paramètres du compte utilisateur ne peuvent être modifiés que localement par l'intermédiaire du service Web de l'omm et ne seront jamais restaurés par une importation de la base de données. AVERTISSEMENT :Une importation manuelle ou automatique de la base de données exige une réinitialisation de l'omm pour pouvoir être prise en compte. Pour importer une base de données depuis un serveur externe, sélectionnez le protocole désiré et entrez l'adresse IP ou le nom du serveur externe. Si nécessaire, saisissez les données du compte (nom d'utilisateur / mot de passe) du serveur et sélectionnez le chemin et le nom du fichier, de l'endroit où la base de données doit être restaurée. Puis appuyez sur le bouton "Charger" Exportation manuelle de la base de données Pour exporter manuellement une base de données depuis un serveur externe, sélectionnez le protocole désiré et entrez l'adresse IP ou le nom du serveur externe. Si nécessaire, saisissez les données du compte (nom d'utilisateur / mot de passe) du serveur et sélectionnez le chemin et le nom du fichier, correspondant à l'endroit où vous voulez sauvegarder la base de données. Puis appuyez sur le bouton "Sauvegarder". Aastra depl-0900/0.4 Page: 49 (108)

50 Si la base de données est exportée vers le système de fichiers du navigateur Web (protocole : FICHIER) elle sera sauvegardée dans le fichier indiqué par l'utilisateur Importation automatique de la base de données Cette fonctionnalité facilite la restauration d'une base de données OMM préparée vers un OMM, en cas notamment de configuration initiale ou de mise à jour. Dans le cas d'une importation automatique, le fichier de la base de données doit être configurée en format URL de type : ou {ftp ftps http https}://[[user:password@]server]/[directory/]file tftp://server]/[directory/]file Pour être disponible lors du démarrage de l'omm et pour permettre une configuration initiale par le biais d'une importation automatique, cet URL doit être indiqué via DHCP (option 24 / voir chapitre 3.1.4) ou OM Configurator (voir chapitre 3.2). Si cet URL est transmise par DHCP ou OM Configurator, l'omm essaie d'importer automatiquement un fichier de base de données configuré lors du démarrage de l'omm. En plus de l'importation au démarrage, le service Web permet d'activer et de désactiver l'importation automatique de la base de données, à un moment donné de la journée, qui peut être configuré par l'utilisateur. Si l'option "Démarrage et périodiquement" est active, l'omm essaie d'importer le fichier de base de données configuré au démarrage et au moment de la journée défini. L'URL du fichier configure via DHCP ou OM Configurator est toujours affiché. Aastra depl-0900/0.4 Page: 50 (108)

51 AVERTISSEMENT : Pour une importation automatique de la base de données à un moment défini (configuré par l'utilisateur), il est recommandé de définir une synchronisation avec un serveur NTP. Pour plus de détails sur la configuration du serveur NTP, voir chapitre et le chapitre 3.2. Avant qu'une base de données ne soit acceptée et remplacée par un processus d'importation automatique, l'omm effectue les vérifications suivantes : - L'intégrité du fichier doit être vérifiée (OK) - Pour éviter d'importer le même fichier plusieurs fois, le total de contrôle de la nouvelle base de données doit être différent du total de contrôle du dernier fichier d'importation de base de données (stocké dans la mémoire flash). - Pour des raisons d'autorisation ou d'authentification : Le PARK du fichier de la nouvelle base de données doit être identique au PARK de la configuration actuelle. - Le compte d'accès admin/complet de la nouvelle base de données doit être le même que celui de la configuration actuelle. Ce n'est que si toutes ces vérifications s'avèrent positives que le fichier de la base de données sera accepté. Si le fichier de la base de données n'est pas validé ou n'a pas été trouvé, un message d'erreur s'affiche sur la page d'état du service Web de l'omm. AVERTISSEMENT :Une importation manuelle ou automatique de la base de données exige une réinitialisation de l'omm pour pouvoir être prise en compte. L'importation automatique de la base de données de l'omm permet de modifier tous les paramètres de configuration mais pas les paramètres de compte et PARK. Il y a une exception cependant : Il est possible de modifier le compte utilisateur et le PARK par défaut dans le cas d'une configuration initiale. Après la première configuration, les paramètres du compte utilisateur et le PARK ne peuvent être modifiés que via le service Web et sur l'omm cible. Aastra depl-0900/0.4 Page: 51 (108)

52 Exportation automatique de la base de données Cette fonctionnalité permet de sauvegarder automatiquement la base de données sur un serveur externe, à chaque modification de la configuration. Si cette fonctionnalité est activée, l'omm transfère un fichier de sauvegarde vers un serveur externe configure chaque fois que la configuration est modifiée, par exemple lors de l'inscription du combiné. Si la configuration n'est pas modifiée, aucune sauvegarde ne sera effectuée. Le fichier de sauvegarde sera écrasé pendant la journée, si plusieurs modifications successives sont effectuées. Un nouveau fichier sera créé lors de la première modification de la journée. L'OMM enregistrera la base de données dans un fichier stocké sur le serveur externe, en utilisant la convention de nommage des fichiers suivante : <aammjj>_<system_name>_<park>_omm_conf.gz AVERTISSEMENT : Dans le cas d'une exportation automatique de la base de données, il est obligatoire de définir une synchronisation avec un serveur NTP. Pour plus de détails sur la configuration du serveur NTP, voir chapitre et le chapitre Configuration RFP Tous les RFP configurés sont listés dans des tableaux groupés en grappes selon leurs relations topographiques. Les RFP sont classés dans l'ordre de leur adresse Ethernet (MAC). Pour assurer un transfert fluide pendant un appel, chaque RFP impliqué doit livrer le même signal horloge au PP. Ceci est possible en synchronisant les RFP. La synchronisation est obtenue en plaçant les RFP aussi près que possible de leurs voisins de manière à ce que chaque RFP reconnaisse au moins un autre RFP via son interface aérienne. Il existe des conditions où la synchronisation est impossible, par exemple lorsque les sont situés RFP dans des lieux isolés. Dans ce cas, les RFP sont Aastra depl-0900/0.4 Page: 52 (108)

53 groupés dans des grappes différentes. L OpenMobility Manager ne tentera pas de synchroniser les RFP au-delà des limites des grappes. Tous les clusters utilisés sont affichés dans la barre de navigation à gauche, et le OMM RFP est indiqué en caractères gras. Lorsque les RFP se connectent à l OMM ils transmettent leur type de matériel. Ce type est affiché dans la page web de liste de RFP Créer et modifier des RFP Touche Nouveau, Modifier et Effacer Vous pouvez ajouter de nouveaux RFP au système en cliquant sur "Nouveau". Une fenêtre contextuelle apparaît proposant la configuration d'un nouveau RFP. Chaque RFP est identifié par son adresse MAC (format 6 bytes hex, séparés par une virgule). L'adresse Ethernet est unique et peut être trouvée au dos du châssis. Aastra depl-0900/0.4 Page: 53 (108)

54 Pour faciliter l'administration, chaque RFP peut être associé à une chaîne de localisation. La chaîne de localisation peut comprendre jusqu'à 20 caractères. La fonctionnalité DECT pour chaque RFP peut être allumée/éteinte. Si DECT est actif, le RFP peut être attribué à un cluster. La partie WLAN est uniquement destinée au RFP L42 WLAN. La partie Réglages WLAN» de la page permet de sélectionner le profil, la diversité d antenne, l antenne, la puissance d émission et le canal. La diversité d antenne devrait généralement être activée (amorcée) de sorte que le PA puisse automatiquement sélectionner l antenne présentant les meilleures caractéristiques d émission et de réception. Note importante: Un RFP configuré en OMM ne peut pas simultanément fonctionner comme point d accès WLAN. Pour plus de détails sur les configurations WLAN, veuillez vous référer au chapitre La même fenêtre contextuelle peut être ouverte pour un RFP existant en cliquant sur l'icône outil du RFP adéquat. Un RFP peut être supprimé en cliquant sur l'icône poubelle. Une fenêtre contextuelle similaire demande confirmation, montrant la configuration actuelle du RFP Importation par le biais de fichiers de configuration. Il est aussi possible d effectuer une configuration semi-automatique d un jeu de RFP en important un fichier de configuration. Appuyez sur le bouton «Importer» pour parcourir le sous-menu correspondant : Sélectionnez votre fichier de configuration puis appuyez sur le bouton «Importer» (voir l annexe pour des informations sur la présentation du fichier). Vous pouvez obtenir un compte-rendu d analyse en appuyant sur le fichier «Fichier journal» Correspondant. Tous les enregistrements de données importés avec succès apparaissent dans une liste: Aastra depl-0900/0.4 Page: 54 (108)

55 Pour ajouter les RFP à la base de données de l OMM, sélectionnez-les en cliquant sur leur bouton puis appuyez sur «Ajouter". Tous les enregistrements mémorisés avec succès apparaissent en vert dans la colonne «Ajout» (les enregistrements ayant échoué sont marqués d un astérisque rouge. Les optimisations d erreurs sont visibles dans le fichier journal correspondant ou dans un traceur Syslog) Capture de RFP Les RFP qui ont été assignés à l OMM par les options DHCP ou les réglages de l'om Configurator peuvent se connecter au système. Appuyez sur le bouton «Démarrer» correspondant sur la page web Liste RFP. Au bout d un certain temps, la page est remplie avec les adresses MAC des RFP qui ont tenté de se déclarer à l OMM. Veuillez noter que ces entrées ne sont pas réellement enregistrées (elles sont perdues après la réinitialisation). En cliquant sur l icône Outils du RFP correspondant, vous pouvez ajouter des données supplémentaires et sauvegarder le RFP Aastra depl-0900/0.4 Page: 55 (108)

56 Etats d'un RFP Pour chaque RFP l'état du sous-système DECT est affiché. Ces états sont: Synchrone Le RFP fonctionne. Le RFP reconnaît et est reconnu par d'autres RFP dans sa grappe à travers son interface aérienne, et fournit un signal d horloge synchrone aux portatifs. Asynchrone Le RFP n'a encore pas eu la possibilité de se synchroniser avec ses voisins. La communication DECT est impossible. Mais le RFP a déjà pu se connecter au OMM. Cette phase ne devrait pas durer plus de quelques secondes à la suite du démarrage du RFP ou du OMM. Si cet état dure plus longtemps, cela est une indication d'erreur matériel ou réseau. Recherche Le RFP a perdu la synchronisation avec ses voisins. La communication DECT est impossible. Cette phase ne devrait pas durer plus de quelques secondes à la suite du démarrage du RFP ou du OMM. Si cet état dure plus longtemps, ou survient à nouveau après un état synchrone, ceci indique une mauvaise localisation du RFP. Inactive Le RFP s'est connecté au OMM mais l'interface air n'a toujours pas été enclenchée. Pour un RFP avec la fonctionnalité DECT activée, cette phase ne devrait durer que quelques secondes à la suite du démarrage du RFP. Si cet état perdure, cela peut indiquer une erreur matériel. Non connecté Le RFP a été configuré mais n'est pas encore connecté au OMM. La colonne adresse IP est donc vide. Aastra depl-0900/0.4 Page: 56 (108)

57 Type de matériel du RFP Lorsque les RFP se connectent à l OMM ils transmettent leur type de matériel. Ce type est affiché dans la liste de RFP de la page web : Vérification de version OMM / RFP SW Lorsque les RFP se connectent à l OMM, ils transmettent leur version logicielle. Si cette version est différente de la version OMM SW, la tentative RFP est rejetée. Cela peut se produire lors de l'utilisation dse plusieurs serveurs DHCP avec différentes versions de OpenMobility SW. Dans ce cas, le RFP est marqué avec un message d'erreur. De plus, un message d'erreur global est affiché sur la page web de liste de RFP en cas d'au moins une erreur de correspondance Configuration des Parties Portables Sur la page web des Parties Portables, tous les combinés DECT (Parties Portables) configurés sont triés par numéro. Pour que la liste soit concise, la liste complète est divisée en sous-listes comprenant jusqu'à 100 combinés. L'utilisateur peut naviguer parmi des ensembles de 100 combinés. Parce que la fonction de navigation ne permet pas de rechercher un combiné particulier parmi l'ensemble des sous-listes, une fonction de recherche est disponible permettant de retrouver un combiné à l'aide du numéro IPEI. Aastra depl-0900/0.4 Page: 57 (108)

58 La colonne "Télécharger" n'apparaît que si la fonctionnalité Téléchargement OTA est activée et contient des informations sur l'état du téléchargement (voir chapitre 6) Créer et modifier des portatifs Touche Nouveau, Modifier et Effacer Ajouter des Parties Portables au système SIP-DECT Il est possible d'ajouter une nouvelle Partie Portable au système en cliquant sur "Nouveau". La fenêtre contextuelle ci-dessous apparaît permettant la configuration d'un nouveau PP. Le paramètre de Nom représente le champ Affichage Nom SIP. Ce paramètre est optionnel mais recommandé. Le Nombre est le numéro de compte ou d'extension SIP du PP. Aastra depl-0900/0.4 Page: 58 (108)

59 Le IPEI est le numéro combiné IPEI DECT 142 qui se trouve dans le menu Options Système du combiné DECT 142. Le code d'authentification DECT est utilisé lors de l'enregistrement DECT initiale en tant que option de sécurité, et peut être configuré à cet endroit pour chaque PP séparément. Si un code global d'authentification DECT est indiqué sur la page web Configuration Système, cette valeur est entrée ici en tant que valeur par défaut. Ce paramètre est optionnel. Note: Le code d'authentification peut uniquement être modifié si le PP n'est pas encore enregistré. Le nom de PP peut être modifié, mais ceci ne prendra effet que lorsque le PP sera enregistré à nouveau. L ID supplémentaire peut être utilisée comme un moyen de recherche de données à l aide de caractères de substitution (l IPEI n est pas configuré, d où une sélection différente des données). Le Nom d'utilisateur Authentification SIP est optionnel mais recommandé. Il représente le nom qui sera utilisé lors de l'enregistrement et de l'authentification SIP. Si aucun nom n'est donné, le numéro sera utilisé par défaut. Le mot de passe sera utilisé lors de l'enregistrement et de l'authentification SIP. Modification de Parties Portables dans le système SIP-DECT Une fenêtre contextuelle apparaît lors de la configuration d'un PP existant en cliquant sur l'icône outil. La seule différence entre la fenêtre contextuelle d'ajout de PP et celle de modification est la case supprimer inscription. Si cette option est sélectionnée, l'inscription du PP sera supprimée. Suppression de Parties Portables du système SIP-DECT Un portatif peut être supprimé en cliquant sur l'icône Corbeille. Une fenêtre contextuelle apparaît, demandant confirmation de la commande Importation par le biais de fichiers de configuration. Il est aussi possible d effectuer une configuration semi-automatique d un jeu de portatifs en important un fichier de configuration. Appuyez sur le bouton «Importer» pour parcourir le sous-menu correspondant : Sélectionnez votre fichier de configuration puis appuyez sur le bouton «Importer» (voir l annexe pour des informations sur la présentation du fichier). Vous pouvez obtenir un compte-rendu d analyse en appuyant sur le fichier «Fichier journal» Correspondant. Tous les enregistrements de données importés avec succès apparaissent dans une liste: Aastra depl-0900/0.4 Page: 59 (108)

60 Pour ajouter les portatifs à la base de données de l OMM, sélectionnez-les en cliquant sur leur bouton puis appuyez sur «Ajouter". Aastra depl-0900/0.4 Page: 60 (108)

61 Tous les enregistrements mémorisés avec succès apparaissent en vert dans la colonne «Ajout» (les enregistrements ayant échoué sont marqués d un astérisque rouge. Les optimisations d erreurs sont visibles dans le fichier journal correspondant ou dans un traceur Syslog) Inscription Préparation par service Web OMM Suite à l'ajout d'une configuration PP au OMM, il est nécessaire d'inscrire le PP. Le OMM doit en premier lieu accepter l'inscription à partir des combinés PP. Ceci est possible en cliquant sur "Inscription" sur la page web OMM Unités Portables. Bouton de démarrage de la partie "Inscription avec IPEI configurés" Ce bouton permet l'inscription pour les 24 heures à venir. ou Bouton Démarrage et intervalle de la section "Inscription par caractères de substitution" Ce bouton permet une "Inscription par caractères de substitution" pour la durée indiquée. Après expiration de ce délai, "l'inscription avec IPEI configurés" reste active pendant 24 heures. Pour faciliter la première installation d'un système DECT, l'inscription est activée de façon permanente, dès lors qu'au moins un PP (avec IPEI) est Aastra depl-0900/0.4 Page: 61 (108)

62 configuré dans la base de données et qu'aucun PP n'est inscrit. Une fois l'inscription du premier PP validée, celle-ci restera activée pendant 24 heures. Etapes de l inscription effectuées par les portatifs Une fois la configuration PP terminée sur le OMM, et lorsque le OMM permet de nouvelles inscriptions, chaque PP doit être inscrit au système. Sur chaque combiné PP, l'administrateur ou l'utilisateur doit effectuer l'inscription au système SIP-DECT via le menu Système/Inscriptions. Le code PARK spécifique au système SIP-DECT doit être entré pour effectuer les inscriptions au système. IMPORTANT:le code PARK en format numérique se trouve en haut à droite de la page web OMM Parties Portables. Chaque déploiement SIP-DECT possèdera un code PARK unique fourni avec le kit d'activation OMM. Si l'administrateur a configuré un code d'authentification DECT Partie Portable global ou individuel, l'administrateur/utilisateur doit entrer ce code avant que le PP ne soit inscrit au système. Dans le cas d une inscription par caractères de substitution, il convient de noter qu une ID supplémentaire qui n a pas été tapée peut être configurée (voir sous-chapitre Inscription par caractères de substitution). En cas de difficultés rencontrés par l'administrateur/utilisateur lors de l'inscription au système SIP-DECT, il est conseillé d'éteindre le combiné PP et de tenter l'inscription à nouveau. Ceci complète le processus d'inscription d'un PP au système SIP-DECT Inscription avec IPEI configurés Les données portatifs à assigner au portatif qui s inscrit sont identifiées par l IPEI. L IPEI offre d ailleurs une garantie supplémentaire contre les inscriptions non autorisées même si l AC n a pas été programmé pour assurer la sécurité. Pour autoriser les inscriptions, appuyez sur le bouton «Démarrer» de la section «Inscription avec IPEI configurés». L OMM permettra l'inscription des portatifs configurés mais pas encore inscrits uniquement pendant l'heure qui suit. L'administrateur doit cliquer sur Inscription pour permettre à d'avantage de combinés PP d'être inscrits au système SIP-DECT Inscription par caractère de substitution Pour réduire le travail administratif, l inscription est aussi possible sans IPEI configuré. Toutefois, comme vous ne bénéficiez pas de la sécurité supplémentaire découlant du contrôle IPEI, ce type d inscription n est autorisé que dans un court intervalle par défaut de 2 minutes. Aastra depl-0900/0.4 Page: 62 (108)

63 Pour activer les inscriptions, appuyez sur le bouton «Démarrer» de la section «Inscription par caractère de substitution» et augmentez l intervalle si nécessaire (ou rafraîchissez l autorisation d inscription à temps). L OMM autorisera une inscription par caractère de substitution durant l intervalle spécifié. En cas de dépassement du temps imparti, l autorisation sera perdue. Seule l inscription avec IPEI reste autorisée dans la limite fixée d une heure (voir chapitre précédent). Pour sélectionner des données en cours d inscription (le nom d utilisateur assigné au portatif par exemple), vous pouvez activer le champ «ID supplémentaire» dans les données OMM. Lorsque l'omm reçoit une «ID supplémentaire» en cours d inscription, les données correspondantes sont assignées au portatif. Si l ID supplémentaire est requise pour un enregistrement de données, l utilisateur du portatif doit la composer. Une «ID supplémentaire» peut aussi être définie dans le menu du code d'authentification. Appuyez sur la touche R puis composez l ID supplémentaire. AVERTISSEMENT :La saisie de l'id supplémentaire est possible uniquement avec l'aastra 142 DECT / Aastra 142d. Il n est pas possible d entrer cette valeur sur des téléphones GAP de marques tierces. Quand les téléphones GAP opèrent une inscription à caractères de substitution, le premier enregistrement de données portatif sans ID supplémentaire est sélectionné et assigné Recherche dans la liste des portatifs Recherche de Parties Portables dans le système SIP-DECT Si l'utilisateur désire trouver un combiné en particulier, alors la fonction de recherche peut être utilisé. En cliquant sur "Recherche" on fait apparaître la fenêtre contextuelle suivante. L'utilisateur peut entrer le numéro de combiné ou IPEI. Il faut définir au moins l'un des paramètres. Le numéro ou IPEI doit correspondre exactement au numéro ou IPEI d'un combiné. Si l'on entre un numéro ou IPEI, alors un Aastra depl-0900/0.4 Page: 63 (108)

64 combiné correspondant doit exister au sein de la base de données OMM, faute de quoi la recherche échouera. Si un combiné possédant le numéro et/ou IPEI souhaité a été trouvé, alors une liste s'affiche comprenant le combiné en question en tête de liste. La fonction de recherche peut également être utilisée pour trouver la bonne sous-liste en une étape Configuration WLAN (RFP L42 WLAN uniquement) Pour une configuration correcte d un RFP sans composante WLAN, il faut correctement configurer la composante DECT. La seconde étape consiste à spécifier le domaine réglementaire du réseau WLAN sur la page Web système du service Web OMM. Domaine Réglementaire 0x10: FCC USA, Australie 0x20: IC Canada Pays: 0x30: ETSI Europe (hors Espagne et France) 0x31: ESPAGNE Espagne 0x31: FRANCE France 0x40: MKK Japon 0x41: MKK1 Japon (MKK1) Ces réglages dépendent du pays et sont prescrits par la législation du pays en question. Vous devez appliquer uniquement les réglages prescrits pour ce pays. Aastra depl-0900/0.4 Page: 64 (108)

65 La troisième étape consiste à spécifier les paramètres WLAN dans un profil. Entrez ici le nom (SSID) du réseau WLAN et d autres paramètres. Les procédures de cryptage et d authentification sont particulièrement importantes. Elles doivent être soigneusement préparées au préalable. Le point d accès peut être assigné à un VLAN conforme 802.1q. Toutes les données qui en sont obtenues et qui doivent être transférées aux clients WLAN sont alors acheminées par un VLAN. Toutes les données qui ne répondent pas à ce critère telles que les paquets VoIP, les données de configuration ou d authentification (Radius) reçoivent le code VLAN du RFP. Le port du composant de réseau auquel le point d accès est connecté doit être configuré comme port de réseau. Les paramètres du profil disposent de valeurs prédéfinies. Paramètre Portée Notes Périodicité de balisage Millisecondes Longueur des intervalles entre les balises. Périodicité DTIM balises Le nombre de balises entre deux transmissions DTIM (Delivery Traffic Indication Map) Aastra depl-0900/0.4 Page: 65 (108)

66 Seuil RTS Bytes Les trames Unicast et de gestion dépassant le seuil défini à cet endroit sont transmises par le biais d'une procédure de prise de contact RTS/CTS. Seuil de fragmentation Bytes Les trames Unicast dépassant le seuil spécifié à cet endroit sont fragmentées. Débit maximal 1; 2; 5,5; 6; 9; 11; 12; 18; 22; 24; 36; 48; 54 Mbps Débit maximal de transmission entre l AP WLAN et le client WLAN Mode b/g Mixte b uniquement / g uniquement Mode connexion SSID masqué Oui/non Supprime la transmission du SSID. Prévention des interférences Paramètres de sécurité Oui/non Procédure pour prévenir les interférences. Paramètres de cryptage (voir ci-dessous) Filtre d accès MAC 1 64 Clients autorisés (liste blanche) Isolation BSS Oui/non Evite que les clients WLAN n en détectent un autre. Longueur du chiffrage Intervalle de distribution. 64 / 128 / 256 Bits Longueur de la clé utilisée dans les modes de sécurité. Secondes Intervalles entre les échanges de clés Paramètres Radius Adresse IP, port, secret Paramètres serveur Radius. Paramètres SSID multiples Nom du SSID, paramètres VLAN et de sécurité 1 à 3 SSID supplémentaires En sélectionnant «Système ouvert», vous configurez un système ouvert, à savoir un système dans lequel toutes les procédures d authentification et de cryptage sont désactivées. Les paramètres «Isolation BSS» évitent aux clients WLAN de se contacter mutuellement autrement que par un seul et unique AP. Note:Le RFP L42 WLAN doit être raccordé à un connecteur Ethernet 100BaseT pour devenir opérationnel en tant que service WLAN Optimiser le WLAN Intervalle de balisage La transmission de balises requiert des capacités de transmission. En réduisant l intervalle de balisage, vous accroissez les capacités du réseau Aastra depl-0900/0.4 Page: 66 (108)

67 WLAN à détecter des signaux tout en améliorant sa disponibilité. Dans le même temps, vous augmentez la capacité du réseau à ajuster la puissance de signal négociée mutuellement. Une valeur plus élevée ou, en autres termes, un intervalle de balisage plus long réduit indirectement la consommation de courant du client WLAN. Seuil RTS Si le débit du réseau est faible ou s il y a de nombreuses retransmissions, vous pouvez activer la correction RTS en abaissant le seuil RTS. Ceci peut améliorer le débit, tout particulièrement dans les environnements où les réflexions et atténuations créent des difficultés pour la transmission HF. Seuil de fragmentation Dans les environnements sujets à d importantes interférences et à une faible qualité de signal radio, la réduction de la taille des fragments peut améliorer le débit effectif. Cependant, dans ce cas, les trames transmises doivent être plus souvent fragmentées, ce qui induit une charge plus importante pour le processeur AP. Périodicité DTIM La périodicité DTIM désigne l intervalle entre les transmissions de paquets à diffusion générale et multidiffusion. Tous les clients WLAN doivent être actifs durant cet intervalle. L augmentation de la périodicité DTIM réduit légèrement la consommation d énergie du client. Tous les programmes ne sont toutefois pas en mesure de gérer l augmentation des temps de réponse Sécuriser le WLAN avec Radius. Diverses mesures sont nécessaires en vue de garantir la sûreté des communications dans le réseau WLAN. Tout d abord, les paquets de données transmis via l interface radio ouvertement visible doivent être cryptés. Ensuite, tous les composants qui constituent une partie du réseau ou fournissent des services devraient s authentifier. Vous construisez é cet effet un système dit «AAA» (Authentification, Authorisation, Accounting - authentification, autorisation, compte). Le RFP L42 WLAN fait office de serveur d accès au réseau tandis qu un serveur Radius fait office de serveur AAA. Le RFP L42 WLAN fonctionne comme accès de réseau et peut transférer l authentification à un serveur Radius dans le réseau. Le cryptage des données échangées entre le RFP L42 WLAN et le client WLAN est assuré par WPA (accès WiFi protégé), 802.1x (Radius) ou par «802.1x (Radius)» qui utilise le cryptage WEP. L adresse IP du serveur, le port IP et le mot de passe commun doivent être entrés dans le profil Radius). Un serveur Radius (Remote Authentication Dial In User Service) gère l authentification 802.1x et autorise les clients. Nous recommandons l utilisation d un serveur Radius avec EAP-TLS (p. ex. FreeRadius ou MS Windows 2003 IAS Serveurs) ainsi que d une autorité de certification (CA). Aastra depl-0900/0.4 Page: 67 (108)

68 Votre client WLAN doit prendre en charge cette méthode d authentification et doit détenir les certificats déterminants (c est le cas pour la plupart des clients WLAN). Un site de certification est nécessaire pour générer les clés qui doivent être communiquées au client WLAN et au serveur Radius. Vous devez entrer l adresse IP du serveur Radius, le port IP et le secret commun dans la section des paramétrages du Radius. La dernière étape consiste à assigner un profil aux RFP / points d accès (PA). Chaque PA doit être configuré sur un canal. A cet égard, vous devez veiller à ce que les fréquences des canaux PA ne se chevauchent pas. Les PA à portée des autres doivent être séparés d au moins cinq canaux. Vous procédez à cette configuration sur l écran de configuration des PA. Une fois Aastra depl-0900/0.4 Page: 68 (108)

69 que la zone radio est panifiée, les PA de n importe quel autre WLAN pouvant fonctionner dans le voisinage doivent être pris en compte. Lorsque vous étudiez la couverture radio pour une zone bidimensionnelle, vous devez garder à l esprit que la distance entre deux stations de base utilisant la même fréquence doit représenter au moins deux fois leur portée. La portée peut être ajustée avec le paramètre de puissance d émission. Vous pouvez ajouter de nouveaux PX et assigner des RFP configurés à un réseau WLAN à l aide du menu «Radio Fixed Parts». Pour cela, sélectionnez l'option "Trié par" pour l'entrée "Profils WLAN". Aastra depl-0900/0.4 Page: 69 (108)

70 Dans la partie «Réglages WLAN» de la page, vous pouvez sélectionner le profil, la diversité d antenne, l antenne, la puissance d émission et le canal. La diversité d antenne devrait généralement être activée (amorcée) de sorte que le PA puisse automatiquement sélectionner l antenne présentant les meilleures caractéristiques d émission et de réception. La partie WLAN est disponible uniquement pour le RFP L42 WLAN. IMPORTANT: Un RFP configuré en OMM ne peut pas simultanément fonctionner comme point d accès WLAN Spécifications pour le WLAN Les adaptateurs WLAN conformes aux normes b ou g sont requis pour exploiter des clients WLAN. Concernant le cryptage WEP et WPA ainsi que l utilisation d une infrastructure Radius, il faut assurer que les adaptateurs de réseau WLAN tournant sous le système d exploitation du client prennent en charge les modes requis. En tout état de cause, il faut toujours vérifier le bon fonctionnement des adaptateurs avant de les mettre en service Caractéristiques système Configuration centrale de l'accès LDAP Les paramètres suivants sont définis via le service web OMM. La configuration s'applique à tous les combinés PP, l'appel par le nom LDAP est activé. L'OMM prend en charge le LDAP simple bind. Aastra depl-0900/0.4 Page: 70 (108)

71 Description des champs: Nom de serveur et port de serveur (obligatoire) - Nom de serveur ou adresse IP du serveur - Port du serveur (par défaut: 389) Nota Bene : SSL (port par défaut 689) n'est pas pris en charge Répertoire racine La base de recherche doit être éditée (p. ex., ou=people,o=my com ). Nom d utilisateur et mot de passe d utilisateur Il est possible d'entrer un nom d utilisateur (un nom distinctif) et un mot de passe si le serveur LDAP l'exige. Sinon, les entrées sont remplies par une connexion anonyme. Nota Bene : l'omm DECT IP prend en charge le LDAP simple bind. Attributs de recherche Les recherches sont effectuées pour l'un des attributs suivants - Nom (sn)-> (par défaut) // nom de famille - Prénom Attributs d'affichage Il est possible de choisir entre les deux alternatives suivantes: - nom de famille (sn), prénom ->par défaut - prénom et nom de famille (sn) Timeout de recherche du serveur (plage de valeurs: 1-99 sec) Les résultats de la recherche sont acceptés pendant le délai de recherche. Aastra depl-0900/0.4 Page: 71 (108)

72 Traitement des chiffres Le traitement des chiffres remplace, efface ou insère des chiffres pour les numéros reçus par l'annuaire d entreprise (basé sur LDAP). Les chiffres sont traités en deux étapes: pour commencer, tous les caractères invalides tels que les espaces ou traits d'union sont éliminés du numéro (p. ex., +49 (30) est remplacé par ). Dans la seconde étape, le système recherche la meilleure concordance au sein de la liste des préfixes configurés. Le préfixe est remplacé (p. ex., la meilleure concordance pour le numéro est le préfixe avec le substitut ; le résultat est 4492 ). Le traitement des chiffres a lieu avant que le numéro ne soit transmis au menu du combiné. Plages de valeurs et limites: jusqu'à 128 entrées si l'omm tourne sur une station de base DECT IP et 750 entrées si l'omm tourne sur un serveur Linux sont possibles Chaque préfixe peut être composé de chiffres (0-9) et des caractères * et #. Conformément aux standards LDAP, le premier caractère peut être un +. Jusqu'à 15 chiffres par séquences sont possibles. Les espaces ne sont pas autorisés. Chaque substitut peut être composé de chiffres (0-9) et des caractères * et # Codes d'accès aux fonctionnalités Les codes d'accès aux fonctionnalités permettent d'exécuter certaines actions spécifiques sur l'omm à partir de n'importe quel combiné DECT enregistré. Aastra depl-0900/0.4 Page: 72 (108)

73 Pour activer un code d'accès aux fonctionnalités (FAC), sélectionnez un numéro de FAC unique, activez la case correspondante et entrez le code d'action associé. Après quoi, pour exécuter l'action correspondante, il vous suffit de composer le numéro du "numéro FAC", suivi du "code d'action FAC" en bloc à partir de n'importe quel combiné enregistré. Dans l'exemple ci-dessus un utilisateur inscrit peut activer l'inscription DECT de l'omm en composant 99999*4701# en bloc. AVERTISSEMENT : Les transmissions en chevauchement ne sont pas prises en charge pour les FAC. Le "numéro FAC" et le "code d'action FAC" doivent être saisis en bloc. Les fonctions FAC seront confirmées par un signal sonore (signaux de tonalité intrabande). Aastra depl-0900/0.4 Page: 73 (108)

74 4 Sécurité 4.1 Le concept de sécurité En plus de l'accès https de l'omm, chaque RFP offre deux possibilités d'accès: l'om Configurator et un accès ssh. Chacun de ces 3 types d accès indépendants utilise les mêmes données de compte. Les données du compte peuvent être modifiés sur l interface https de l OMM. L OMM fournit toutes les informations nécessaires relatives au compte pour tous les RFT connectés. Les RFP enregistrent les données du compte dans leur mémoire permanente. Ceci a quelques implications : 4.2 Types de comptes Un RFP sorti de son emballage utilise les données de compte par défaut tant qu il n est pas connecté à l OMM. Un RFP qui a été connecté au moins une fois à l OMM utilise les données de compte de l OMM : Si les données du compte sont modifiées sur l OMM, tout RFP non connecté continue d utiliser les anciens mots de passe. Il existe 3 types de comptes différents : 1. Accès complet Ce type d accès constitue l accès «normal» à toute la configuration. Cet accès permet de configurer l OMM et chaque RFP. Le type d accès permet de se connecter à l interface ssh d un RFP pour déboguer des informations ou par exemple «pinguer» un autre RFP pour vérifier sa visibilité. La configuration d origine pour ce compte est Nom: 'omm' Mot de passe: 'omm' Actif: 'n/a' 2. Accès Lecture uniquement Comme son nom le suggère, ce type d accès ne comprend pas l autorisation de modifier un quelconque point de l installation de l'omm. Ce type d accès est autorisé uniquement sur l interface https. Le compte peut être désactivé. La configuration d origine pour ce compte est Nom: 'user' Mot de passe: 'user' Actif: Oui 3. Accès racine Ce type d accès s applique uniquement à l interface ssh d un RFP. Son but est d obtenir des informations détaillées, notamment les paramètres du noyau. L accès utilisant ce type de compte ne peut être Aastra depl-0900/0.4 Page: 74 (108)

75 atteint depuis les autres hôtes, d autant plus qu une ouverture de session utilisant le type d accès complet est nécessaire. IMPORTANT: Il est vivement déconseillé d'utiliser ce type de compte. Il a uniquement été conçu pour l assistance technique. La configuration d origine pour ce compte est Nom: 'root' Mot de passe: '22222' Actif: 'n/a' https OM Configurator ssh Accès complet Autorisé Autorisé Autorisé Accès lecture uniquement Autorisé (mais permission de modifier la configuration) Non autorisé Non autorisé Accès racine Non autorisé Non autorisé Autorisé (mais pas directement depuis d autres serveurs) 4.3 Modifier les données du compte L OMM contraint l utilisateur à remplacer les données du compte par défaut par ses propres réglages. Tant qu il n aura pas modifié les mots de passe, l OMM ne lui permettra aucune autre opération de configuration. Pour modifier le mot de passe, il faut encore une fois entrer l ancien mot de passe. L OMM applique diverses règles pour contrôler la complexité du nouveau mot de passe. Un nouveau mot de passe sera rejeté si une des règles suivantes n est pas respecté: Le nouveau mot de passe ne comporte pas au moins 5 caractères Aastra depl-0900/0.4 Page: 75 (108)

76 Le nouveau mot de passe ne contient pas des caractères appartenant au moins aux trois groupes suivants : Minuscule, majuscule, chiffres ou autres caractères. Le mot de passe est composé à 50% ou plus du même caractère ('World11111' ou 'W1o1r1l1d1') ou Le nouveau mot de passe contient l un des objets suivants (soit majuscule ou minuscule ainsi que en avant ou en arrière) : Nom du compte Nom du serveur (adresse IP) Ancien mot de passe ou Quelques frappes de caractères voisins (p. ex. "qwert"). 4.4 Pièges potentiels Un RFP qui est configuré via l'om Configurator et retiré de l installation peut devenir inutilisable: Lorsque ce RFP démarre, il décèle en effet une configuration censée être valide dans sa mémoire permanente. Il va par conséquent sauter le DHCP pour démarrer. Or si cette configuration n est plus valable (le serveur TFTP a une nouvelle adresse IP entre temps, par exemple), le RFP en peut plus démarrer et n est donc plus en mesure de se connecter à l OMM. Le RFP n obtient plus les nouveaux mots de passe de l OMM. il est par conséquent recommandé de désactiver la configuration OM avant de retirer un RFP d une installation. L'OM Configurator permet néanmoins de réinitialiser la mémoire permanente d'un RFP (l'assistance Aastra DeTeWe doit être connectée). Aastra depl-0900/0.4 Page: 76 (108)

77 5 Résilience de l OMM Pour garantir la résilience de l OMM, il faut mettre en place deux gestionnaires OpenMobility dans un réseau OMM. L un sera l OMM «maître» et l autre l OMM résilient ou en veille. En cas de défaillance du RFP désigné comme OMM, l autre RFP désigné comme OM secondaire reprendra automatiquement la fonction d OpenMobility Manager. 5.1 Fonctionnement de la résilience OMM Durant le démarrage du système, chaque RFP IP détecte une (sans résilience OMM) ou deux (si la résilience OMM est configurée) adresses IP OMM et cherche à les relier entre elles. L'OMM actif ou «maître» servira toutes les connexions des RFP. L OMM résilient ou en veille refusera toutes les tentatives de connexion des RFP. 5.2 Introduction En mode d exploitation normal, à la fois l OMM actif et l OMM en veille/résilient sont en contact et surveillent mutuellement leur état d exploitation. Ils échangent continuellement leurs états de résilience actuels et l'omm en veille reçoit une copie de toute modification de la configuration sur l'omm actif. Dans la mesure où les deux OMM sont en contact entre eux, leurs bases de données sont automatiquement synchronisées. En cas de défaillance de l OMM principal, l OMM en veille prend ses fonctions en charge afin de maintenir le fonctionnement du système. Un avertissement «Pas de résilience» s'affiche sur l interface web OMM pour signaler que seul un des OMM du réseau ou de la grappe fonctionne encore. Dans cette situation, les modifications de la configuration ne sont pas sécurisées. Quand l OMM actif connaît une défaillance, l OMM inactif la reconnaît et agit comme l'omm actif. Le service Web est lancé simultanément. Tous les RFP IP suivis par l OMM sont redémarrés et toutes les unités mobiles sont resynchronisées. En cas de défaillance de la connexion entre deux OMM, le réseau ou la grappe se fractionne pour l essentiel en deux composantes opérationnelles. L OMM résilient ou en veille devient l OMM actif. A ce stade, les deux OMM ne sont pas en mesure d en détecter en autre et ne sont par conséquent pas en mesure de se synchroniser. Quand la connexion entre les deux OMM est établie, la synchronisation des OMM force l'un des deux à reprendre l'état de veille. Une fois que l'omm qui vient de tomber en panne reprend du service et devient l'omm inactif, il ne reprend plus le rôle de l'omm actif. 5.3 Configurer la résilience de l OMM Tout RFP du système DECT doit être configuré avec deux adresses IP OMM. Ces deux adresses OMM peuvent être configurées soit par DECT (voir chapitre ), soit à l aide du configurateur OM (voir chapitre 3.2 ). Aastra depl-0900/0.4 Page: 77 (108)

78 5.4 Situations de relayage Le relayage intervient dans les circonstances suivantes : - Une erreur OMM se produit sur l'omm actif - Le RFP faisant office d OMM actif est arrêté ou redémarré sur la console ssh - L OMM est redémarré dans le menu du navigateur Web. - L'OMM actif est inaccessible L OMM résilient ou en veille devient l'omm actif dans les circonstances suivantes: - Le proxy/serveur d enregistrement configuré peut être atteint - L'autre OMM a une adresse IP plus volumineuse tandis qu'aucun OMM n'est actif ou que les OMM sont en contact entre eux (au démarrage du système en temps normal). Quand les OMM reprennent contact : - Les deux OMM contrôlent lequel a fonctionné pendant une période prolongée. Celui-ci deviendra l OMM actif. L autre retombe au statut de repos. 5.5 Situations de défaillance de relayage La défaillance de relayage intervient dans les circonstances suivantes : - La connexion IP entre les OMM échoue et le proxy/serveur d enregistrement SIP configuré ne répond pas. Dans ce cas, l OMM actif doit attendre jusqu à ce que le proxy/serveur d enregistrement SIP réponde. Le schéma ci-après présente les différents états de résilience OMM : Aastra depl-0900/0.4 Page: 78 (108)

79 OMM Reset with exit code 46 OMM sync NOK and PBX reachable OMM Start up or Restart OMM star up sync OK OMM Reset with exit code 45 OMM sync NOK and PBX unreachable PBX not reachable (registration and OPTIONS request failes) Unsynchronised Inactive OMM OMM sync OK OMM sync NOK Synchronised Inactive OMM OMM sync OK other OMM is active PBX reachable (registration or OPTIONS request OK) No OMM is active and I have the lowest IP address PBX not reachable (registration and OPTIONS request failes) Unsynchronised Active OMM OMM sync OK OMM sync NOK Synchronised Active OMM Another OMM is running for a longer period In this state the DECT air interface might not be in a definite state, when both OMMs are active but do not see each other! In this case a network problem occurs (broken into two parts) which is very theoretical and we can not handle. There might be two DECT systems with the same PARK active. For this case it is random which RFP is connected to the one or to the other OMM. In this state hand over might be reduced (not all RFPs might be synchronised). OMM sync OK only one OMM is active OMM sync OK means: OMMs are synchronised with each other and are able to exchange their operational states OMM sync NOK means: OMMs are not synchronised with each other and are not able to exchange their operational states 5.6 Situations de résilience spécifiques Certains aspects doivent être examinés dans le cas où l OMM changerait d état pendant qu ils ne sont pas synchronisés Comment un OMM résilient devient-il actif? Comme l illustration ci-dessus l indique, dans le cas d un OMM non synchronisé, l OMM en veille doit décider s il devient actif ou non. A cet effet, l OMM tente de contacter le proxy et le serveur d enregistrement SIP configurés. L OMM lance une inscription SIP pour le combiné présentant le plus faible numéro de téléphone et envoie une requête OPTIONS au proxy configuré. S il obtient une réponse, le proxy/serveur d enregistrement SIP sera considéré comme joignable et l OMM deviendra actif Procédure quand aucun des deux OMM n est synchronisé Dans un état de résilience OMM non synchronisée, la connexion entre les deux OMM est interrompue. Les deux OMM peuvent se trouver dans cet état en cas de problème de réseau. Pendant ce laps de temps, un système OpenMobility inconsistant fonctionnera avec certaines contraintes. Aastra depl-0900/0.4 Page: 79 (108)

80 Le service Web émettra l avertissement «Pas de résilience» pour les deux OMM dans cette situation et les éventuels changements de la configuration opérés ne seront pas sauvegardés. Dans tous les cas, quand les deux OMM entrent en contact mutuel, celui qui a fonctionné le plus longtemps devient l'omm actif et cette information écrasera le fichier base de données de l'omm en veille. Les configurations opérées sur cet OMM passant en veille seraient perdues Deux interfaces aériennes DECT Si les deux OMM sont dans un état actif et non synchronisés, ils fonctionnent tous les deux pleinement. Les RFP qui perdent leur connexion avec leur OMM en raison de la panne de réseau peuvent se connecter à l autre OMM. Deux interfaces DECT aériennes seront présentes mais fonctionneront en parallèle. Note: Ces deux interfaces aériennes utilisent le même code PARK. Il ne sera donc pas possible de déterminer quelle inscription OMM réussira. Différentes situations sont envisageables pour les portatifs: - Ils ne remarquent pas cette situation. o Les communications actives sont maintenues en fonction des conditions de réseau. o Les portatifs peuvent passer et recevoir de ne nouveaux appels en fonction de la disponibilité d une connexion PBX disponible. o Les portatifs peuvent effectuer des passations aux RFP connectés au même OMM. o Les portatifs peuvent appeler les portatifs inscrits auprès de l autre OMM. - Ils perdent leur station de base RFP et procèdent à un nouvel enregistrement de cellule. o Les communications en cours sont coupées. o Les portatifs peuvent passer et recevoir de ne nouveaux appels en fonction de la disponibilité d une connexion PBX disponible. o Les portatifs peuvent effectuer des passations aux RFP connectés au même OMM. o Les portatifs peuvent appeler les portatifs inscrits auprès de l autre OMM. - Ils perdent leur station de base RFP et recherchent le réseau DECT sans en trouver un autre. o Les communications en cours sont coupées. o Les portatifs restent en mode de recherche de réseau jusqu à ce qu'une interface aérienne redevienne disponible. Note: Les passations entre portatifs rattachés à des RFP contrôlés par des OMM différentes ne sont pas possibles. Aastra depl-0900/0.4 Page: 80 (108)

81 Quand les OMM reprennent le contact entre eux, cette situation inconsistante du système OpenMobiliy prend fin. Aastra depl-0900/0.4 Page: 81 (108)

82 6 Téléchargement OTA Cette fonctionnalité permet de mettre à jour le logiciel du combine sans aucune intervention de l'utilisateur ni interruption des services de téléphonie, via l'interface aérienne DECT existante. Elle est disponible actuellement sur les combinés types 610d, 620d et 630d. 6.1 Comment fonctionne le téléchargement OTA Si la fonctionnalité de Téléchargement OTA est active, l'omm joue le rôle de serveur de téléchargement qui fournit le logiciel nécessaire pour les téléchargements. Le PP envoie le numéro de version du logiciel installé dans le cadre de la procédure d'attachement DECT. Si la version logicielle indiquée ne correspond pas à la version fournie par l'omm, le PP sera placé en file d'attente dans la file des mises à jour. Par la suite, les PP présents dans la file d'attente seront recherchés afin d'établir une connexion pour le téléchargement. Une fois la connexion établie, l'omm transmets sa version logicielle PP et le PP demandera un fichier de description du combiné. Après avoir reçu le fichier de description du combiné, le PP détermine quels sont les fichiers manquants ou les fichiers à mettre à jour. S'il manque des fichiers ou si certains fichiers doivent être mis à jour, le PP déclenche la procédure de téléchargement. L'OMM prend automatiquement en charge les scénarios de téléchargement suivants. Si un combiné est injoignable, lorsque, par exemple, il est éteint, l'omm procédera à la mise à jour de celui-ci dès que le PP redeviendra disponible. L'OMM se chargera du téléchargement du logiciel alors que l'utilisateur se déplace entre des stations de base (itinérance) et des zones de localisation. L'OMM a également la possibilité de reprendre un téléchargement là où il a été interrompu, si par exemple sort d'une zone de couverture pendant le téléchargement ou si la batterie du combiné se trouve déchargée. L'OMM met à jour les nouveaux combinés inscrits dans le système. Le téléchargement sera différé, tant que le combiné est indisponible (à cause d'un problème de batterie ou parce que le téléchargement OTA est désactivé au niveau du menu local). Le téléchargement s'effectue sans aucune intervention de l'utilisateur. Pendant le téléchargement, les services de téléphonie, roaming ou itinérance et procédures de transfert restent disponibles. Le téléchargement s'arrête automatiquement lorsque, par exemple, le PP sort de la zone de couverture Aastra depl-0900/0.4 Page: 82 (108)

83 ou si le RFP est occupé. Il reprendra automatiquement lorsque la cause de l'interruption a disparu. Les combinés 610d / 620d / 630d comprennent deux partitions en mémoire flash interne, de manière à pouvoir héberger 2 versions logicielles différentes. Pendant le téléchargement, le nouveau logiciel est enregistré dans l'une des partitions et le PP continue de fonctionner sur l'autre partition. Le nouveau logiciel ne sera pas activé tant que - Le téléchargement n'est pas complètement terminé, - Et qu'un contrôle de cohérence n'a pas été réalisé avec succès. - Le combiné est à l'état de veille. Le téléchargement d'un logiciel d'environ 1 Mo sur un seul PP dure environ 90 minutes. Le téléchargement peut être "refusé" par le combiné pour plusieurs raisons : Batterie faible La charge de la batterie est inférieure à 50% et le PP n'est pas connecté à la base ou à l'interface USB. Interdiction logicielle L'option Téléchargement OTA est désactivée dans le menu local du combiné Echec du téléchargement Le nombre d'échecs du téléchargement est trop élevé. Systèmes multiples Un PP peut être déclaré sur plusieurs systèmes OpenMobility. Le premier système sur lequel le combiné sera déclaré, sera automatiquement le "système Maître". Le PP n'effectuera ses téléchargements que depuis le "système maître". Il est possible de sélectionner un autre "système Maître" à partir du menu local du combiné. Le nombre de PP qui peut être téléchargés dépend des ressources système disponibles. 6.2 Configuration du téléchargement OTA La fonctionnalité Téléchargement OTA peut être activée ou désactivée à partir de la page Web "Configuration système". Aastra depl-0900/0.4 Page: 83 (108)

84 Le micrologiciel ou firmware du PP fait partie du progiciel OpenMobility fourni par Aastra. Le micrologiciel du PP est situé dans l'ensemble de fichiers progiciel aafon6xxd.dnld. Cet ensemble de fichiers progiciel doit être sur le même serveur tftp et au même emplacement que celui où se trouve le fichier image d'amorçage de l'omm-rfp (ex. omm_ffsip.tftp). Important : Pour qu'un nouveau logiciel pour combiné puisse être mis sur un serveur tftp, la fonctionnalité Téléchargement OTA doit être désactivée sur la page web Configuration système. Une fois la copie ou l'installation terminée, la fonctionnalité Téléchargement OTA peut être ré-activée. Le service de téléchargement OTA est retardé pendant un certain temps après le démarrage du système, pour être active pour l'ensemble du système DECT. Ceci peut prendre plusieurs minutes. Si la fonctionnalité Téléchargement OTA est active, l'état du service Téléchargement OTA ainsi que certaines statistiques s'affichent sur la page Web "Etat". L'état du téléchargement de chaque PP s'affiche sur la page Web "Portatif". Aastra depl-0900/0.4 Page: 84 (108)

85 Le terminal est occupé. Aastra depl-0900/0.4 Page: 85 (108)

86 Les différentes icônes et les textes de la colonne "Téléchargement" correspondent à la description suivante : Téléchargement Définition - Impossible de télécharger le logiciel sur le combiné (p.ex. 610d, 620d ou 630d absent) Il reste xx Koctets Le système recherche le PP pour établir une connexion en vue du téléchargement. Si le système parvient à établir a connexion, le PP calcule le nombre d'octets à télécharger. Ceci peut prendre plusieurs secondes. Téléchargement en cours et il reste xx Koctets à télécharger. Le logiciel de ce PP est à jour. Le PP figure dans la file d'attente pour mise à jour (en attente). Avertissement. Le téléchargement est impossible pour l'une des raisons suivantes : - Le PP est occupé (état provisoire) - La batterie est faible - Il ne s'agit pas du système maître pour le téléchargement - Le téléchargement est désactivé au niveau du combiné. La raison précise est indiquée à l'aide d'une infobulle. Erreur Le téléchargement a échoué pour l'une des raisons suivantes : - Erreur de total de contrôle - Erreur au niveau du système de fichiers - Erreur lors de l'écriture du logiciel en mémoire flash - Erreur au niveau des versions - Erreur lors de la décompression du logiciel La raison précise est indiquée à l'aide d'une infobulle. Info Le téléchargement est impossible car : - le combiné n'est pas joignable - le combine est décroché La raison précise est indiquée à l'aide d'une infobulle. Aastra depl-0900/0.4 Page: 86 (108)

87 Aastra depl-0900/0.4 Page: 87 (108)

88 7 Maintenance 7.1 Equipement de mesure et d'expertise du site Si une installation SIP-DECT doit être prévue, une distribution suffisante de RFP est nécessaire, remplissant les conditions pour une synchronisation et une connectivité fiable des portatifs. Le kit d'expertise de site peut aider. Il comprend: Un RFP de mesure, avec sa propre alimentation. Un trépied et une batterie pour le RFP. Deux portatifs de référence avec chargeurs. Chargeurs de batteries. En option, un combiné de mesure, capable d'observer les sources radio des DECT d'autres marques. 7.2 Vérification de la version logicielle du combiné Aastra DECT 142 / Aastra 142d Il est possible d'afficher les informations sur la version du Aastra DECT 142 Handset / Aastra 142d en quelques clics. Vérifier la version firmware pour déterminer si une mise à niveau est nécessaire pour résoudre des problèmes utilisateur. 1. Appuyer sur la touche programmable Menu 2. Sélectionner Systèm (seulement pour mettre en surbrillance) 3. Appuyer sur OK. 4. Sélectionner Numéro version 5. Appuyer sur OK. Les versions logicielles et matérielles de l Aastra DECT 142 Handset / Aastra 142d s'afficheront. 7.3 Diagnostique Mode expertise site de l'aastra DECT 142 / Aastra 142d Il est possible de mettre le Aastra DECT 142 / Aastra 142d en "mode expertise site" en quelques clics. Dans ce mode, le téléphone affichera les RFP et la puissance de champ réelle du signal reçu en dbm. 1) Appuyer sur la touche programmable Menu 2) Entrer la séquence suivante R***76# 3) Sélectionner Site Survey 4) Appuyer sur OK. Pour quitter le mode expertise site, éteignez puis rallumez le téléphone. L'écran suivant est affiché sur l Aastra DECT 142 Handset / Aastra 142d: Aastra depl-0900/0.4 Page: 88 (108)

89 PARK: 1F-10-FF-F0-21 RFP ID: 02* RFPI 10FFF21 02 Frame error FE PP: FP: Field strength RFP ID -dbm RPN Menu Phonebook RFP ID: 02* *The ID of RFP to which the PP is currently associated to. Dans cet exemple le PP est actuellement connecté au RFP numéro 02. Le RFP 01 et 00 sont également visibles. Le numéro 10FFF en haut à droite correspond au PARK (Exemple 1F-10-F2-21) du système SIP-DECT et au RFP auquel le téléphone est actuellement connecté Mode test appel automatique Aastra DECT 142 / Aastra 142d Il est possible de mettre le Aastra DECT 142 / Aastra 142d en "mode test appel automatique" en quelques clics. Dans ce dernier, le téléphone appelle en boucle un numéro déterminé. Cette fonctionnalité peut être utilisée pour générer un trafic pour effectuer des tests. Ce mode est également activé lorsque le téléphone est sur le chargeur. 1) Appuyer sur la touche programmable Menu 2) Entrer la séquence suivante R***76# 3) Sélectionner Auto Call Test 4) Appuyer sur OK. 5) Composer le numéro de téléphone à appeler 6) Appuyer sur OK. 7) Entrer la durée en secondes entre deux appels. 8) Appuyer sur OK. 9) Entrer la durée en secondes de chaque appel. 10) Appuyer sur OK. Le test commencera automatiquement. Pour arrêter le test, éteignez puis rallumez le téléphone Mode test réponse automatique de l'aastra DECT 142 / Aastra 142d Il est possible de mettre le Aastra DECT 142 / Aastra 142d en "mode test réponse automatique" en quelques clics. Dans ce dernier, le téléphone répond aux appels automatiquement. Cette fonctionnalité peut être utilisée en complément de téléphones en "mode test appel automatique". Ce mode est également activé lorsque le téléphone est sur le chargeur. Aastra depl-0900/0.4 Page: 89 (108)

90 7.3.4 Syslog 1) Appuyer sur la touche programmable Menu 2) Entrer la séquence suivante R***76# 3) Sélectionner Auto Answer 4) Appuyer sur OK. 5) Entrer la durée en secondes avant que le téléphone ne réponde à l'appel. 6) Appuyer sur OK. 7) Entrer la durée en secondes de chaque appel. 8) Appuyer sur OK. Le test commencera automatiquement. Pour arrêter le test, éteignez puis rallumez le téléphone. L OpenMobility Manager ainsi que les RFP sont capables de propager des messages syslog conformément à /8/. Cette fonctionnalité, ainsi que l'adresse IP d'un hôte collectant ces messages, peut être configurée. Syslog est activé lorsque DHCP utilise options publiques 227 et 228. Le serveur et port daemon syslog sont configurés via l'interface web. La mise en place du syslog via DHCP ou OM Configurator est intéressante car les syslog sont disponibles dès les premières phases du démarrage du RFP. Le niveau de messages syslog dans l'état par défaut permet à l'utilisateur d'avoir le contrôle de l'état général du système et des échecs majeurs. Aastra depl-0900/0.4 Page: 90 (108)

91 7.3.5 shell utilisateur ssh Chaque RFP propose une série de commande dans le shell ssh. La plupart d'entre elles servent au diagnostic et peuvent aider les experts à résoudre des problèmes. Note: Certaines commandes peuvent nuire à l exploitation du système. L'accès ssh d'un RFP est ouvert si - le RFP est connecté à un OMM et que l'accès à distance est commuté sur EN - le RFP n'est pas connecté à un OMM Il faut cocher la case "Accès à distance" de la page web de configuration du système OMM pour activer l'accès ssh d'un RFP connecté à un OMM Ouverture de session La procédure est: ouvrir la session ssh vers la station de base DECT IP avec le nom d utilisateur Accès complet et entrer le mot de passe pour l'accès complet L'affichage qui en résulte aura l'aspect suivant: Bienvenue sur IP RFP OpenMobility SIP, uniquement version 1.6.x Juin :12:16 Release (BUILD 0) cause de la dernière réinitialisation: réinitialisation hardware (Power-on reset) Aastra depl-0900/0.4 Page: 91 (108)

92 mot de passe de > Vue d ensemble des commandes Tapez help pour afficher la vue d ensemble des commandes: exit,quit,bye : ferme la session ommconsole : console omm ip_rfpconsole : console rfp flash : affiche les informations de la mémoire flash link : affiche l'état de l'interface ethernet ldb : affiche / fixe la configuration locale (OmConfigurator) setconsole : duplique les messages vers la console noconsole : ne duplique pas les messages vers la console dmesg : messages du dernier boot logread : derniers messages su : commute sur l'utilisateur root ping : la commande bien connue ping traceroute : la commande bien connue traceroute free : la commande bien connue free ps : la commande bien connue ps top : la commande bien connue top ifconfig : la commande bien connue ifconfig uptime : la commande bien connue uptime reboot : la commande bien connue reboot Commandes de la console RFP Si vous tapez ip_rfpconsole, vous pouvez utiliser les commandes suivantes sur chaque RFP: heap - affiche les statistiques du tampon heap help - affiche la table d'aide des commandes lec - ajuste les paramètres de l'inhibiteur d'écho linéaire media - affiche l'état des canaux média mutex - liste toutes les exclusions mutuelles MXP créées mutex - liste toutes les files d'attente MXP créées reset - réinitialise l application IPRFP rsx - permet la connexion RSX vers BMC via le TCP sem - liste tous les sémaphores MXP créées spy - définit/affiche les niveaux spy: [ <key #> <level #> ] tasks - liste toutes les tâches MXP en cours d'exécution voice - affiche l'état du traitement de la voix exit - ferme la console IP-RFP Note:La commande spy vous permet d'augmenter le niveau des messages syslog. Elle ne devrait être utilisée que sur ordre de l organisation de support car elle peut nuire à l exploitation du système. Aastra depl-0900/0.4 Page: 92 (108)

93 Commandes de la console OMM Si vous avez ouvert une session sur l'omm RFP et que vous tapez ommconsole, vous pouvez utiliser les commandes suivantes en rapport avec l'openmobility Manager (OMM) related commands: > ommconsole Bienvenue sur la console omm, tapez? pour voir la liste des commandes possibles omm# help Commande Description ? Affiche la table d'aide des commandes cmi commandes cmi cnf affiche les paramètres de configuration dsip commandes dsip help affiche la table d'aide des commandes exit quitte cette console heartbeat configurer le mécanisme de pulsation pour les IP-RFP ipc affiche le socket de communication ipl affiche les RFP configurés ki Moniteur KI quit quitte cette console logger envoie une chaîne au démon syslog mon bascule la fonctionnalité du moniteur msm affiche les états dans le MediaStreamManagement mutex liste toutes les exclusions mutuelles MXP créées queues liste toutes les files d'attente MXP créées rspy configure à distance les niveaux spy sur les IP-RFP rsx affiche les RFP configurés sem liste tous les sémaphores MXP créées spy définit/affiche les niveaux spy: [ <key #> <level #> ] standby affiche les OMM redondants sync commandes de synchronisation des RFP tasks liste toutes les tâches MXP en cours d'exécution tasks liste toutes les tâches MXP en cours d'exécution tzone commandes tzone uptime affiche l'uptime système ver information de version wlan affiche les états de la gestion du réseau sans fil omm# Aastra depl-0900/0.4 Page: 93 (108)

94 Note:La commande spy vous permet d'augmenter le niveau des messages syslog, spécialement pour les sous-systèmes de l'omm. Elle ne devrait être utilisée que sur ordre de l organisation de support car elle peut nuire à l exploitation du système Core file captchering L'OMM est à même de générer un dump de la mémoire en cas d'erreur fatale de l'omm et de panne du logiciel. Vous contribuez à résoudre ces problèmes en envoyant les fichiers ainsi générés au service de support. L'OMM est capable de stocker ces fichiers core sur un serveur TFTP dans votre réseau local. Pour permettre la création de fichier core, tapez dans la ligne de commande OMM: local_db core=yes local_db core_srv=server-ip adresse IP serveur TFTP local_db core_path=path chemin du fichier sur le serveur TFTP (avec droit à l'écriture) Si aucun local_db_core_srv etlocal_db_core_path n'est spécifié, l'omm tente d'enregistrer les fichiers core sur le serveur TFTP, dans le répertoire où l application OMM/RFP a été téléchargée. Les fichiers sont automatiquement transférés sur le serveur TFTP après redémarrage de l'omm. Nota:le serveur TFTP doit autoriser l enregistrement de nouveaux fichiers, ce qui n'est habituellement pas le réglage par défaut. Pour désactiver le core file captchering writer, tapez sur la ligne de commande: local_db core= Suivi DECT Le moniteur DECT peut être utilisé pour mieux détecter les erreurs sur le système IP DECT. Le moniteur DECT est un programme autonome tournant sous MS Windows. Il permet d'obtenir une vision en temps réel de la station de base DECT IP actuelle et des états des téléphones dans le système DECT IP. Le moniteur DECT offre les fonctionnalités suivantes: extraire la configuration DECT d'un système DECT IP la configuration peut être enregistrée dans un fichier ASCII. affichage des transactions DECT entre la station de base DECT IP et le téléphone, avec mise en évidence des situations de passation. Affichage en temps réel. affichage d'autres événements en rapport avec l'état des stations de base DECT IP et des téléphones sur le système DECT IP. Aastra depl-0900/0.4 Page: 94 (108)

95 tous les événements peuvent également être enregistrés dans un fichier journal affichage des relations de synchronisation entre les RFP surveillance de systèmes comptant jusqu'à 256 stations de base DECT IP et 512 PP extraction et affichage des données statistiques RFP DECT IP, soit pour un seul RFP DECT IP, soit pour tous les RFP DECT IP. affichage de données centrales DECT du système DECT IP. Le programme de surveillance DECT peut uniquement être utilisé si le flag de surveillance DECT est activé dans la configuration système OMM. Nota: Pour des raisons de sécurité, le flag de surveillance DECT n'est pas enregistré de manière permanente dans la mémoire flash interne de l'omm/rfp. Le flag de surveillance DECT est désactivé après une réinitialisation. Le programme de surveillance DECT est utilisé conjointement au système DECT IP. Lorsque le programme est lancé, l'utilisateur est invité à saisir l'adresse IP du RFP DECT IP ou du serveur exécutant le logiciel OpenMobility Manager (OMM). L'échec de l'établissement de la liaison peut avoir plusieurs raisons: l exploitation du moniteur DECT n'est pas activée dans l'omm. Utilisez le service web pour autoriser l exploitation du moniteur DECT. l'adresse IP n'est pas correcte. Il doit s'agir de l'adresse du RFP sur lequel est exécuté l'omm une connexion acheminée vers le RFP n'est pas prise en charge. Le programme affiche l'adresse IP utilisée la dernière fois. Lorsque le programme est exécuté, une connexion est automatiquement établie vers l'omm et la fenêtre du programme montre toutes les fenêtres et tables subordonnées configurées par l'utilisateur. Aastra depl-0900/0.4 Page: 95 (108)

96 Lorsque toutes les connexions ont été établies, les données DECT du système sont automatiquement extraites et enregistrées dans les tables "RFP-Table" et "PP-Table". Cette procédure est appelée "Config Request". Les options de traçage définies (Event Mask) sont ensuite envoyées à l'omm. Les options envoyées à l'omm sont toujours celles qui étaient actives lorsque le programme a été fermé pour la dernière fois. Si l'option de traçage "Transaction establish/release" est active, l'omm délivrera toutes les transactions existantes. Par conséquent, le système OMM livre les données de traçage désirées. L'utilisateur peut soit communiquer interactivement avec le programme (voir ci-dessous), soit simplement activer un fichier journal dans lequel seront enregistrées les données. A la suite de cette initialisation, l'utilisateur peut procéder aux modifications suivantes: les réglages de traçage peuvent être modifiés à l'aide la rubrique de menu Options Event Mask. La transmission vers l'omm a lieu après confirmation des réglages avec <OK>. une Config Request peut encore être envoyée à l'omm. il est possible d'activer un fichier journal. diverses boîtes de dialogue permettent d'afficher et d'enregistrer dans des fichiers ASCII les données de configuration des téléphones, des RFP et des modules de contrôle. Les informations suivantes sont affichées de manière dynamique dans les tables: Aastra depl-0900/0.4 Page: 96 (108)

97 transactions entre le téléphone et le système DECT. Elles sont affichées dans les deux tables. Les transactions simples sont affichées en noir sur fond blanc; durant la passation, les deux transactions impliquées sont affichées en blanc sur fond rouge. les événements Location Registration et Detach sont, dans la mesure du possible, affichés dans les tables environ 1 à 2 s après leur occurrence (fond en vert clair). Il n'y aucun affichage dans la table FP s'il n'y a plus de colonne libre. Un événement qui a déjà été affiché peut être écrasé à tout moment. Les événements ne sont pas affichés s'ils surviennent durant une transaction en cours. Que les événements soient affichés ou non dans les tables, ils sont toujours saisis dans la fenêtre des événements FP/PP et dans le fichier journal (à condition qu'il soit ouvert). La combinaison de couleurs suivante est utilisée pour afficher les RFP dans la table RFP: RFP gris-bleu La station de base DECT IP n'est pas active (pas connectée ou en dérangement) RFP noir La station de base DECT IP est active Les données d'un RFP sont affichées dans une boîte de dialogue après un clic sur champ du RFP correspondant dans la table RFP. Les données statistiques du RFP peuvent être appelée depuis cette boîte de dialogue. La combinaison de couleurs suivante est utilisée pour afficher les téléphones dans la table RFP: PP noir Le combiné est déclaré. Il est supposé que le téléphone est accessible. PP bleu Le combiné ne peut vraisemblablement pas être atteint. Un Detach a été reçu ou le combiné ne répond pas lorsque l'on tente d'atteindre un téléphone. PP gris bleu Combiné pas déclaré. Les données d'un téléphone sont affichées dans une boîte de dialogue après un clic sur champ du téléphone correspondant dans la table RFP. La fenêtre subordonnée Sync Info contient toutes les stations de base DECT IP et montre leurs états de synchronisation et de relation entre elles. En sélectionnant des stations de base DECT IP avec le bouton droit de la souris, l'utilisateur peut changer la vue et même forcer une resynchronisation d'une station de base DECT IP. Facultativement, il est possible de sélectionner différentes fenêtres subordonnées. Elles sont énumérées ci-après et fournissent diverses informations sur le système DECT IP. Il s'agit le plus souvent de statistiques et d'informations à usage uniquement interne. Aastra depl-0900/0.4 Page: 97 (108)

98 Aastra depl-0900/0.4 Page: 98 (108)