Installation, Administration et Maintenance de la solution

Transcription

Installation, Administration et
Maintenance de la solution DECToverIP
using SIP
Release 1.7
Document ID: depl-0900
Version: 0.4
Aastra
Zeughofstr. 1
10997 Berlin, Allemagne
Juin 2008- 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
Installation, Administration et Maintenance
de la solution
Table des matières
1
PRÉSENTATION GÉNÉRALE ....................................................................................................................... 4
1.1
OBJECTIF .................................................................................................................................................... 4
1.2
DÉCLARATION DE CONFORMITÉ ................................................................................................................. 4
1.3
ABRÉVIATIONS ET DÉFINITIONS ................................................................................................................. 4
1.3.1
Abréviations ................................................................................................................................ 4
1.3.2
Définitions................................................................................................................................... 4
1.4
RÉFÉRENCES .............................................................................................................................................. 7
2
INTRODUCTION .............................................................................................................................................. 8
2.1
A PROPOS DE DECTOVERIP USING SIP LA SOLUTION ................................................................................ 8
2.2
A PROPOS DES POINTS D'ACCES (RFP)....................................................................................................... 9
2.3
OPENMOBILITY MANAGER ...................................................................................................................... 12
2.4
SIGNAL IP ET FLUX MÉDIA ....................................................................................................................... 12
2.5
SYNCHRONISATION RFP .......................................................................................................................... 15
2.6
CAPACITÉ CANAUX RFP .......................................................................................................................... 16
2.7
A PROPOS DES PARTIES PORTABLES ......................................................................................................... 18
2.8
CAPACITÉS SYSTÈME ............................................................................................................................... 19
3
INSTALLATION ET CONFIGURATION.................................................................................................... 20
3.1
DÉMARRAGE OPENMOBILITY .................................................................................................................. 20
3.1.1
Démarrage des RFPs’................................................................................................................ 20
3.1.1.1
3.1.2
3.1.3
3.1.3.1
3.1.3.1.1
3.1.3.1.2
3.1.3.1.3
3.1.3.2
3.1.4
Mise à jour Booteur.................................................................................................................25
Sélection du serveur DHCP adéquat .......................................................................................25
3.1.5
Statut LED du RFP.................................................................................................................... 26
3.1.6
Graphique d'état des phases de démarrage ................................................................................ 28
CONFIGURATION LOCALE STATIQUE D'UN RFP ........................................................................................ 29
CONFIGURATION DE OPENMOBILITY MANAGER...................................................................................... 34
3.3.1
Procédure de Connexion Service .............................................................................................. 34
3.3.2
System ....................................................................................................................................... 37
3.3.2.1
3.3.2.1.1
3.3.2.1.2
3.3.2.1.3
3.3.2.2
3.3.2.3
3.3.2.4
3.3.2.5
3.3.2.5.1
3.3.2.5.2
3.3.2.5.3
3.3.2.5.4
3.3.3
3.3.4
Configurations système ...........................................................................................................37
Redémarrage du OMM ...........................................................................................................38
Encryptage ..............................................................................................................................39
Domaine Règlementaire..........................................................................................................39
SIP...........................................................................................................................................39
Compte Utilisateur ..................................................................................................................43
Fuseaux Horaires.....................................................................................................................43
Gestion de la base de données .................................................................................................45
Importation manuelle de la base de données...........................................................................46
Exportation manuelle de la base de données...........................................................................47
Importation automatique de la base de données......................................................................48
Exportation automatique de la base de données......................................................................49
Configuration RFP .................................................................................................................... 50
3.3.3.1
3.3.3.1.1
3.3.3.1.2
3.3.3.1.3
3.3.3.2
3.3.3.3
3.3.3.4
Créer et modifier des RFP .......................................................................................................51
Touche Nouveau, Modifier et Effacer.....................................................................................51
Importation par le biais de fichiers de configuration...............................................................52
Capture de RFP.......................................................................................................................53
Etats d'un RFP .........................................................................................................................53
Type de matériel du RFP.........................................................................................................54
Vérification de version OMM / RFP SW ................................................................................54
Configuration des Parties Portables........................................................................................... 55
3.3.4.1
3.3.4.1.1
3.3.4.1.2
Aastra
Client DHCP ...........................................................................................................................21
Requête DHCP........................................................................................................................21
Offre DHCP ............................................................................................................................23
Répétition................................................................................................................................23
Client TFTP.............................................................................................................................23
Application ................................................................................................................................ 23
3.1.4.1
3.1.4.2
3.2
3.3
Description du Boot ................................................................................................................20
Démarrage du OpenMobility Manager ..................................................................................... 21
Booteur...................................................................................................................................... 21
Créer et modifier des portatifs.................................................................................................56
Touche Nouveau, Modifier et Effacer.....................................................................................56
Importation par le biais de fichiers de configuration...............................................................57
depl-0900/0.4
Page: 2 (108)
3.3.4.2
3.3.4.2.1
3.3.4.2.2
3.3.4.3
3.3.5
Inscription ...............................................................................................................................58
Inscription avec IPEI configurés.............................................................................................59
Inscription par caractère de substitution..................................................................................59
Recherche dans la liste des portatifs........................................................................................60
Configuration WLAN (RFP L42 WLAN uniquement)............................................................. 61
3.3.5.1
3.3.5.2
3.3.5.3
3.3.6
de la solution
Optimiser le WLAN ................................................................................................................63
Sécuriser le WLAN avec Radius. ............................................................................................64
Spécifications pour le WLAN .................................................................................................67
Caractéristiques système ........................................................................................................... 67
3.3.6.1
3.3.6.2
3.3.6.3
Configuration centrale de l'accès LDAP .................................................................................67
Traitement des chiffres............................................................................................................69
Codes d'accès aux fonctionnalités ...........................................................................................69
4
SÉCURITÉ........................................................................................................................................................ 71
4.1
LE CONCEPT DE SÉCURITÉ ........................................................................................................................ 71
4.2
TYPES DE COMPTES .................................................................................................................................. 71
4.3
MODIFIER LES DONNÉES DU COMPTE........................................................................................................ 72
4.4
PIÈGES POTENTIELS .................................................................................................................................. 73
5
RÉSILIENCE DE L’OMM ............................................................................................................................. 74
5.1
FONCTIONNEMENT DE LA RÉSILIENCE OMM ........................................................................................... 74
5.2
INTRODUCTION ........................................................................................................................................ 74
5.3
CONFIGURER LA RÉSILIENCE DE L’OMM ................................................................................................. 74
5.4
SITUATIONS DE RELAYAGE ....................................................................................................................... 75
5.5
SITUATIONS DE DÉFAILLANCE DE RELAYAGE ........................................................................................... 75
5.6
SITUATIONS DE RÉSILIENCE SPÉCIFIQUES ................................................................................................. 76
5.6.1
Comment un OMM résilient devient-il actif ? .......................................................................... 76
5.6.2
Procédure quand aucun des deux OMM n’est synchronisé....................................................... 76
5.6.2.1
Deux interfaces aériennes DECT ............................................................................................77
6
TÉLÉCHARGEMENT OTA .......................................................................................................................... 78
6.1
COMMENT FONCTIONNE LE TÉLÉCHARGEMENT OTA............................................................................... 78
6.2
CONFIGURATION DU TÉLÉCHARGEMENT OTA ......................................................................................... 79
7
MAINTENANCE.............................................................................................................................................. 83
7.1
EQUIPEMENT DE MESURE ET D'EXPERTISE DU SITE ................................................................................... 83
7.2
VERIFICATION DE LA VERSION LOGICIELLE DU COMBINE AASTRA DECT 142 / AASTRA 142D ................ 83
7.3
DIAGNOSTIQUE ........................................................................................................................................ 83
7.3.1
Mode expertise site de l'Aastra DECT 142 / Aastra 142d ......................................................... 83
7.3.2
Mode test appel automatique Aastra DECT 142 / Aastra 142d................................................. 84
7.3.3
Mode test réponse automatique de l'Aastra DECT 142 / Aastra 142d ...................................... 84
7.3.4
Syslog........................................................................................................................................ 85
7.3.5
shell utilisateur ssh .................................................................................................................... 86
7.3.5.1
7.3.5.2
7.3.5.3
7.3.5.4
7.3.6
7.3.7
8
Ouverture de session ...............................................................................................................86
Vue d’ensemble des commandes.............................................................................................87
Commandes de la console RFP ...............................................................................................87
Commandes de la console OMM ............................................................................................88
Core file captchering ................................................................................................................. 89
Suivi DECT ............................................................................................................................... 89
ANNEXE ........................................................................................................................................................... 94
8.1
INFORMATION SUR LA REGLEMENTATION DES COMMUNICATIONS POUR AASTRA DECT 142 US ........... 94
8.2
INFORMATION SUR LA REGLEMENTATION EN MATIERE DE COMMUNICATIONS POUR LES RFP 32 OU RFP 34
(NA) ........................................................................................................................................................ 96
8.3
REGLES POUR LES FICHIERS DE PRE-CONFIGURATION............................................................................... 98
8.3.1
Fichier de configuration portatif (base de données OMM) ....................................................... 99
8.3.1.1
8.3.1.2
8.3.1.3
8.3.2
Fichier de configuration RFP/ conf. centrale (base de données OMM) .................................. 101
8.3.2.1
8.3.2.2
8.3.2.3
8.3.3
Instructions supportées ..........................................................................................................101
Champs sections données......................................................................................................101
Exemple ................................................................................................................................101
Fichier de configuration RFP/ conf. centrale (OM Configurator) ........................................... 103
8.3.3.1
8.3.3.2
Aastra
Instructions supportées ............................................................................................................99
Champs sections données........................................................................................................99
Exemple ..................................................................................................................................99
Instructions supportées ..........................................................................................................103
Champs sections données......................................................................................................104
depl-0900/0.4
Page: 3 (108)
8.3.3.3
8.4
Aastra
de la solution
Exemple ................................................................................................................................104
PROTOCOLES ET PORTS .......................................................................................................................... 107
depl-0900/0.4
Page: 4 (108)
de la solution
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
1.3.1
Abréviations
AC
ADPCM
DHCP
DSP
Authentication Code
Adaptive Differential Pulse Code
Modulation
Digital Enhanced Cordless
Telecommunication
Dynamic Host Configuration Protocol
Digital Signal Processor
FCC
GAP
IPEI
HTTP
OMM
PARK
PP
SNMP
TFTP
RFP
RTCP
RTP
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
DECT
1.3.2
Définitions
Aastra DECT 142 Aastra DECT 142 Handset / Aastra 142d
Handset / Aastra Dans le contexte de cette solution DECToverIP using SIP
142d
, 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)
de la solution
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
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
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.
DECT
Digital Enhanced Cordless Telecommunication
• La norme (ETS 300 175) 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: 1880 – 1900 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:
•
•
•
Aastra
Gamme de fréquence: 1920 – 1930 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
depl-0900/0.4
Page: 6 (108)
•
•
GAP
Transfert
de la solution
Taux de données net par canal de 32 kbps
(pour transmission de voix utilisant ADPCM)
Codage voix utilisant la méthode ADPCM
Generic Access Profile
• GAP est l'abréviation de Generic Access Profile
•
La norme GAP (ETS 300444) 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
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).
IPEI
International Portable Equipment Identity
• Code d'identification à 13 chiffres pour portatif
• Exemple: 00019 0592015 3
00019 0592015 3 (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 SIPDECT.
Aastra
depl-0900/0.4
Page: 7 (108)
Roaming
de la solution
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)
de la solution
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)
2.2
de la solution
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)
-
-
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)
de la solution
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)
de la solution
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 ov er Ethernet
standard IEEE 802.3af
Power jack (120 V/230 V AC adapter)
RFP L42 WLAN
LED for WLAN
LED red (Booter)
Ethernet jack
Power supply in line with Power over Ethernet
Aastra
depl-0900/0.4
Page: 12 (108)
de la solution
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)
de la solution
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)
de la solution
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)
2.5
de la solution
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)
de la solution
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:
Aastra
•
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.
depl-0900/0.4
Page: 17 (108)
de la solution
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)
2.7
de la solution
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
Aastra DECT 142 (NA)
-
-
60 canaux duplex
-
100 mW (sortie maximale par canal actif)
-
5 mW (sortie moyenne par canal actif)
Aastra 142d (zone EMEA)
-
-
120 canaux duplex
-
250 mW (sortie maximale par canal actif)
-
10 mW (sortie moyenne par canal actif)
depl-0900/0.4
Page: 19 (108)
de la solution
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)
3
de la solution
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
3.1.1
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.
3.1.1.1 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)
de la solution
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.
3.1.2
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é.
3.1.3
Booteur
3.1.3.1 Client DHCP
Dans le processus initial de boot le client DHCP supporte les paramètres
suivants:
•
•
•
•
•
•
Adresse IP
Masque de réseau
Passerelle
Nom de fichier Boot
Serveur TFTP
Option Publique 224: “OpenMobility”
obligatoire
obligatoire
obligatoire
obligatoire
obligatoire
obligatoire
3.1.3.1.1 Requête DHCP
3.1.3.1.1.1 Identifiant classe fournisseur (code 60)
Le client DHCP envoie l'identifiant classe fournisseur “OpenMobility”.
3.1.3.1.1.2 Liste de requête paramètre (code 55)
Aastra
depl-0900/0.4
Page: 22 (108)
de la solution
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)
Aastra
depl-0900/0.4
Page: 23 (108)
de la solution
3.1.3.1.2 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é.
3.1.3.1.3 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.
3.1.3.2 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.
3.1.4
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 (0x63825363) ainsi que
l'option de fin(0xFF).
Aastra
depl-0900/0.4
Page: 24 (108)
de la solution
Les paramètres suivants sont supportés lors de cette étape:
Option / Champ
Définition
Obligatoire
yiaddr
Adresse IP du IP-RFP
oui
siaddr
Paramètre appelé Nom d'Hôte Serveur de Boot
possédant une valeur identique à l'adresse IP du
serveur TFTP
oui
file
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.
oui
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
Les Options Spécifiques au Fournisseur sont composées de:
Option
Spécifique au
Fournisseur
option 10
option 14
option 15
option 17
option 18
option 19
option 24
Définition
Longueur
Obligatoire
ommip1: Utilisé pour sélectionner le IPRFP où devrait résider le OpenMobility
Manager (OMM)
4
oui
syslogip: Adresse IP d'un Syslog
Daemon
syslogport: Port d'un Syslog Daemon
Pays: Utilisé pour sélectionner le pays
où l’OMM est situé. Ce paramétrage
autorise des tonalités spécifiques au
pays (tonalité d'occupation, de
numérotation...)
ntpservname: Nom d'un Serveur NTP
Ommip2: Utilisé pour sélectionner un
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 ).
rsturl: Restaurer URL
4
Non
2
2
Non
Non
x
4
Non
Non
x
Non
URL pour l'importation automatique de la
base de données de l'OMM (voir chapitre
3.3.2.5)
Un exemple de contenu minimum pour le paramètre Option 43 serait:
0a 04 C0 A8 00 01 où C0 A8 00 01 représente 192.168.0.1 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)
de la solution
0a = option 10 (ommip1)
04 = la valeur suivante a une longueur de 4 blocs
C0 A8 00 01 = 192.168.0.1
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
1
2
3
4
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
24
25
100
101
102
pays
Allemagne
Royaume Uni
Suisse
Espagne
Italie
Russie
Belgique
Pays Bas
Tchèque
Autriche
Danemark
Slovaquie
Finlande
Hongrie
Pologne
Biélorussie
Estonie
Lettonie
Lituanie
Ukraine
Norvège
Suède
Taiwan
Amérique du Nord
France
Australie
3.1.4.1 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.
3.1.4.2 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)
de la solution
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é.
3.1.5
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 red (Booter)
Ethernet jack
Aastra
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
depl-0900/0.4
Page: 27 (108)
de la solution
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
Etat DEL WLAN
Module WLAN introuvable
Rouge allumé
WLAN désactivé parce que l’OMM est actif
Off
WLAN désactivé par configuration
Off
WLAN désactivé en raison de 10 Mbps1
Vert clignotant 1 Hz
WLAN actif
Vert On
RFP L42 WLAN
LED for WLAN
LED red (Booter)
Ethernet jack
1
Le RFP L42 WLAN doit être raccordé à un connecteur Ethernet 100BaseT pour le
service WLAN.
Aastra
depl-0900/0.4
Page: 28 (108)
3.1.6
de la solution
Graphique d'état des phases de démarrage
LED RED ON
Start-up
wait for link up
BOOTER
LED RED ON
Wait for 6 seconds; listen
for local configuration
yes
Local
configuration
LED red
flashing 0,25 Hz
no
LED red
flashing 0,5 Hz
retry
DHCP no answer / offer not o.k.
DHCP
Wait for 60 seconds; listen
for local configuration
wait for reply
LED red
flashing 2,5 Hz
TFTP
TFTP failed
File download
Kernel
Local
configuration
Listen for local configuration in every state
no
yes
LED orange
LED orange
DHCP
Local conf. Start-up
wait for reply
LED green
flashing (0,5 Hz)
Application
Init failed
Init
LED green
flashing 1 Hz
Application
Connect to OMM
LED green
flashing 2 seconds
on / 50ms off
DHCP no answer; offer not o.k.
(try 3 minutes)
Application
Connection attempt to OMM failed
Failure, i.e. connection to OMM lost
Synchronize DECT
LED green
Application
Failure, i.e. connection to OMM lost
Up & running
*
Change of the local configuration
Aastra
depl-0900/0.4
Page: 29 (108)
3.2
de la solution
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 3.1.4 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)
de la solution
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
Utiliser
locale
Type
Définition
configuration obligatoire Les paramètres précisent s'il faut oui ou non utiliser au
démarrage les réglages de la configuration locale.
Adresse IP
obligatoire Adresse IP du RFP
Masque de réseau
obligatoire Masque sous-réseau du réseau IP
Adresse Serveur TFTP obligatoire Adresse IP du serveur TFTP
Nom de Fichier TFTP
obligatoire Au démarrage, le fichier de boot sera lu depuis le serveur TFTP.
Adresse IP OMM
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
OMM
Aastra
adresse
IP 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 3.3.2.5)
OMM en mode proxy
facultatif
Mode expert
depl-0900/0.4
Page: 31 (108)
de la solution
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)
de la solution
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 8.3.3 .
Aastra
depl-0900/0.4
Page: 33 (108)
de la solution
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)
3.3
de la solution
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.
3.3.1
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)
de la solution
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)
de la solution
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)
de la solution
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.
3.3.2
System
3.3.2.1 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 3.3.4.1). 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 3.3.2.1.2
•
Domaine Règlementaire tel qu'il est décrit au chapitre .3.3.2.1.3
•
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.
•
Aastra
Paramètres Date et Heure
depl-0900/0.4
Page: 38 (108)
de la solution
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 3.3.2.4).
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)
de la solution
3.3.2.1.1 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.
3.3.2.1.2 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.
3.3.2.1.3 Domaine Règlementaire
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).
3.3.2.2 SIP
Aastra
depl-0900/0.4
Page: 40 (108)
de la solution
Les paramètres SIP comprennent tous les paramètres correspondant au
signal SIP et les flux de voix RFP.
Aastra
•
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
5060. 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
5060. 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 3600.
•
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.
depl-0900/0.4
Page: 41 (108)
de la solution
•
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 à 64000. Valeur par défaut : 4000.
•
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 à 1440. 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 16320.
•
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)
de la solution
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)
de la solution
3.3.2.3 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)
de la solution
La signification des différents types de compte est décrite aux chapitres 4.2
et 4.3.
3.3.2.4 Fuseaux Horaires
Le chapitre 3.3.2.1 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)
de la solution
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)
de la solution
3.3.2.5 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
Aastra
-
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.
depl-0900/0.4
Page: 47 (108)
de la solution
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
3.3.2.5.1 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)
de la solution
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".
3.3.2.5.2 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)
de la solution
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.
3.3.2.5.3 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 :
{ftp|ftps|http|https}://[[user:password@]server]/[directory/]file
ou
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)
de la solution
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 3.1.4 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)
de la solution
3.3.2.5.4 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
3.1.4 et le chapitre 3.2 .
3.3.3
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)
de la solution
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.
3.3.3.1 Créer et modifier des RFP
3.3.3.1.1 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)
de la solution
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 3.3.5.
La même fenêtre contextuelle peut être ouverte pour un RFP existant en
du RFP adéquat.
cliquant sur l'icône outil
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.
3.3.3.1.2 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 8.3.2 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)
de la solution
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).
3.3.3.1.3 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)
de la solution
3.3.3.2 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)
de la solution
3.3.3.3 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 :
3.3.3.4 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.
3.3.4
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)
de la solution
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).
3.3.4.1 Créer et modifier des portatifs
3.3.4.1.1 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)
de la solution
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.
3.3.4.1.2 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 8.3.1 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)
de la solution
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)
de la solution
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).
3.3.4.2 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)
de la solution
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.
3.3.4.2.1 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.
3.3.4.2.2 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)
de la solution
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é.
3.3.4.3 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)
de la solution
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.
3.3.5
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
Pays:
0x10:
FCC
USA, Australie
0x20:
IC
Canada
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)
de la solution
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
Aastra
Portée
Notes
Périodicité de
balisage
50 – 65.535 Millisecondes
Longueur des intervalles
entre les balises.
Périodicité DTIM
1—255 balises
Le nombre de balises entre
deux transmissions DTIM
(Delivery Traffic Indication
Map)
depl-0900/0.4
Page: 65 (108)
de la solution
Seuil RTS
0 – 4.096 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
0 – 4.096 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.
802.11 Mode b/g
Mixte b uniquement / g
uniquement
Mode connexion 802.11.
SSID masqué
Oui/non
Supprime la transmission du
SSID.
Prévention des
interférences
Oui/non
Procédure pour prévenir les
interférences.
Paramètres de
sécurité
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
64 / 128 / 256 Bits
Longueur de la clé utilisée
dans les modes de sécurité.
Intervalle de
distribution.
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.
3.3.5.1 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)
de la solution
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.
3.3.5.2 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)
de la solution
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)
de la solution
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)
de la solution
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.
3.3.5.3 Spécifications pour le WLAN
Les adaptateurs WLAN conformes aux normes 802.11b ou 802.11g 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.
3.3.6
Caractéristiques système
3.3.6.1 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)
de la solution
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)
de la solution
3.3.6.2 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) 6104 4492” est
remplacé par +493061044492).
• 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 “+493061044492” est le préfixe
“+49306104” 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 ‘’#’.
3.3.6.3 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)
de la solution
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)
de la solution
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
●
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.
Types de comptes
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é.
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)
de la solution
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.
Nom:
'root'
Mot de passe: '22222'
Actif:
'n/a'
4.3
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)
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é:
●
Aastra
Le nouveau mot de passe ne comporte pas au moins 5 caractères
depl-0900/0.4
Page: 75 (108)
4.4
de la solution
●
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").
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)
de la solution
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 3.1.1 ), soit à l’aide du configurateur OM (voir chapitre 3.2 ).
Aastra
depl-0900/0.4
Page: 77 (108)
5.4
de la solution
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 :
-
5.5
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.
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)
de la solution
OMM – Reset with exit code 46
OMM – Reset with exit code 45
OMM Start up
or Restart
OMM sync NOK and
PBX reachable
OMM sync NOK and
PBX unreachable
OMM star up sync
OK
PBX not reachable
(registration and
OPTIONS request
failes)
OMM sync OK
Unsynchronised
Inactive OMM
Synchronised
Inactive OMM
OMM sync OK
other OMM is active
OMM sync NOK
PBX reachable
(registration or OPTIONS
request OK)
No OMM is active and
I have the lowest IP address
OMM sync OK
PBX not reachable
Unsynchronised
Active OMM
Synchronised
Active OMM
OMM sync NOK
(registration and OPTIONS
request failes)
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).
Another OMM is running
for a longer period
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.
5.6.1
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.
5.6.2
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)
de la solution
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.
5.6.2.1 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)
de la solution
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)
6
de la solution
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)
de la solution
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)
de la solution
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)
de la solution
Le terminal est occupé.
Aastra
depl-0900/0.4
Page: 85 (108)
de la solution
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)
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.
Il reste xx
Koctets
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
infobulle.
Info
Le téléchargement est impossible car :
- le combiné n'est pas joignable
- le combine est décroché
infobulle.
Aastra
depl-0900/0.4
Page: 86 (108)
Aastra
de la solution
depl-0900/0.4
Page: 87 (108)
de la solution
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:
•
•
•
•
•
7.2
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.
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
7.3.1
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)
de la solution
PARK: 1F-10-FF-F0-21
RFPI
RFP ID: 02*
10FFF21 02
Frame error
FE
PP: FP:
Field strength
-dBm
50
57
RFP ID
RPN 02
01
00
Menu
50
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 “10FFF221 02” 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é.
7.3.2
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.
3) Sélectionner “Auto Call Test”
5) Composer le numéro de téléphone à appeler
7) Entrer la durée en secondes entre deux appels.
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.
7.3.3
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)
de la solution
3) Sélectionner “Auto Answer”
5) Entrer la durée en secondes avant que le téléphone ne réponde à l'appel.
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.
7.3.4
Syslog
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)
7.3.5
de la solution
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.
7.3.5.1 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 4 2008 10: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)
de la solution
mot de passe de [email protected]
[email protected] >
7.3.5.2 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
7.3.5.3 Commandes de la console RFP
Si vous tapez “ip_rfpconsole”, vous pouvez utiliser les commandes
suivantes sur chaque RFP:
heap
help
lec
linéaire
media
mutex
créées
mutex
reset
rsx
sem
spy
<level #> ]
tasks
d'exécution
voice
exit
- affiche les statistiques du tampon heap
- affiche la table d'aide des commandes
- ajuste les paramètres de l'inhibiteur d'écho
- affiche l'état des canaux média
- liste toutes les exclusions mutuelles MXP
-
liste toutes les files d'attente MXP créées
réinitialise l’application IPRFP
permet la connexion RSX vers BMC via le TCP
liste tous les sémaphores MXP créées
définit/affiche les niveaux spy: [ <key #>
- liste toutes les tâches MXP en cours
- affiche l'état du traitement de la voix
- 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)
de la solution
7.3.5.4 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:
[email protected] > 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)
de la solution
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.
7.3.6
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=
7.3.7
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:
Aastra
•
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.
depl-0900/0.4
Page: 94 (108)
de la solution
•
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)
de la solution
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)
de la solution
•
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)
Aastra
de la solution
depl-0900/0.4
Page: 98 (108)
de la solution
8
Annexe
8.1
Information sur la réglementation des communications pour
Aastra DECT 142 US
Notes FCC (USA uniquement)
Cet appareil est conforme à la partie 15 des règles FCC. Son exploitation est
soumise aux deux conditions suivantes: (1) Cet appareil ne doit causer
aucune interférence dommageable et (2) cet appareil doit tolérer toute
interférence reçue à l’inclusion des interférences susceptibles de causer une
opération non désirée.
Les modifications non expressément agréées par cette entreprise pourraient
rendre caduque l'habilitation de l'utilisateur à exploiter cet équipement.
NOTE: Cet équipement a été testé et jugé conforme aux limitations pour un
appareil numérique de classe B en vertu de la partie 15 des règles FCC. Ces
limitations ont été conçues pour garantir une protection raisonnable contre
les interférences dommageables dans les installations résidentielles. Cet
équipement génère, utilise et peut rayonner des ondes radio et peut causer
des interférences dommageables dans les communications par radio s’il
n’est pas installé et utilisé conformément aux instructions. Cependant,
l’absence d’interférences dans une installation particulière n’est pas garantie.
Si cet équipement perturbe de façon importante la réception de la radio ou
de la télévision (interférences qui peuvent être déterminées en arrêtant et en
remettrant l’appareil en marche), l’utilisateur est invité à tenter de corriger les
interférences en prenant une ou plusieurs des mesures suivantes :
•
Réorienter ou déplacer l’antenne de réception.
•
Eloigner l’équipement du récepteur.
•
Raccorder l’équipement à une prise d’un circuit différent de celui
auquel est raccordé le récepteur.
•
Consulter le revendeur ou un technicien radio/TV.
Santé et sécurité
Exposition aux ondes radio (RF)
Votre téléphone sans fil est un émetteur-récepteur radio. Il a été conçu pour
ne pas dépasser les limitations en matière d’exposition aux ondes radio
établies par la Federal Communications Commission (FCC) du
gouvernement des Etats-Unis. Ces limitations font partie de directives
complètes et établissent des niveaux admissibles d'énergie RF pour
l'ensemble de la population. Ces directives sont basées sur des normes de
sécurité établies par des organes de normalisation américains et
internationaux. Ces normes intègrent une importante marge de sécurité
Aastra
depl-0900/0.4
Page: 99 (108)
de la solution
censée garantir la sécurité de toute personne, quels que soient son âge et
son état de santé.
Cet appareil et son antenne ne doivent pas être installés ou exploités
conjointement avec d’autres antennes ou émetteurs.
Cet appareil a démontré sa compatibilité avec le degré d’absorption
spécifique localisé, aux limitations pour l’exposition non contrôlée de
l’environnement / de la population spécifiée dans les normes ANSI / IEEE
C95.1-1992 et a été testé en conformité avec les procédures de mesure
spécifiées dans le bulletin FCCT/OET 67 Supplément C (2001) et IEEE
1528—2003.
Industrie Canada (Canada uniquement)
L’exploitation de cet appareil est soumise aux deux conditions suivantes: (1)
Cet appareil ne doit causer aucune interférence et (2) cet appareil doit tolérer
toute interférence reçue à l’inclusion des interférences susceptibles de
causer une opération non désirée.
La confidentialité des communications risque de ne pas être garantie lorsque
vous utilisez ce téléphone.
émises par le Ministère de la Santé (Canada,) Code de sécurité 6. Ces
limitations font partie de directives complètes et établissent des niveaux
admissibles d'énergie RF pour l'ensemble de la population. Ces directives
sont basées sur des normes de sécurité établies par des organes de
normalisation internationaux. Ces normes intègrent une importante marge de
sécurité censée garantir la sécurité de toute personne, quels que soient son
âge et son état de santé.
Cet appareil a démontré sa compatibilité avec le degré d’absorption
spécifique localisé, aux limitations pour l’exposition non contrôlée de
l’environnement / du public spécifiée dans les normes ANSI / IEEE C95.11992 et a été testé en conformité avec les procédures de mesure spécifiées
dans IEEE 1528—2003.
Aastra
depl-0900/0.4
Page: 100 (108)
8.2
de la solution
Information sur la réglementation en matière de
communications pour les RFP 32 ou RFP 34 (NA)
Notes FCC (USA uniquement)
Cet appareil est conforme à la partie 15 des règles FCC. Son exploitation est
soumise aux deux conditions suivantes: (1) Cet appareil ne doit causer
aucune interférence dommageable et (2) cet appareil doit tolérer toute
interférence reçue à l’inclusion des interférences susceptibles de causer une
opération non désirée.
Les modifications non expressément agréées par cette entreprise pourraient
rendre caduque l'habilitation de l'utilisateur à exploiter cet équipement.
NOTE: Cet équipement a été testé et jugé conforme aux limitations pour un
appareil numérique de classe B en vertu de la partie 15 des règles FCC. Ces
limitations ont été conçues pour garantir une protection raisonnable contre
les interférences dommageables dans les installations résidentielles. Cet
équipement génère, utilise et peut rayonner des ondes radio et peut causer
des interférences dommageables dans les communications par radio s’il
n’est pas installé et utilisé conformément aux instructions. Cependant,
l’absence d’interférences dans une installation particulière n’est pas garantie.
Si cet équipement perturbe de façon importante la réception de la radio ou
de la télévision (interférences qui peuvent être déterminées en arrêtant et en
remettrant l’appareil en marche), l’utilisateur est invité à tenter de corriger les
interférences en prenant une ou plusieurs des mesures suivantes :
•
Réorienter ou déplacer l’antenne de réception.
•
Eloigner l’équipement du récepteur.
•
Raccorder l’équipement à une prise d’un circuit différent de celui
auquel est raccordé le récepteur.
•
Consulter le revendeur ou un technicien radio/TV.
établies par la Federal Communications Commission (FCC) du
gouvernement des Etats-Unis. Ces limitations font partie de directives
complètes et établissent des niveaux admissibles d'énergie RF pour
l'ensemble de la population. Ces directives sont basées sur des normes de
sécurité établies par des organes de normalisation américains et
internationaux. Ces normes intègrent une importante marge de sécurité
censée garantir la sécurité de toute personne, quels que soient son âge et
son état de santé.
Aastra
depl-0900/0.4
Page: 101 (108)
de la solution
En cours d’exploitation, l’élément rayonnant du RFP devrait être installé à
une distance supérieure à 20 cm entre l’utilisateur et l’appareil. L’appareil est
conforme aux exigences pour les limites d’évaluation de routine.
Industrie Canada (Canada uniquement)
L’exploitation de cet appareil est soumise aux deux conditions suivantes: (1)
Cet appareil ne doit causer aucune interférence et (2) cet appareil doit tolérer
toute interférence reçue à l’inclusion des interférences susceptibles de
causer une opération non désirée.
La confidentialité des communications risque de ne pas être garantie lorsque
vous utilisez ce téléphone.
émises par le Ministère de la Santé (Canada,) Code de sécurité 6. Ces
limitations font partie de directives complètes et établissent des niveaux
admissibles d'énergie RF pour l'ensemble de la population. Ces directives
sont basées sur des normes de sécurité établies par des organes de
normalisation internationaux. Ces normes intègrent une importante marge de
sécurité censée garantir la sécurité de toute personne, quels que soient son
âge et son état de santé.
En cours d’exploitation, l’élément rayonnant du RFP devrait être installé à
une distance supérieure à 20 cm entre l’utilisateur et l’appareil. Cet appareil
est conforme aux exigences pour les limites d’évaluation de routine.
Aastra
depl-0900/0.4
Page: 102 (108)
8.3
de la solution
Règles pour les fichiers de pré-configuration
La trame du texte suit strictement des règles définies.
La trame principale se divise en deux parties :
1. Une partie instructions utilisée pour engendrer la création de
données génériques pour ces champs non complétées avec une
section Séquence de données
2. Une Section séquence de données définit des champs
d’enregistrements de données. Chacune est définie de façon explicite
Détails des règles de présentation :
•
Les commentaires commencent par #
•
Chaque enregistrement est clôturé par les expressions régulières “\r”
ou “\n”
•
Les paramètres d’instruction sont du type <balise> = <valeur>.
•
Les sections de séquences de données commencent par le mot clé
« data_sequence ». Ce mot clé est toujours obligatoire pour
exécuter le fichier. Toutes les instructions doivent être inscrites avant
cette ligne.
•
Les champs correspondant aux enregistrements de séquences de
données sont séparés par un point-virgule « ; ». Les points-virgules
doivent aussi être entrés pour les champs vides si au moins un suit un
champ qui n'est pas vide. A défaut, les positions des champs ne
correspondent pas.
•
Si plusieurs valeurs sont assignées à des champs (ce peut être le cas
pour quelques champs de configuration locale de RFP tels que
ntp_adress), il faut les séparer avec des virgules.
Notes :
Aastra
•
Comme les champs des séquences de données sont séparés par des
points-virgules, le contenu de cette partie peut être généré par une
exportation en format .csv d’une feuille de calcul Excel et copié dans
le fichier de configuration.
•
Les instructions sont uniquement assurées dans ces champs qui sont
vides dans la partie séquences de données.
depl-0900/0.4
Page: 103 (108)
8.3.1
de la solution
Fichier de configuration portatif (base de données OMM)
8.3.1.1 Instructions supportées
•
start_number (numéro démarrage)
Les numéros peuvent être générés automatiquement. Cette instruction
définit la valeur de démarrage
•
no_of_number
Si le numéro de dépannage est établi, cette instruction définit le
nombre maximal de numéros qui seront générés.
•
Ac (code d’authentification)
S’il est spécifié « numéro » l’ac équivaudra à un numéro. Si une valeur
est fournie, elle sera utilisée comme une valeur de démarrage qui sera
augmentée à chaque génération.
•
additional_pin
see ac
•
sip_user
see ac
•
sip_pw
see ac
8.3.1.2 Champs sections données
Les sections Données comprennent l’ordre des champs suivant :
1.
2.
3.
4.
5.
6.
7.
Numéro
Nom
AC
IPEI
ID supplémentaire
Nom utilisateur SIP
Mot de passe SIP
8.3.1.3 Exemple
Fichier de configuration portatif :
# -----------------------#
# instruction section:
# -----------------------#
# -- start_number
= {<valeur de démarrage pour les numéros à générer>}
# -- no_of_number
= {<nombre maximum de numéros générés>}
# -- dect authentication code (ac) = {<"numéro">, <valeur de démarrage pour les ac à
générer>}
# -- additionalId/userPin
= {<"numéro">, <valeur de démarrage pour ID à génerer>}
# -- SIP user
= {<"numéro">, <valeur de démarrage pour ID à générer>}
# -- SIP password
= {<"numéro">, <valeur de démarrage pour ID à générer>}
Aastra
depl-0900/0.4
Page: 104 (108)
de la solution
start_number = 5401
no_of_number = 10
ac = 1001
additional_pin = number
sip_user = number
sip_pw = number
# ---------------------#
# data sequence:
# ---------------------#
# 1. number # 2. name # 3. AC # 4. IPEI # 5. additionalId # 6. SIP user # 7. SIP password
data_sequence
101;PP 1;;0081008625768
104;PP 4;;0007701154842
;Kiel Phone1;;0127105395099
;Karl May
;Karl Valentin
;Karl Heinz
;Radi Radenkowicz
;Radi Rettich
;Wadi Wade
;Stephan Fiedler;;0127105314450
;Waldi Hartmann;
Référence au journal d’analyse sur l’instruction d’exécution et lire :
instruction analyse:
OK start_number = 5401
OK ac = 1001
OK additional_pin = number
OK sip_user = number
OK sip_pw = number
OK no_of_number = 10
Exécution section :
0 : 101;PP 1;1001;0081008625768;101;101;101
1 : 104;PP 4;1002;0007701154842;104;104;104
2 : 5401;Kiel Phone1;1003;0127105395099;5401;5401;5401
3 : 5402;Karl May;1004;;5402;5402;5402
4 : 5403;Karl Valentin;1005;;5403;5403;5403
5 : 5404;Karl Heinz;1006;;5404;5404;5404
6 : 5405;Radi Radenkowicz;1007;;5405;5405;5405
7 : 5406;Radi Rettich;1008;;5406;5406;5406
8 : 5407;Wadi Wade;1009;;5407;5407;5407
9 : 5408;Stephan Fiedler;1010;0127105314450;5408;5408;5408
10 : 5409;Waldi Hartmann;1011;;5409;5409;5409
11 : 5410;;1012;;5410;5410;5410
Aastra
depl-0900/0.4
Page: 105 (108)
8.3.2
de la solution
Fichier de configuration RFP/ conf. centrale (base de
données OMM)
Toutes les instructions sont prises en tant que valeur commune fixée pour
tous les enregistrements de séquences de données du fichier en question si
le champ correspondant est vide.
•
Nom
Nom cellule
•
active
Activation DECT : {0=inactif, 1=actif}
•
Grappe
Grappe à laquelle le RFP se réfère : {1..256}
•
wlan_profile
Clé de référence pour un profil WLAN existant
•
wlan_antenna
Réglages antenne : = {0=diversité, 1, 2}
•
wlan_channel_bg
{0..14 (la taille dépend du domaine réglementaire) }
•
wlan_power
•
{ 6, 12, 25, 50,100 (pourcentage)}
•
wlan_act
Activation WLAN : {0=inactif, 1=actif}
1.
2.
3.
4.
5.
6.
7.
8.
9.
Adresse MAC
Nom cellule
DECT actif
Grappe
Référence profil WLAN
Antenne WLAN
Channel_bg
Courant WLAN
WLAN actif
8.3.2.3 Exemple
Fichier de configuration RFP / conf. Centrale :
Aastra
depl-0900/0.4
Page: 106 (108)
de la solution
# ---------------------#
# instruction section:
# ---------------------#
# -- name
= {<nom cellule>}
# -- active
= {0,1}
# -- cluster
= {1..256}
# -- wlan_profile
= <référence valide à un profil WLAN existant>}
# -- wlan_antenna
= {0=diversité, 1, 2}
# -- wlan_channel_bg = {0.0.13 (la taille dépend du domaine réglementaire) }
# -- wlan_power
= { 6, 12, 25, 50,100 (pourcentage)}
# -- wlan_act
= {0,1}
active = 1
cluster = 1
#wlan_profile = 2
#wlan_antenna = 0
#wlan_channel_bg =5
#wlan_power = 12
#wlan_act = 1
# ---------------#
# data sequence:
# ----------------#
# 1.MAC # 2.Name # 3.active # 4.cluster
# 5.wlanProfile # 6. antenna # 7.channelBg # 8.Power # 9.WlanActive
data_sequence
00:30:42:08:31:A2;142(Mirko);1;1;;;;;
00:30:42:0D:95:E0;Lab1
00:30:42:0A:C5:40;Lab2(kiel);;2
pas établie: Cellule :
OK active = 1
OK cluster = 1
pas établie: wlan_profile
pas établie: wlan_antenna
pas établie: wlan_channel_bg
pas établie: wlan_power
pas établie: wlan_act
0 : 00:30:42:08:31:A2;142(Mirko);1;1;;;;;
1 : 00:30:42:0D:95:E0;Lab1;1;1;;;;;
2 : 00:30:42:0A:C5:40;Lab2(kiel);1;2;;;;;
Aastra
depl-0900/0.4
Page: 107 (108)
8.3.3
de la solution
Fichier de configuration RFP/ conf. centrale (OM
Configurator)
Toutes les instructions sont prises en tant que valeur commune fixée pour
tous les enregistrements de séquences de données du fichier en question si
le champ correspondant est vide.
•
active
Configuration locale active {0=inactive(lui substituer DHCP ), 1=active}
•
net_mask
Masque de réseau
•
tftp_server
Adresse IP du serveur TFTP
•
tftp_file
Chemin et nom du fichier d’amorçage
•
omm_1
Adresse IP OMM
•
omm_2
Adresse IP de l’OMM en backup
•
Passerelle
Passerelle par défaut
•
dns_server
Jusqu’à deux adresses IP de serveur DNS
•
dns_domain
Domaine DNS local
•
ntp_address
Jusqu’à deux adresses IP de serveur NTP
•
ntp_name
Jusqu’à deux noms de serveur NTP
•
syslog_addr
Adresse IP du démon syslog
•
syslog_port
Ecoute port du démon syslog
•
broadcast_addr
Adresse de diffusion locale
•
pays
Indicatif de pays
Aastra
depl-0900/0.4
Page: 108 (108)
de la solution
1. Adresse MAC du RFP
2. Flag configuration locale active
3. Adresse IP du RFP
4. Masque de sous-réseau
5. Serveur TFTP
6. TFTP_FILE
7. Adresse IP OMM
8. Adresse IP de l’OMM en backup
9. Passerelle par défaut
10. Serveur DNS
11. Domaine DNS
12. Adresse IP du serveur NTP
13. Nom du serveur NTP
14. Adresse IP du démon syslog
15. Ecoute port syslog
16. Adresse Broadcast
17. Indicatif de pays...
8.3.3.3 Exemple
Fichier de configuration RFP/ conf. locale (OM Configurator):
# -------------------------------------------#
# instruction section
#
# -------------------------------------------#
active = 1
net_mask
= 255.255.0.0
tftp_server= 172.30.200.92
tftp_file = /omm_ffsip.tftp
omm_1
= 172.30.111.188
omm_2
= 172.30.11.181
gateway
= 172.30.0.2
dns_server = 172.30.0.4,172.30.0.21
dns_domain = detewe.de
ntp_addr
= 192.53.103.108,192.53.103.104
ntp_name
= ptbtime1.ptb.de,ptbtime2.ptb.de
syslog_addr= 172.30.200.92
syslog_port= 512
broadcast_addr = 172.30.255.255
country
= 1
#
#
#
#
#
#
#
Aastra
-------------------------------------------#
data sequence
#
-------------------------------------------#
1. MAC_ADDR
! aucune instruction prise en charge !
2. ACTIVE_FLAG
3. RFPADDR
! aucune instruction prise en charge !
4. NET_MASK
depl-0900/0.4
Page: 109 (108)
# 5.
# 6.
# 7.
# 8.
# 9.
#10.
#11.
#12.
#13.
#14.
#15.
#16.
#17.
de la solution
TFTP_SERVER
TFTP_FILE
OMM1
OMM1
GATEWAY
DNS_SERVER
DNS_DOMAIN
NTP_ADDR
NTP_ADDR
SYSLOG_ADDR
SYSLOG_PORT
BROADCAST_ADDR
COUNTRY
data_sequence
00-30-42-01-01-01;;172.30.111.1
00-30-42-02-02-02;;172.30.111.2
00-30-42-01-01-03;;172.30.111.3;
OK active = 1
OK net_mask
= 255.255.0.0
OK tftp_server= 172.30.200.92
OK tftp_file = /omm_ffsip.tftp
OK omm_1
= 172.30.111.188
pas établie: omm_2
pas établie: gateway
pas établie: dns_server
pas établie: dns_domain
pas établie: ntp_addr
pas établie: ntp_name
pas établie: syslog_addr
pas établie: syslog_port
pas établie: broadcast_addr
pas établie: country
:analyse ok:
: 0 : 00-30-42-01-01-01; 1;172.30.111.1;255.255.0.0;172.30.200.92;
/omm_ffsip.tftp;172.30.111.188;;;;;;;;;;;
: 1 : 00-30-42-02-02-02;1;172.30.111.2;255.255.0.0;172.30.200.92;
/omm_ffsip.tftp;172.30.111.188;;;;;;;;;;;
: 2 : 00-30-42-01-01-03;1;172.30.111.3;255.255.0.0;172.30.200.92;
/omm_ffsip.tftp;172.30.111.188;;;;;;;;;;;
créer données:
0 :ajouté: 00-30-42-01-01-01;1;172.30.111.1;255.255.0.0;172.30.200.92;
/omm_ffsip.tftp;172.30.111.188;;;;;;;;;;;
1 :ajouté: 00-30-42-02-02-02;1;172.30.111.2;255.255.0.0;172.30.200.92;
/omm_ffsip.tftp;172.30.111.188;;;;;;;;;;;
2 :ajouté: 00-30-42-01-01-03;1;172.30.111.3;255.255.0.0;172.30.200.92;
/omm_ffsip.tftp;172.30.111.188;;;;;;;;;;;
Configuration RFP :
Aastra
depl-0900/0.4
Page: 110 (108)
de la solution
0 : adresse MAC =00-30-42-01-01-01 : use_local_cfg=1 ip=172.30.111.1
subnet=255.255.0.0 siaddr=172.30.200.92
boot_file=/omm_ffsip.tftp ommip1=172.30.111.188
0 : adresse MAC =00-30-42-01-01-01 : timer expired ! !
subnet=255.255.0.0 siaddr=172.30.200.92
subnet=255.255.0.0 siaddr=172.30.200.92
Aastra
depl-0900/0.4
Page: 111 (108)
8.4
de la solution
Protocoles et ports
Protocole
DHCP
TFTP
Envoi IP station base DECT
Port SRC
Port DST
68
67
Aléatoire
69
Réception IP station base DECT
Port SRC
Port DST
67
68
Aléatoire
Aléatoire
Envoi OMM
Port SRC
-
Port DST
-
Réception OMM
Port SRC
Port DST
-
OMCFG (UDP)
64000
64000
64000
64000
-
-
-
-
NTP
123
123
123
-
-
-
-
syslog
514
-
-
-
-
-
-
application
TFTP
Protocole OMMRFP (TCP)
> 1023
123
Selon
configuration
69
Amorce
Amorce
Amorce /
application
application
Aléatoire
> 1023
-
-
-
-
application
> 1023
16321
16321
> 1023
16321
> 1023
> 1023
16321
application
Portée du port
base RTP + 72
ports pairs pour
RTP, ports
impaires pour
RTCP
En fonction
de la partie
distante
En fonction
de la partie
distante
Portée du port base
RTP + 72
ports pairs pour
RTP, ports impaires
pour RTCP
-
-
-
-
application
Port
proxy/serveur
d’enregistrement
configuré
16322
port configuré
(par défaut 389)
Port client
Port client
53
Port
proxy/serveur
d’enregistrement
configuré
16322
port configuré
(par défaut 389)
Port client
Port client
53
5060
application
> 1023
application
> 1023
application
80
443
> 1023
application
application
application
RTP / RTCP
SIP (UDP)
-
-
-
-
5060
Résilience (TCP)
-
-
-
-
> 1023
LDAP (TCP)
-
-
-
-
> 1023
http redirect
Web-IF / HTTPS
DNS
> 1023
53
53
> 1023
80
443
> 1023
Aastra
depl-0900/0.4
Remarques
Page: 112 (108)
Protocole
de la solution
Envoi IP station base DECT
Port SRC
Port DST
Réception IP station base DECT
Port SRC
Port DST
Envoi OMM
Port SRC
Réception OMM
Port SRC
Port DST
Remarques
Port DST
ssh
22
Port client
Port client
22
-
-
-
-
application
DECTnetMonitor
(TCP)
-
-
-
-
8106
Port client
Port client
8106
application
Protocoles
supplémentaires
ARP
ICMP
Aastra
depl-0900/0.4
Page: 113 (108)

Installation, Administration et Maintenance de la solution

Transcription

Documents pareils

La photosynthèse L`ATP La glycolyse Le cycle de Krebs (ou des

Reference Case Orell Fuessli Security Printing Ltd.

TGP500 - TÉLÉPHONE-BASE SIP DECT TÉLÉPHONE SANS FIL SIP

SOLUTION DECT SIP

la bioélectronique selon LC Vincent - danze-jm

Fiche Macaron /FR (Page 1)

GIGAREPEATER2.0 Gigaset Repeater 2.0 Le

Voix sur IP – VoIP

dépliant Teslabel sur les risques du Wi-Fi