Instalación, Administración y Mantenimiento de la solución DECToverIP using SIP Versión 1.7

Transcripción

1 Instalación, Administración y Mantenimiento de la solución DECToverIP using SIP Versión 1.7 Id. del documento : depl-0900 Versión: 0.4 Aastra Zeughofstr Berlin, Alemania Junio de Todos los derechos reservados Este documento, ya sea total o parcialmente, no se puede reproducir o transmitir de ninguna forma ni por ningún medio, electrónico o mecánico, incluyendo su fotocopia, grabación o almacenamiento de su información en un sistema de recuperación, bajo ningún pretexto sin el consentimiento expreso por escrito de Aastra.

2 Sumario 1 PERSPECTIVA GENERAL OBJETIVO DECLARACIÓN DE CONFORMIDAD ABREVIATURAS Y DEFINICIONES ABREVIATURAS DEFINICIONES REFERENCIAS INTRODUCCIÓN ACERCA DE LA SOLUCIÓN IP DECT DECTOVERIP USING SIP ACERCA DE LOS PUNTOS DE ACCESO (RFP) OPENMOBILITY MANAGER SEÑALES IP Y FLUJOS DE MEDIOS SINCRONIZACIÓN DE LAS RFP CAPACIDAD DE LOS CANALES DE LA RFP ACERCA DE LAS PARTES MÓVILES CAPACIDAD DEL SISTEMA INSTALACIÓN Y CONFIGURACIÓN INICIO DE OPENMOBILITY INICIO DE LAS RFP Perspectiva general del arranque ARRANQUE DEL OPENMOBILITY MANAGER ARRANQUE Cliente DHCP Solicitud DHCP Oferta DHCP Reintentos Cliente TFTP APLICACIÓN Actualización del arranque Selección del servidor DHCP adecuado ESTADO DEL LED DE LA RFP GRAFICO DE ESTADO DE LAS FASES DE ARRANQUE CONFIGURACIÓN LOCAL ESTÁTICA DE UNA RFP CONFIGURACIÓN DEL OPENMOBILITY MANAGER PROCEDIMIENTO DE INICIO DE SESION EN EL SERVICIO SISTEMA Ajustes del sistema Reinicio del OMM Codificación Campo normativo SIP Cuenta de usuario Zonas horarias Gestión de la base de datos Importación manual de una base de datos Exportación manual de una base de datos Importación automática de una base de datos Exportación automática de una base de datos CONFIGURACIÓN RFP Creación y cambios de RFP Botones nuevo, cambiar y borrar Importar archivos de configuración Captura de RFP Estados de una RFP Modelo de HW del RFP Verificación de la versión del software del OMM / RFP CONFIGURACIÓN DE LOS TERMINALES Creación y cambios de PP Botones nuevo, cambiar y borrar Importar archivos de configuración Registro...61 Aastra depl-0900/0.4 Página: 2 (112)

3 Registro con IPEI configurado Registro libre Búsqueda en la lista de PP CONFIGURACIÓN DE WLAN (SÓLO RFP L42 WLAN) Optimización de la WLAN Seguridad de la WLAN con Radius Requisitos para la WLAN PROPIEDADES DEL SISTEMA Configuración centralizada del acceso LDAP Tratamiento de los dígitos Códigos de acceso a funciones SEGURIDAD EL CONCEPTO DE SEGURIDAD TIPOS DE CUENTA CAMBIO DE LOS DATOS DE CUENTA OBSTÁCULOS POTENCIALES REDUNDANCIA DE OMM COMO FUNCIONA LA REDUNDANCIA DE OMM INTRODUCCIÓN CONFIGURACIÓN DE LA REDUNDANCIA DE OMM SITUACIONES DE CAMBIO DE OMM ACTIVO SITUACIONES DE FALLO EN EL CAMBIO DE OMM ACTIVO SITUACIONES ESPECÍFICAS DE REDUNDANCIA CÓMO PASA A SER ACTIVO UN OMM REDUNDANTE FUNCIONAMIENTO CUANDO AMBOS OMM NO ESTÁN SINCRONIZADOS Dos interfaces inalámbricas DECT DESCARGA INALÁMBRICA CÓMO FUNCIONA LA DESCARGA INALÁMBRICA CÓMO CONFIGURAR LA DESCARGA INALÁMBRICA MANTENIMIENTO EQUIPAMIENTO DE EVALUACION DE UN LUGAR DE INSTALACION COMPROBACION DE LA VERSION DE FIRMWARE DEL TERMINAL AASTRA DECT 142 / AASTRA 142D DIAGNÓSTICO MODO DE EVALUACION DE UN LUGAR DE INSTALACION DEL AASTRA DECT 142 / AASTRA 142D MODO DE PRUEBA AUTOLLAMADA DEL AASTRA DECT 142 / AASTRA 142D MODO DE PRUEBA AUTORRESPUESTA DEL AASTRA DECT 142 / AASTRA 142D SYSLOG SSH USER SHELL Login Resumen de comandos Comandos de consola RFP Comandos de consola OMM CAPTURA DE FICHEROS DE VOLCADO DE MEMORIA (CORE FILES) MONITOR DECT ANEXO INFORMACION DE REGULACION DE LAS COMUNICACIONES PARA AASTRA DECT 142 EE.UU INFORMACIÓN SOBRE REGULACIÓN DE LAS COMUNICACIONES PARA LA RFP 32 O RFP 34 (NORTEAMÉRICA) REGLAS PARA EL ARCHIVO DE CONFIGURACION PREVIA ARCHIVO DE CONFIGURACION DE LOS PP (BASE DE DATOS DEL OMM) Instrucciones soportadas Campos de la sección de datos Ejemplo ARCHIVO DE CONFIGURACION DE LA RFP / CENTRAL (BASE DE DATOS DEL OMM) Instrucciones soportadas Campos de la sección de datos Ejemplo Aastra depl-0900/0.4 Página: 3 (112)

4 8.3.3 ARCHIVO DE CONFIGURACION DE LA RFP / LOCAL (OM CONFIGURATOR) Instrucciones soportadas Campos de la sección de datos Ejemplo PROTOCOLOS Y PUERTOS Aastra depl-0900/0.4 Página: 4 (112)

5 1 Perspectiva general 1.1 Objetivo Este documento describe la instalación, configuración y mantenimiento de la solución DECToverIP using SIP. 1.2 Declaración de Conformidad La marca CE certifica la conformidad del producto con los principios técnicos para la seguridad del usuario y la compatibilidad electromagnética, válida desde la fecha de publicación de la Declaración de Conformidad correspondiente conforme a la Directiva Europea 99/5/EC. La Declaración de Conformidad está publicada en la página web de Aastra. 1.3 Abreviaturas y definiciones Abreviaturas AC ADPCM DECT DHCP DSP FCC GAP IPEI HTTP OMM PARK PP SNMP TFTP RFP RTCP RTP Authentication Code Adaptive Differential Pulse Code Modulation Digital Enhanced Cordless Telecommunication Dynamic Host Configuration Protocol Digital Signal Processor Federal Communications Commission Generic Access Profile International Portable Equipment Identity Hyper Text Transfer Protocol OpenMobility Manager Portable Access Rights Key Portable Part (DECT handset) Simple Network Management Protocol Trivial File Transfer Protocol Radio Fixed Part (Access Point) Real Time Control Protocol Real Time Protocol Definiciones Aastra DECT 142 Handset / Aastra 142d Aastra DECT 142 Handset / Aastra 142d En el contexto de la solución DECToverIP using SIP, se puede utilizar indistintamente Aastra DECT 142 Handset, Aastra 142d y Terminal Móvil (PP).142 Teniendo en cuenta las divergencias entre los requisitos normativos entre Norteamérica y todas las demás zonas del mundo, existen dos variantes de PP, que utilizan Aastra depl-0900/0.4 Página: 5 (112)

6 bandas de frecuencia e intensidades de campo específicas: Aastra DECT 142 Para su utilización en Norteamérica. Aastra 142d Punto de Acceso Punto de Acceso Asterisk DECT Para su utilización en todas las demás zonas. En el contexto de la solución DECToverIP using SIP, se puede utilizar indistintamente Punto de Acceso y Parte Fija de Radio (RFP). Asterisk Asterisco, en software, es una Open Source PBX completa. Funciona en Linux, BSD y MacOSX y proporciona muchas funciones. Asterisk soporta voz en IP en muchos protocolos, y puede interoperar con casi todo el equipamiento de telefonía basado en estándares. Digital Enhanced Cordless Telecommunication El estándar (ETS ) especifica fundamentalmente la interfaz por aire, conocida como la interfaz de radio. A través de esta interfaz se puede transmitir tanto voz como datos. Sus características técnicas clave para Europa son: Rango de frecuencia: MHz (aproximadamente 20 MHz de ancho de banda) 10 frecuencias portadoras (espaciadas a 1728 khz) con 12 franjas temporales cada una Duplicar el número de franjas temporales (hasta 24) utilizando el proceso TDMA Velocidad de datos neta por canal de 32 kbps (para transmisión de voz utilizando ADPCM) Codificación de voz utilizando el método ADPCM Sus características técnicas clave para Norteamérica son: Rango de frecuencia: MHz (aproximadamente 10 MHz de ancho de banda) 5 frecuencias portadoras (espaciadas a 1728 khz) con 12 franjas temporales cada una Duplicar el número de franjas temporales (hasta 24) utilizando el proceso TDMA Velocidad de datos neta por canal de 32 kbps (para transmisión de voz utilizando ADPCM) Codificación de voz utilizando el método ADPCM Aastra depl-0900/0.4 Página: 6 (112)

7 GAP Generic Access Profile GAP es la abreviatura de Generic Acces Profile El estándar GAP (ETS ) está basado en la misma tecnología que la DECT, pero se limita a las funciones básicas más importantes. Este estándar se creó para que teléfonos de diferentes fabricantes pudieran usarse en cualquier tipo de sistema DECT. Así, representa el mínimo común denominador de todas las variantes específicas de cada fabricante del estándar DECT. Una limitación importante del estándar GAP es que las operaciones externas de transferencia no son posibles. Por esta razón se utiliza una transferencia de conexión, que los terminales GAP soportan. El funcionamiento de los teléfonos con GAP es comparable a la de los terminales analógicos. Por ejemplo, las funciones se pueden iniciar a través de procedimientos ' * y '#'. Transferencia IPEI Transferencia Una transferencia es similar al roaming, pero ocurre durante una llamada. Tiene lugar normalmente de fondo, sin afectar a la llamada (transferencia sin cortes). International Portable Equipment Identity Código de identificación de 13 dígitos para PP. Ejemplo: (el dígito final es la suma de verificación). El código se representa de manera decimal. Este código es único globalmente. PARK Roaming Portable Access Rights Key Código de acceso del terminal(pp). Este código determina si un PP puede acceder a un sistema DECT en particular. Se utiliza para una selección única de un sistema dedicado en el momento del registro o suscripción del teléfono. Etiquetado en el CD OpenMobility y único para cada instalación SIP - DECT. Roaming Mientras está en movimiento, el PP realiza medidas para determinar qué RFP se recibe mejor. La que se pueda recibir mejor se define como la RFP activa. Para evitar que una PP no pare de cambiar entre dos RFP con intensidades de señal parecidas, se aplican ciertos valores de umbral. Aastra depl-0900/0.4 Página: 7 (112)

8 1.4 Referencias /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 Página: 8 (112)

9 2 Introducción 2.1 Acerca de la solución IP DECT DECToverIP using SIP La solución DECToverIP using SIP contiene los siguientes componentes: Puntos de Acceso Aastra SIP - DECT (también conocidos como Partes Fijas de Radio o RFP) distribuidos en una red IP y que ofrecen interfaces IP y DECT inalámbricas. Una plataforma SIP de Gestión de Llamadas / IP PBX / Servidor Multimedia (por ej. Asterisk). Aastra DECT 142 Handsets / Aastra 142d (conocidos también como partes móviles o terminales PP). OpenMobility Manager (OMM): Interfaz de gestión para la solución DECToverIP mediante SIP ( DECToverIP using SIP ), que funciona en una de las estaciones de base (Radio Fixed Parts). En el esquema siguiente se ofrece una perspectiva general de la arquitectura de la solución IP DECT inalámbrica: La PABX IP / servidor de canales IP / gateway de canales IP, OMM y las RFP se comunican a través de la infraestructura IP. Las RFP s y los Terminales Móviles se comunican a través de aire utilizando el protocolo DECT GAP o el DECT GAP con mejoras propietarias. Aastra depl-0900/0.4 Página: 9 (112)

10 2.2 Acerca de los Puntos de Acceso (RFP) Aastra DeTeWe proporciona 3 tipos de Puntos de Acceso: - RFP L32 Punto de Acceso DECT, modelo para interiores - RFP L34 Punto de Acceso DECT, modelo para exteriores - RFP L42 WLAN DECT + WLAN, modelo para interiores En general, la RFP 32 y la RFP 34 poseen las mismas características de hardware y software. Tenga en cuenta las diferencias normativas entre Norteamérica y las demás zonas del mundo. Estas diferencias llevan a diversas variantes de la RFP 32/34 que utilizan bandas de frecuencia e intensidades de campo específicas: RFP 32 NA o RFP 34 NA (NA) - Banda de Frecuencia de 1920 a 1930 MHz - 5 frecuencias portadoras - Potencia de Transmisión 20 dbm RFP L32 IP o RFP L34 IP (EMEA) - Banda de Frecuencia de 1880 a 1900 MHz - 10 frecuencias portadoras - Potencia de Transmisión 24 dbm La RFP L42 WLAN sólo está disponible para la región de EMEA (Europa, Oriente Medio y África). Una RFP dentro de una instalación SIP - DECT debe comunicarse que funciona como el OpenMobility Manager (OMM). La RFP que actúa como el OMM puede además actuar como una FRP normal, así como si se incluye en un Clúster DECT. Aastra depl-0900/0.4 Página: 10 (112)

11 Modo sólo RFP En este modo, la RFP convierte el protocolo IP en protocolo DECT y después transmite el tráfico de los terminales a una franja temporal DECT. En funcionamiento, la RFP tiene 12 franjas temporales disponibles, 8 pueden tener recursos DSP asociados para flujos de canales IP y las 2 franjas temporales restantes se utilizan para señales de control entre las RFP y los PP, y 2 franjas se reservan con fines de entrega. Se pueden hacer grupos de RFP, que se denominan clusters. Dentro de un cluster, las RFP se sincronizan para permitir una transferencia sin cortes cuando un usuario pasa de la zona de cobertura de una RFP a otra. Para la sincronización, no es necesario que una RFP se comunique directamente con todas las demás RFP del sistema. Cada RFP sólo tiene que ser capaz de comunicarse con la siguiente RFP de la cadena. Sin embargo, es preferible que una RFP esté en contacto con más de una de las restantes RFP para garantizar la sincronización en caso de que una de las RFP falle. Los 2 canales de control se utilizan también para transmitir señales que indican al terminal el inicio del proceso de transferencia. Si la señal de radio de otra RFP es más potente que la de la RFP actual, entonces el terminal inicia el proceso de transferencia a la RFP con la señal más potente, mientras el usuario se desplaza. Modo OpenMobility Manager En este modo, una RFP funciona como una RFP normal. Además, es responsable de las señales SIP entre el sistema IP DECT y el servidor de medios o telefonía. También asume la parte de gestión de la solución IP DECT. La RFP queda configurada como OMM asignándole una dirección IP dentro del rango DHCP (ver capítulo 3) o configurándolo con ayuda del OM Configurator (ver capítulo 3.2), Una vez que una RFP se haya designado como el OMM, inicia los servicios adicionales (por ejemplo, el servicio web que soporta la interfaz de gestión). Todas las RFP descargan el mismo firmware de un servidor TFTP, pero sólo una RFP activa los servicios OMM: Nota: Es posible desactivar la parte DECT de una RFP. Si la interfaz DECT se desactiva, entonces todos los recursos (CPU y memoria) quedan disponibles para el OMM. Aastra depl-0900/0.4 Página: 11 (112)

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

13 2.3 OpenMobility Manager El OpenMobility Manager (OMM) realiza las siguientes tareas: Puerta de señales (SIP <-> DECT). Gestión de flujo de medios. Gestión de funciones de sincronización inalámbrica entre distintas RFP. Facilitar modificaciones de configuración del sistema. Permite servicios adicionales, por ejemplo - Directorio Corporativo (basado en LDAP) El OpenMobility Manager (OMM) funciona en una de las RFP. 2.4 Señales IP y flujos de medios Para establecer una llamada entre un teléfono IP y una PP (Aastra DECT 142 Handset / Aastra 142d), se deben establecer los siguientes flujos IP: Un canal de señales desde y hacia el teléfono SIP. Un canal de señales desde y hacia el OMM. Una interfaz de control entre el OMM y la RFP que tenga una conexión a la PP (conocida como la RFP primaria). Una conexión de Protocolo en Tiempo Real (RTP) / Protocolo de Control en Tiempo Real (RTCP) entre el teléfono SIP y la RFP primaria. En el esquema siguiente se ilustra esta situación. Aastra depl-0900/0.4 Página: 13 (112)

14 Para establecer una llamada entre dos PP se deben establecer los mismos flujos IP que en la situación anterior, con la diferencia de que no hay un teléfono IP implicado. En el esquema siguiente se ilustra esta situación. Una llamada de una PP a otra que reside en la misma RFP hará un bucle dentro de la RFP, si no se utiliza una puerta de medios. Así, la llamada no pasará a través de la Red de Área Local (LAN). Aunque los paquetes de voz no afectarán al tráfico de la LAN, los paquetes de señales sí. Aastra depl-0900/0.4 Página: 14 (112)

15 Si el usuario de la PP se está moviendo, la PP detecta que otra RFP tiene más intensidad de señal y, por lo tanto, comienza el proceso de transferencia. El flujo de medios del teléfono IP no se puede desplazar a la RFP secundaria, así que la RFP primaria utiliza la LAN para dirigir la voz a la RFP secundaria, como se muestra en la figura siguiente: Cuando el usuario de la PP se desplaza hacia la siguiente zona de cobertura de una RFP, la PP detecta que dicha RFP tiene una mejor intensidad. De nuevo, el flujo de medios del teléfono IP no se puede desplazar a la RFP secundaria, así que la RFP primaria utiliza la LAN para dirigir la voz a la nueva RFP secundaria, como se muestra en la figura siguiente. Aastra depl-0900/0.4 Página: 15 (112)

16 2.5 Sincronización de las RFP Para garantizar una transferencia sin cortes si un llamante se desplaza de la zona de cobertura de una RFP a otra, resulta necesaria una sincronización precisa de las RFP. Las RFP se sincronizan mediante una interfaz inalámbrica. La primera RFP que realiza un inicio transmite una señal de radio para sincronizarse con las otras RFP. Si una RFP se sincroniza, entonces transmite una señal y será la fuente de sincronización para la siguiente RFP. Sólo se sincronizarán las RFP que puedan recibir una señal de sincronización. Para que una RFP se sincronice con otra, la intensidad de la señal no puede estar por debajo de -70 dbm. Debe considerar este requisito durante la inspección del emplazamiento. Mientras una RFP no esté en sincronización, no se pueden establecer llamadas utilizando dicha RFP. Aastra depl-0900/0.4 Página: 16 (112)

17 Si una RFP pierde la sincronización, no aceptará nuevas llamadas ( bit de ocupado ). Hay un plazo máximo de 3 minutos hasta que las llamadas activas en esta RFP se finalizan. Entonces, intenta sincronizarse de nuevo. Una instalación IP DECT es más fiable si una RFP puede recibir la señal desde más de una sola RFP, porque las otras señales se utilizan también para la sincronización. La solución de sincronización inalámbrica es muy fiable, porque todas las rutas existentes se utilizan para la sincronización, aunque se repitan. Así, las tolerancias de hardware tienen sólo muy poca influencia. Ninguna RFP tiene una posición clave. Sólo las configuraciones desfavorables sin rutas de sincronización redundantes pueden causar problemas. Algunas veces, las RFP no necesitan sincronizarse, p.e., si están en diferentes edificios. Estas RFP se pueden poner en clusters diferentes. Las RFP de clusters diferentes no se sincronizarán entre ellas. Los diferentes clústeres se inician al mismo tiempo de manera independiente. 2.6 Capacidad de los canales de la RFP La RFP tiene 12 franjas temporales disponibles: 8 pueden tener recursos DSP asociados para flujos de medios. Las 4 franjas temporales restantes se utilizan para, p.e., señales de control entre RFP y PP, y para propósitos de entrega. Si se utilizan los 8 canales de flujo de medios, la RFP comunica un bit de ocupado. En ese caso, los PP determinan si otra RFP tiene una intensidad de señal apropiada. Si es así, la PP se transferirá a dicha RFP. Una vez se haya completado la transferencia, la RFP bajará su bit de ocupado. Aastra depl-0900/0.4 Página: 17 (112)

18 Siempre que se comunica un estado de ocupado, se realiza una entrada del registro en los registros del sistema. Si dicha comunicación de ocupado ocurre en una zona específica, se deberá instalar otra RFP para duplicar el número de flujos de medios disponibles para llamadas. 2.7 Acerca de las Partes Móviles Parte Móvil (PP) es terminología estándar de DECT y, dentro del contexto de la solución DECToverIP using SIP, se puede utilizar indistintamente con un terminal (handset). Aastra ofrece los siguientes terminales (handsets): - 142d - 610d - 620d - 630d 142d 610d 620d 630d Tenga en cuenta las diferencias normativas entre Norteamérica y todas las demás zonas del mundo. Estas diferencias llevan a diversas variantes del 142d, que utilizan bandas de frecuencia e intensidades de campo específicas: Aastra DECT 142 (NA) - Banda de Frecuencia de 1920 a 1930 MHz - 60 canales dúplex mw (salida máxima por canal activo) - 5 mw (salida media por canal activo) Aastra depl-0900/0.4 Página: 18 (112)

19 Aastra 142d (EMEA) - Banda de Frecuencia de 1880 a 1900 MHz canales dúplex mw (salida máxima por canal activo) - 10 mw (salida media por canal activo) El 610d / 620d / 630d soporta los requisitos normativos NA (Norteamérica) y EMEA (Europa, Oriente Medio y África). Además del Aastra DECT 142 / Aastra 142d, existen teléfonos estándar DECT GAP de otros fabricantes que pueden funcionar dentro de la solución DECToverIP using SIP. Sin embargo, sus funciones podrían estar limitadas, según el modelo de teléfono. 2.8 Capacidad del sistema Sólo hay un OpenMobility Manager (OMM) activo en el sistema. La capacidad del OMM es: Se pueden controlar hasta 256 RFP (Puntos de Acceso). Se pueden gestionar hasta 512 PP (terminales móviles). Es posible desactivar la parte DECT de una RFP. Si la interfaz DECT se desactiva, entonces los recursos (CPU y memoria) están disponibles para el OMM. Aastra depl-0900/0.4 Página: 19 (112)

20 3 Instalación y configuración Para establecer y mantener una instalación IP DECT, se asume una infraestructura en red, que comprende al menos los componentes siguientes: RFP PP IP PB / servidor de medios (por ej., Asterisk) Servidor TFTP Dependiendo de los modos de operación deberían proporcionarse los siguientes servicios: DHCP SNTP DNS LDAP Syslog daemon Nota: En la región de NA (Norteamérica), las RFP para exteriores sólo se pueden instalar con la antena enviada junto con las unidades. No está permitido utilizar ningún otro tipo de antena ni de cableado. En la región de EMEA, las RFP para exteriores se envían sin antena y se pueden utilizar las unidades con una de las antenas opcionales (número de pedido independiente). 3.1 Inicio de OpenMobility Inicio de las RFP Para arrancar una RFP, debe haber al menos un servidor TFTP en la red adjunta para cargar el software de aplicación OMM / RFP. La configuración de red básica se puede, bien Comunicación a través de un servidor DHCP en el momento de arranque. O configurar en la RFP con la herramienta OM Configurator. Los ajustes realizados por el OM Configurator se guardarán permanentemente en la memoria flash interna de cada OMM / RFP. La RFP obtiene el archivo de imagen de arranque de un servidor TFTP. El servidor TFTP utilizado tiene que soportar Sección 1.3 referencia /1/. El servidor DHCP utilizado tiene que soportar Sección 1.3 referencia /4/. Los servidores TFTP y DHCP no tienen por qué residir en el mismo host Perspectiva general del arranque El arranque se lleva a cabo en dos pasos: 1. Inicio del proceso de arranque. 2. Inicio de la aplicación. Aastra depl-0900/0.4 Página: 20 (112)

21 Arranque La RFP tiene sólo una pequeña aplicación autónoma integrada en la flash. Este software realiza el denominado proceso de arranque en red. Durante el arranque, cada RFP intenta determinar su propia dirección IP y otros ajustes de la interfaz IP a partir de los ajustes de configuración en la memoria flash interna. Si los ajustes no están disponibles o si están desactivados, la RFP intenta determinarlos a través de DHCP. La RFP obtiene el archivo de imagen de arranque de un servidor TFTP. Aplicación Tras iniciar la imagen de aplicación, la RFP verifica los ajustes de red local en su memoria flash interna una vez más. Si los ajustes no están disponibles o si están desactivados, inicia un cliente DHCP para determinar la dirección IP del OMM y otros ajustes de arranque Arranque del OpenMobility Manager No hay diferencias entre el inicio de la RFP que se elige para que funcione en modo OMM de las que están sólo en modo RFP. La decisión está dirigida por la dirección IP del OMM, que se lee dentro de los ajustes de red local, si están activos. a través de una solicitud DHCP. La RFP cuya dirección IP coincide con la destinada al OMM, será la RFP en la que el software de OMM funcione Arranque Cliente DHCP Dentro del proceso de arranque inicial, el cliente DHCP soporta los parámetros siguientes: Dirección IP obligatorio Máscara de red obligatorio Puerta de enlace obligatorio Nombre de fichero de arranque obligatorio Servidor TFTP obligatorio Public option 224: gopenmobilityh obligatorio Solicitud DHCP Identificador de clase del fabricante (code 60) El cliente DHCP envía el identificador de clase del fabricante OpenMobility Lista de parámetros solicitados (código 55) Aastra depl-0900/0.4 Página: 21 (112)

22 El cliente DHCP, en el arranque, solicita las opciones siguientes en la lista de parámetros solicitados: Opción máscara de subred (código 1) Opción ruter (código 3) Opción pública 224 (código 224) Opción pública 225 (código 225) Opción pública 226 (código 226) Aastra depl-0900/0.4 Página: 22 (112)

23 Oferta DHCP El cliente DHCP selecciona el servidor DHCP de acuerdo con las normas siguientes: Las opciones públicas (código 224) tienen un valor igual a la cadena OpenMobility o el campo archivo en el mensaje DHCP tiene una subcadena igual a ip_rfp.cnt. Si ninguna de las dos normas de más arriba concuerda, la oferta DHCP se ignora. Información recuperada de la oferta DHCP: La dirección IP a utilizar se toma del campo yiaddr del mensaje DHCP. La máscara de red IP se toma de la opción máscara de subred (código 1). La puerta de enlace predeterminada se toma de la opción ruter (código 3). La dirección IP del servidor TFTP se toma del campo siaddr del mensaje DHCP. El nombre de archivo de imagen de arranque se toma del campo file del mensaje DHCP; si este campo está vacío, se utiliza el nombre de archivo predeterminado "iprfp.bin" Reintentos Si el cliente DHCP no obtiene una oferta DHCP apropiada, se envía una nueva solicitud DHCP tras 1 segundo. Una vez que se envíen 3 solicitudes DHCP, el cliente DHCP se desactivará durante 60 segundos. Durante este tiempo el arranque aceptará una configuración local con el OM Configurator (OMC). Este ciclo se repetirá cada 3 minutos hasta que TODAS las opciones DHCP se proporcionen o el sistema se configure de manera manual utilizando la herramienta OM Configurator Cliente TFTP El cliente TFTP descargará la imagen de aplicación del servidor TFTP. Tanto el servidor TFTP como el nombre de la imagen de aplicación se proporcionan a través del cliente DHCP. La imagen de aplicación está protegida con una suma de verificación. Aastra depl-0900/0.4 Página: 23 (112)

24 3.1.4 Aplicación Tras descargar e iniciar la aplicación con éxito, la RFP determinará la dirección IP del OMM a partir del DHCP. El cliente DHCP es capaz de recibir respuestas DHCP broadcast y unicast. Por lo tanto, el campo flags es 0x0000. La solicitud DHCP contiene la consabida cookie mágica (0x ) y la opción final (0xFF). Los parámetros siguientes se soportarán dentro de este paso: Opción / Campo Significado Obligatoriedad yiaddr Dirección IP de la IP - RFP sí siaddr file Parámetro denominado Nombre del Host del Servidor de Arranque, con un valor igual a la dirección IP del servidor TFTP Parámetro denominado Nombre de fichero de arranque, con el valor de la ruta (opcional) y el nombre de la imagen de aplicación. Por ejemplo, omm_ffsip.tftp. code 1 Máscara de subred sí code 3 Puerta de enlace predeterminado sí code 6 Servidor de Nombres de Dominio No code 15 Nombre de Dominio No code 42 Dirección IP de un servidor NTP No code 43 Opciones Específicas del Fabricante sí public option 224 El parámetro denominado magic_str se debe fijar en el valor OpenMobility. sí sí sí Las Opciones Específicas del Fabricante consisten en: Opción Específica del Fabricante option 10 Significado Longitud Obligatoriedad ommip1: Utilizada para seleccionar la IP - RFP en que debe radicar el OpenMobility Manager (OMM) 4 sí option 14 option 15 option 17 option 18 option 19 syslogip: dirección IP de un Syslog Daemon syslogport: Puerto de un Syslog Daemon País: Se utiliza para seleccionar el país en el que se ubica el OMM. Esto permite utilizar tonos específicos para cada país (como el tono de ocupado, el de llamada, etc.) ntpservname: Nombre de un Servidor NTP ommip2: Se utiliza para seleccionar una IP RFP secundaria que albergue el OpenMobility Manager (OMM) de 4 No 2 No 2 No x No 4 No Aastra depl-0900/0.4 Página: 24 (112)

25 option 24 redundancia o secundario. Esta opción debe seleccionarse si se desea utilizar la función de Redundancia de OMM (ver el capítulo 5). rsturl: Restaurar URL URL para una importación automática de una base de datos OMM (ver capítulo ) x No Un ejemplo de los contenidos mínimos para el valor del parámetro de la opción 43 sería: 0a 04 C0 A siendo C0 A la representación de que es la IP de OMM. La opción 43 contiene una cadena de códigos en formato hexadecimal con el formato "número de la opción" "longitud" "valor" en este caso 0a = opción 10 (ommip1)0a = opción 10 (ommip1) 04 = el valor que le sigue consiste de 4 bloques C0 A = En caso de haber más de una opción, la siguiente se añade a continuación de la anterior. Dependiendo el servidor DHCP puede ser necesario acabar la opción 43 con FF. Se soportan tonos para los países siguientes: código país del país 1 Alemania 2 Reino Unido 3 Suiza 4 España 6 Italia 7 Rusia 8 Bélgica 9 Países Bajos 10 Checo 11 Austria 12 Dinamarca 13 Eslovaquia 14 Finlandia 15 Hungría 16 Polonia 17 Bielorrusia 18 Estonia 19 Letonia 20 Lituania 21 Ucrania 22 Noruega 24 Suecia 25 Taiwán 100 Norteamérica 101 Francia 102 Australia Actualización del arranque Cada aplicación de software viene con el último software de arranque publicado. El SW de aplicación actualiza el programa de arranque de manera automática. Aastra depl-0900/0.4 Página: 25 (112)

26 Advertencia:Después de una actualización de OpenMobility de la versión 1.1.x a la versión 1.7.x, el software de arranque de las RFP se actualizará a la versión 3.3.x. Se necesita el OpenMobility Configurator 1.7.x para configurar las RFP con esta nueva versión del software de arranque. Si se rebajan las RFP a una versión más antigua, el software de arranque no quedará rebajado automáticamente Selección del servidor DHCP adecuado El cliente DHCP solicita su propia dirección IP utilizando el código 50. El cliente DHCP seleccionará el servidor DHCP que ofrezca la dirección IP actualmente utilizada. Además, las opciones obligatorias se deben ofrecer, de lo contrario la oferta DHCP se ignorará por parte del cliente DHCP. Si no se recibe una respuesta que concuerde, el cliente DHCP reenvía la solicitud 2 veces tras transcurrir 1 segundo. Después, el cliente DHCP esperará 1 minuto antes de reenviar 3 solicitudes de nuevo. Si el cliente DHCP no puede aceptar una oferta DHCP en el plazo de 3 minutos, la RFP se arranca de nuevo Estado del LED de la RFP Las siguientes imágenes muestran el estado de los LED de una RFP según los diferentes estados durante el arranque. La RFP L32 IP tiene tres LED distintos (uno rojo, uno naranja y otro verde) para mostrar los diferentes estados durante el arranque. RFP 32 NA / RFP L32 IP Unused LED LED green (Application) LED orange (Application) LED red (Booter) Ethernet jack Power supply in line with Power over Ethernet standard IEEE 802.3af Power jack (120 V/230 V AC adapter) Estado Estado del LED Observaciones Booter (Start up) Rojo continuo Esperando para conectarse Booter DHCP Rojo intermitente 0,5 Hz Lanzando una solicitud DHCP y Aastra depl-0900/0.4 Página: 26 (112)

27 Estado Estado del LED Observaciones esperando una oferta DHCP Booter (TFTP) Rojo intermitente 2,5 Hz Descargando la imagen de aplicación Application (DHCP) Naranja continuo Lanzando una solicitud DHCP y esperando la respuesta DHCP Application (init) Verde intermitente 0,5 Hz La RFP está iniciando sus componentes internos Application (init) Verde intermitente 1 Hz La RFP intenta conectarse al OMM Application (init) Verde intermitente (2 segundos encendido, 0,5 segundos apagado) La parte DECT de la RFP no funciona (o no está configurada o no está sincronizada con las otras RFP) Application (init) Verde La RFP está conectada y funcionando La RFP L42 WLAN dispone de un LED adicional que describe el estado de la WLAN: Estado Módulo WLAN no encontrado WLAN desactivada porque está funcionando el OMM WLAN desactivada por configuración WLAN desactivada por velocidad de 10 Mbps 1 WLAN activa y funcionando Estado del LED WLAN Rojo continuo apagado apagado Verde intermitente 1 Hz Verde 1 La RFP L42 WLAN debe estar conectada a un Ethernet 100BaseT para que el servicio WLAN funcione. Aastra depl-0900/0.4 Página: 27 (112)

28 RFP L42 WLAN LED for WLAN LED green (Application) LED orange (Application) LED red (Booter) Ethernet jack Power supply in line with Power over Ethernet standard IEEE 802.3af Power jack (120 V/230 V AC adapter) Aastra depl-0900/0.4 Página: 28 (112)

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

30 3.2 Configuración local estática de una RFP Como alternativa a la configuración DHCP, las RFP / OMM se pueden configurar estáticamente utilizando la herramienta OM Configurator. El OM Configurator precisa el entorno Java Runtime versión 1.6 o superior. Los ajustes, que se configuran en la RFP con la herramienta OM Configurator, se guardarán de manera permanente en la memoria flash interna de una RFP. Los parámetros configurables a través del OM Configurator cumplen con la opción DHCP, consulte la sección para más detalles. Si se ha realizado una configuración estática local, el DHCP no se usa más. En la imagen siguiente se muestra el OM Configurator. En sistemas con múltiples adaptadores de Ethernet, seleccione el interfaz que desea utilizar para la configuración de las RFP's. Para configurar una RFP, debe asignar un valor al menos a la dirección MAC y a todas las opciones obligatorias (ver la tabla más abajo). La dirección MAC se debe introducir con un formato como éste: xx-xx-xx-xx-xx-xx. Si la RFP ya tiene una dirección IP, introduzca esta dirección en el campo de dirección IP. En este caso, puede ponerse en contacto con la RFP desde fuera del segmento de LAN local. Opcional. Para fijar los parámetros adicionales, haga clic en el botón "Agregar parámetro" y elija el parámetro deseado. Aastra depl-0900/0.4 Página: 30 (112)

31 IMPORTANTE: Marque la casilla "sí" en "Utilizar configuración local" en la RFP, si no se utilizará el DHCP. Haga clic en el botón Enviar configuración para transmitir los parámetros a una RFP. Parámetros de arranque (de acuerdo con las opciones DHCP) Parámetro Tipo Significado Utilizar local: Dirección IP Máscara de red configuración Dirección del Servidor TFTP Nombre de Archivo TFTP Dirección IP del OMM obligatorio El parámetro define si se deben utilizar los valores de configuración local al arrancar o no. obligatorio Dirección IP de la RFP obligatorio Máscara de subred obligatorio Dirección IP del servidor TFTP obligatorio El fichero de arranque debe ser leído del servidor TFTP durante el arranque. obligatorio Dirección IP del gestor OpenMobility. Direcciones del router opcional Dirección IP de la pasarela predeterminada Direcciones DNS opcional Dirección IP del servidor DNS Dominio DNS opcional Nombre de dominio de la red Dirección de broadcast opcional Segunda dirección IP del OMM opcional La dirección de broadcast para esa red Dirección IP del OMM redundante/secundario País opcional Define el país en el que se encuentra el OMM con el fin de poder gestionar los tonos de llamada específicos para cada país. Direcciones Servidor NTP del Nombre del servidor NTP opcional opcional Dirección IP de un servidor NTP Nombre de un Servidor NTP VLAN ID opcional Identificador de VLAN Dirección IP de Syslog opcional Dirección IP de destino para el syslog Puerto Syslog opcional Puerto de destino para el syslog Restaurar URL opcional URL para una importación automática de una base de datos OMM (ver capítulo ) OMM en modo proxy opcional Modo experto Aastra depl-0900/0.4 Página: 31 (112)

32 La configuración sólo se puede establecer tras el encendido o en la fase de reintento (LED intermitente a 0,25 Hz), o en el modo núcleo (kernel), consulte la sección 3.1 para más detalles. La herramienta de configuración espera 2 segundos y reintenta la transmisión de los datos 3 veces. Si desea acceder a los parámetros de configuración desde una RFP, configure además las direcciones MAC e IP y haga clic en el botón Configuración de lista. Todos los parámetros aparecerán en la herramienta OM Configurator. Pulse el botón Reiniciar configuración para borrar todos los campos de entrada y parámetros adicionales. Desde la versión 1.5 de OpenMobility se pueden utilizar datos de acceso para evitar cambios de configuración no autorizados. Si desea utilizar este tipo de autorización, marque la casilla Acceso e introduzca el nombre de usuario y la contraseña en los correspondientes campos Usuario y Contraseña. Esta versión de OM Configurator es compatible con versiones anteriores de OpenMobility que no soporten datos de acceso. Una contraseña que no se recuerde no se podrá recuperar, pero sí borrar mediante el botón Valores predeterminados. Envíe la cookie mostrada al servicio de soporte del fabricante de OpenMobility. Tras recibir la clave de reinicio de contraseña del servicio de soporte, introdúzcala en el diálogo Introducir clave de reinicio. Con esto también se borrará la configuración local por completo de la memoria flash interna del RFP! Advertencia: El restablecimiento de la contraseña tiene como consecuencia que toda la configuración local incluyendo la configuración de OpenMobility se borre. Una RFP que se encuentre fuera del segmento LAN local también podría funcionar como proxy. Marque la casilla como proxy para habilitar esta funcionalidad. Para dirigirse a una RFP en el segmento LAN de la RFP proxy se utilizará la dirección MAC. Con el mecanismo de proxy también se podría utilizar un barrido de RFP disponibles y la configuración de varias RFP mediante un archivo de configuración. Aastra depl-0900/0.4 Página: 32 (112)

33 Utilice el botón Buscar para encontrar RFP disponibles en el segmento LAN local o, a través del mecanismo de proxy, en segmentos LAN externos. Todas las direcciones MAC de las RFP encontradas se mostrarán en la lista izquierda de la RFP. Los LED de estado y el botón de actualizar quedan deshabilitados tras la búsqueda de RFP. La lista de RFP se puede guardar mediante el botón Guardar RFP. Esto permite a un administrador editar los datos de configuración de varias RFP mediante una aplicación tipo editor de texto o una hoja de cálculo como se describe en el capítulo Aastra depl-0900/0.4 Página: 33 (112)

34 El archivo de configuración creado se puede cargar mediante el botón Cargar config.. Los archivos de registro con información de estado sobre la edición y la ejecución del archivo y los datos de configuración se almacenan en el mismo directorio. Utilice el botón Ejecutar config. para iniciar la configuración iterativa de varias RFP mediante el archivo de configuración creado y cargado. Los LED indicarán si la configuración se ha realizado correctamente o ha fallado. Consulte el contenido del archivo de registro para obtener más información. Si fallase la configuración para una RFP, se debería repetir utilizando el botón de actualización situado junto a los LED. Tenga en cuenta que se aplicarán los datos de acceso y del proxy para todo el archivo de configuración. Aastra depl-0900/0.4 Página: 34 (112)

35 3.3 Configuración del OpenMobility Manager El OMM funciona en una RFP designada, dentro de una instalación SIP - DECT. El OMM se designa a través de las opciones DHCP o se indica estáticamente por medio de la herramienta OM Configurator. Todas las demás RFP de la instalación se configuran para apuntar al OMM en la instalación. El OMM se puede configurar a través de HTTP/HTTPS. El OMM funciona como servidor HTTP/HTTPS. El servidor HTTP se conecta al puerto 80 y el HTTPS al 443 por defecto. Los valores de configuración se leen de la memoria flash interna. La configuración se guarda en un fichero de texto ASCII. No está permitido cambiar el fichero de configuración fuera del OMM: El archivo de configuración se puede descargar y cargar a través de la interfaz de la web. El acceso al servicio está restringido a una sesión activa a la vez y está protegido por contraseña. El navegador utilizado para el acceso al servicio deberá ser, como mínimo, Microsoft Internet Explorer 6.0 o Mozilla Firefox 1,5, debe soportar marcos y tener activadas las cookies y JavaScript Procedimiento de Inicio de Sesión en el Servicio El OMM permite que sólo un usuario configure el sistema a la vez. Un usuario se debe autenticar con un nombre de usuario y contraseña. En los dos se distingue entre mayúsculas y minúsculas. Tras la instalación inicial o tras eliminar el archivo de configuración, se puede acceder al servicio OpenMobility a través de una cuenta de usuario integrada, en la que el usuario es omm y la contraseña omm. Aastra depl-0900/0.4 Página: 35 (112)

36 La primera vez que el usuario entra en una nueva versión de OpenMobility, tiene que aceptar el contrato de licencia de usuario final (EULA). En caso de que la cuenta de usuario integrada por defecto se encuentre activa, el administrador deberá cambiar la contraseña para el Acceso Total y la cuenta de root. El significado de los distintos tipos de cuenta se describe en el capitulo 4.2 y 4.3. Aastra depl-0900/0.4 Página: 36 (112)

37 Tras el inicio de sesión, hay disponibles las siguientes opciones: Visualización del estado del sistema Configuración de los parámetros generales del sistema SIP - DECT. Administración de las RFP adjuntas. Administración de los terminales PP (configuración del dispositivo final). Configuración de los parámetros WLAN. Administración de algunas funciones de sistema como el tratamiento de dígitos y del directorio. Visualizando el acuerdo de licencia End User Licence Agreement (EULA) Si no se produce ninguna acción del usuario durante 5 minutos, el OMM cierra la sesión. Para cerrar la sesión del sistema, haga clic en el botón "Cerrar sesión". Aastra depl-0900/0.4 Página: 37 (112)

38 Nota: Si el navegador se cierra sin salir de la sesión primero, el acceso al servicio estará bloqueado para otros clientes durante 5 minutos Sistema Ajustes del sistema Los ajustes del sistema cubren la configuración global del OpenMobility Manager, como: Nombre del sistema Acceso remoto Activa/desactiva el acceso ssh para todas las RFPs del sistema DECT. Código de autentificación DECT. El código de autenticación se utiliza durante el registro inicial del terminal PP como opción de seguridad (ver el capítulo 3.3.4). El código que se introduce aquí será utilizado como código de autenticación DECT para todas las nuevas PP (ver capitulo ). Este código es opcional. PARK Cada red DECT requiere una clave PARK única. Introduzca la clave PARK como aparece en la etiqueta del CD de OpenMobility. Es obligatoria. Cifrado, como se describe en el capítulo Campo Normativo, como se describe en el capítulo Monitor DECT Para supervisar el comportamiento del sistema DECT del OpenMobility Manager, se entrega una aplicación aparte. Esta herramienta necesita un acceso al OpenMobility Manager, que está desactivado de manera predeterminada y que se puede activar en la página del sistema. Por motivos de seguridad, el valor de la casilla de activación del monitor DECT no se guarda de manera permanente en la memoria flash interna del OMM/RFP. Después de un reinicio, la casilla de activación del monitor DECT queda siempre deshabilitada. Parámetros ToS para paquetes de voz y TTL (Time to Live) Para hacer posible la priorización de Paquetes de Voz y / o de Señales (SIP) dentro de la red utilizada, el parámetro IP ToS (Tipo de Servicio) se debe configurar aquí. Parámetros Syslog OpenMobility Manager y las RFP son capaces de transmitir mensajes de syslog. Esta función se puede configurar, al igual que la dirección IP del host que recopila dichos mensajes. Parámetros de Fecha y hora Aastra depl-0900/0.4 Página: 38 (112)

39 Si no se utiliza NTP, la fecha y la hora se pueden configurar en el OMM. Esto se ha de realizar para proporcionar la fecha y la hora al DECT 142 Handset / Aastra 142d. Las reglas para una franja horaria, que se muestran en esta página web, se pueden configurar en la sección de Franjas horarias del servicio web (ver capitulo ). Observe que, en el caso de que no se utilice SNTP, la date and time se ha de configurar tras cada reinicio de la RFP en la que el OpenMobility Manager está funcionando. La fecha y la hora las proporcionará el OpenMobility Manager al DECT 142 Handset / Aastra 142d si el terminal inicia un registro de localización DECT. Este ocurrirá en los casos siguientes: Registro en el OMM Entrar en la red de nuevo tras perder la señal DECT Encendido La función de carga silenciosa está activa en el teléfono y éste se quita del cargador Tras un plazo específico para actualizar la fecha y la hora Please, enter the PARK key as labelled on the OpenMobility CD Aastra depl-0900/0.4 Página: 39 (112)

40 Reinicio del OMM Para reiniciar el OMM, seleccione Configuración del sistema en el árbol de navegación y después seleccione "Reinicio". Existe además la opción de reiniciar los datos de configuración. Entonces, se carga una página web de reinicio, se muestra una barra de progreso y la página web de inicio de sesión se carga automáticamente si el OMM está disponible de nuevo Codificación El cifrado sólo está disponible en los productos RFP 32/34/42. Por lo tanto, sólo se puede activar en la página web Configuración del sistema si no hay otras variantes Aastra RFP conectadas al OMM. Si la codificación está activa y otra variante RFP se conecta al OMM, su interfaz inalámbrica DECT no se activará. Nota: Los PP deben soportar el cifrado DECT, que no es una función obligatoria Campo normativo Para definir dónde se utiliza el IP DECT, se ha de configurar el parámetro campo normativo. Las instalaciones existentes se actualizan al valor predeterminado EMEA (ETSI). Para configurar una instalación que cumpla con la norma norteamericana FCC, el valor se ha de fijar en "US (FCC/CI)". En una instalación norteamericana en EE. UU. (FCC/CI), las RFP que cumplen con la ETSI se desactivan y no se pueden activar si el campo normativo se fija a "US (FCC/CI)". También funciona al revés. Sólo los terminales americanos (FCC/CI) DECT 142 se pueden conectar a las RFP/OMM diseñadas para el mercado de EE. UU. y configuradas para utilizar el campo normativo estadounidense (FCC/CI). Aastra depl-0900/0.4 Página: 40 (112)

41 SIP La configuración SIP cubre todos los ajustes globales que corresponden a las señales SIP y a los flujos de voz RTP. Servidor proxy Dirección IP o nombre del servidor proxy SIP. Si se utilizan un nombre de host y dominio para el parámetro de servidor proxy, asegúrese de que se especifican un servidor DNS y un dominio para su sistema SIP - DECT a través de DHCP o de la herramienta OM Configurator. Puerto proxy Número de puerto del servidor proxy SIP. El puerto predeterminado es el Para activar el soporte DNS SRV para búsquedas de proxy, ponga un valor de 0 en el puerto proxy. Servidor de registro Dirección IP o nombre del servidor de registros SIP. Permite a los PP registrase en un servidor de registros. Si se utilizan un nombre de host y dominio para el parámetro de servidor proxy, asegúrese de que se especifican un servidor DNS y un dominio para su sistema SIP - DECT a través de DHCP o de la herramienta OM Configurator. Puerto de registro Número de puerto del Servidor de registros SIP. El número de puerto predeterminado es Para activar el soporte DNS SRV para búsquedas del servidor de registros, ponga un valor de 0 en el puerto de registro. Período de registro El período de registro solicitado en segundos, a partir del servidor de registros. El puerto predeterminado es Servidor proxy de salida Dirección del servidor proxy de salida. Todos los mensajes SIP que vienen del OMM se envían a este servidor. Por ejemplo, si tiene un Controlador de Sesiones en su red, entonces pondría normalmente su dirección aquí. Opcional. Puerto proxy de salida El puerto proxy del servidor proxy al que el OMM envía todos los mensajes SIP. Opcional. Suscripción MWI explícita Algún Servidor de Medios como el Asterisk soporta la indicación de mensaje en espera (Message Waiting Indication, MWI) basado en /15/. Si el usuario ha recibido un mensaje de voz en su buzón de voz y el Servidor de Canales IP lo soporta, aparecerá un icono de MWI en el Aastra DECT 142 Handset / Aastra 142d. Si la suscripción MWI explícita está activada, el OMM envía por cada PP un mensaje de suscripción MWI al servidor proxy o al servidor proxy de salida. Aastra depl-0900/0.4 Página: 41 (112)

42 Información sobre el usuario / agente Si está activado, el OMM envía información sobre su versión dentro de las cabeceras SIP User-Agent/Server. Enviar terminador de marcado IEstando habilitado el OMM no utiliza el carácter '# para determinar si los datos de entrada introducidos por el usuario están completos. En su lugar, el OMM espera durante 4 segundos a que el usuario introduzca más datos una vez que ha pulsado un digito de marcado. En caso de estar habilitado, el carácter # puede formar parte de la información de marcado. Temporizador de reintento de registro Especifica el tiempo, en segundos, que espera el OMM entre intentos de registro cuando el servidor de registros los rechaza. Temporizador de transacción El tiempo, en milisegundos, que el OMM concede al servidor de llamadas (proxy o servidor de registros) para responder a los mensajes SIP que envía. Si el OMM no recibe una respuesta en el tiempo especificado en este parámetro, el OMM asume que el mensaje ha caducado. En este caso, el servidor de llamadas se añade a la lista negra. El rango de valores permitidos es de 4000 a El valor por defecto es Caducidad de lista negra El tiempo, en minutos, que un servidor de llamadas no disponible permanece en la lista negra. El rango de valores permitidos es de 0 a El valor predeterminado es 5. Base de puerto RTP Cada RFP necesita una zona de puertos continua de 68 puertos UDP para los flujos de voz RTP. La Base de Puertos RTP es el número de puerto de inicio de esa zona. El puerto predeterminado es Códec preferente 1 5 Especifica una lista de preferencia personalizada de códecs, que le permite utilizar los códecs preferentes. El códec 1 tiene la prioridad más alta y el 5 la más baja. Supresión de silencio Se utiliza para configurar si se prefiere o no la supresión del silencio. DTMF Out-of-Band Se utiliza para configurar si se prefiere DTMF Out-of-Band o no. Método DTMF El OMM soporta los siguientes métodos DTMF Out-of-Band: o RFC 2833 Transmite DTMF como eventos RTP de acuerdo con RFC 2833 ( /9/), después de la negociación del tipo de datos de transporte por medio de SIP/SDP. En caso de Aastra depl-0900/0.4 Página: 42 (112)

43 que el tipo de datos de transporte no haya sido negociado, se utilizará inband de manera automática. o INFO El método SIP INFO se utiliza para transportar los tonos DTMF como eventos del teléfono (application/dtmf-relay). Esta opción es la correcta en caso de que no se soporte la RFC o AMBOS Los eventos DTMF del teléfono se transmiten de acuerdo con RFC 2833 así como por medio del método SIP INFO. Nota: Es posible que el receptor detecte un evento dos veces. Tipo de carga útil Si Out-of-Band está activado, el parámetro Tipo de carga útil especifica el tipo de carga útil que se utiliza para enviar eventos DTMF, según lo descrito en la Sección 1.3 referencia /9/. Aastra depl-0900/0.4 Página: 43 (112)

44 Cuenta de usuario Tras la instalación inicial o tras eliminar el archivo de configuración, se puede acceder al servicio OpenMobility a través de una cuenta de usuario integrada, en la que el usuario es omm y la contraseña omm. El nombre de usuario y la contraseña distinguen entre mayúsculas y minúsculas y se pueden cambiar en la página web "Cuenta del usuario". Aastra depl-0900/0.4 Página: 44 (112)

45 El significado de los distintos tipos de cuenta se describe en el capitulo 4.2 y Zonas horarias En el capítulo se describe una resincronización de la hora y la fecha de los terminales Aastra DECT 142 / Aastra 142d. En la sección de zona horaria, el OpenMobility Manager proporciona todas las zonas horarias disponibles. Se establecen con las normas de horarios de verano y de invierno conocidas, ajustadas al Horario Universal Coordinado (UTC) predeterminado. La diferencia con el horario UTC se muestra en la columna Diferencia de UTC. En caso de que haya horarios de verano e invierno configurados, también se indica en cada zona horaria. Existe la posibilidad de cambiar las normas de las zonas horarias en, como máximo, cinco zonas. Las normas cambiadas se marcan con el nombre de la zona en negrita en la tabla. Los cambios se guardan en el archivo de configuración y se restauran tras cada arranque del OpenMobility Manager. El botón Predeterminado vuelve a establecer los valores predeterminados de todas las zonas horarias y elimina las normas modificadas de zonas horarias en el archivo de configuración. Aastra depl-0900/0.4 Página: 45 (112)

46 Con el cuadro de diálogo "Configurar zona horaria", se pueden modificar la hora estándar y la configuración de verano o invierno (DST) de una zona horaria. Si la zona horaria no dispone de DSP, sólo se podrán configurar la diferencia con el UTC. Para la DST, ambos puntos temporales (inicio del horario de verano y de invierno) se han de especificar exactamente. Por lo tanto, se podrá utilizar un cierto día de un mes o de una semana. Observe las siguientes capturas de pantalla a modo de ejemplo: Aastra depl-0900/0.4 Página: 46 (112)

47 Gestión de la base de datos La gestión de la base de datos permite una gestión flexible de copias de seguridad y restauraciones de la base de datos OMM. La base de datos OMM contiene todos los ajustes de configuración que pueden configurarse a través de la interfaz del servicio WEB. La base de datos OMM puede: - Importarse manualmente desde el sistema de archivos del navegador WEB o desde un servidor externo - Importarse automáticamente desde un servidor externo - Exportarse manualmente al sistema de archivos del navegador WEB o a un servidor externo - Exportarse automáticamente a un servidor externo en caso de modificar la configuración Aastra depl-0900/0.4 Página: 47 (112)

48 La base de datos OMM se guardará en un fichero comprimido de formato propietario. Cualquier modificación de este archivo fuera del OMM no está permitida. Se soportan los siguientes protocolos para el transporte a un servidor externo o desde el mismo: - FTP - TFTP - FTPS - HTTP - HTTPS Importación manual de una base de datos Para importar una base de datos desde el sistema de archivos del navegador WEB debe seleccionarse el protocolo FILE. Introduzca la ruta y el archivo que incluye la base de datos OMM y pulse el botón Cargar. Antes de que el OMM acepte la base de datos, se realizará Aastra depl-0900/0.4 Página: 48 (112)

49 una comprobación de validación. Si se comprueba que la base de datos es válida, el OMM será reiniciado para activar la nueva base de datos. Después del reinicio, todas las configuraciones de la base de datos restaurada surtirán efecto, pero no los ajustes de la cuenta de usuario. Los ajustes de la cuenta de usuario sólo pueden modificarse localmente a través del servicio WEB del OMM y nunca se restauran por medio de la importación de una base de datos. Advertencia:Una importación manual o automática de una base de datos hace que produzca un reinicio del OMM. Para importar una base de datos desde un servidor externo, seleccione el protocolo preferido e introduzca la dirección IP o el nombre del servidor externo. Si fuera necesario, introduzca los datos de la cuenta (nombre de usuario / contraseña) del servidor y seleccione la ruta y el nombre de archivo desde donde deba restaurarse la base de datos. A continuación, pulse el botón Cargar Exportación manual de una base de datos Para exportar una base de datos manualmente a un servidor externo, seleccione el protocolo preferido e introduzca la dirección IP o el nombre del servidor. Si fuera necesario, introduzca los datos de la cuenta (nombre de usuario / contraseña) del servidor y seleccione la ruta y el nombre de archivo donde deba guardarse la base de datos. A continuación, pulse el botón Guardar. Aastra depl-0900/0.4 Página: 49 (112)

50 Si la base de datos se exporta al sistema de archivos del navegador WEB (protocolo: FILE), la base de datos se guardará en un archivo especificado por el usuario Importación automática de una base de datos La función de importación automática de una base de datos facilita la restauración de una base de datos OMM preparada en el OMM para una configuración inicial o con motivo de una actualización. El archivo de base de datos para una importación automática debe configurarse en un formato URL como o {ftp ftps http https}://[[usuario:contraseña@]servidor]/[directorio/]archivo tftp://servidor]/[directorio/]archivo Para estar disponible en el momento de arrancar el OMM y para permitir una configuración inicial a través de la importación automática, esta URL ha de ser especificada a través del DHCP (opción 24 / ver capítulo 3.1.4) o del OM Configurator (ver capítulo 3.2). Si la URL es proporcionada por el DHCP o por el OM Configurator, el OMM intentará importar automáticamente un archivo de base de datos configurado durante el arranque del OMM. Además de la importación durante el arranque, el servicio WEB permite activar/desactivar la importación automática de una base de datos a una hora configurable del día. Si se activa Arranque y periódicamente, el OMM intentará importar el archivo de base de datos configurado durante el arranque y a la hora configurada del día. La URL del archivo configurada a través del DHCP o del OM Configurator siempre se visualiza. Aastra depl-0900/0.4 Página: 50 (112)

51 Advertencia: Para una importación automática de la base de datos a una hora configurada se recomienda una sincronización de hora con un servidor NTP. Para la configuración del servidor NTP, ver el capítulo y el capítulo 3.2. Antes de que una base de datos sea aceptada y reemplazada por medio de un proceso de importación automático, el OMM realiza las siguientes comprobaciones: - La integridad del archivo debe ser correcta - Para evitar la importación repetida del mismo archivo, la suma de verificación del nuevo archivo de base de datos y la suma de verificación del último archivo de importación de base de datos (almacenado en la memoria flash) deben ser diferentes - Por motivos de autorización/autenticación: El PARK del nuevo archivo de base de datos debe ser el mismo que el PARK de la configuración actual. - La cuenta de administrador/de acceso total del nuevo archivo de base de datos debe ser la misma que la de la configuración actual El archivo de base de datos sólo se aceptará si todas estas comprobaciones son correctas. Si el archivo de base de datos no se acepta o no se encuentra, se visualizará un mensaje de error en la página de estado del servicio web del OMM. Advertencia:Una importación manual o automática de una base de datos hace que produzca un reinicio del OMM. La importación automática de una base de datos OMM permite cambiar todos los ajustes de la configuración, pero no los ajustes de cuenta y el PARK. Excepción: es posible cambiar la cuenta de usuario y el PARK por defecto para una configuración inicial. Tras la configuración inicial, los ajustes de la cuenta de usuario y el PARK sólo podrán modificarse a través del servicio web en el propio OMM de destino. Aastra depl-0900/0.4 Página: 51 (112)

52 Exportación automática de una base de datos La función de exportación automática de una base de datos permite crear una copia de seguridad automática de la base de datos en un servidor externo para cualquier modificación de la configuración. Si está activada esta función, el OMM transferirá un archivo de copia de seguridad a un servidor externo configurado cada vez que se produzca un cambio en la configuración, p.ej. el registro de un terminal. Si no hay cambios en la configuración no se realizará ninguna copia de seguridad. Un archivo de copia de seguridad se sobrescribirá durante un día si hay más de una modificación. Se creará un nuevo archivo cuando se produzca el primer cambio del día. El OMM escribirá la base de datos en un archivo, ubicado en el servidor externo, con la siguiente convención de nombre: <yymmdd>_<system_name>_<park>_omm_conf.gz Advertencia: Para la exportación automática de una base de datos es obligatoria una sincronización de hora con un servidor NTP. Para la configuración del servidor NTP, ver el capítulo y el capítulo Configuración RFP Todas las RFP configuradas se enumeran en tablas agrupadas por clusters según sus relaciones topográficas. Las RFP están ordenadas por sus direcciones de Ethernet (MAC). Para garantizar la transferencia correcta de una PP durante una llamada, todas las RFP implicadas deben ofrecer la misma señal de reloj a la PP. Esto se consigue teniendo sincronizadas las RFP. La sincronización se lleva Aastra depl-0900/0.4 Página: 52 (112)

53 a cabo colocando las RFP s tan cerca unas de otras que todas ellas detectan al menos a otra a través del interfaz aire. Hay situaciones en las que la sincronización no es posible, por ejemplo si hay RFP en ubicaciones remotas. En este caso, las RFP se agruparán en clusters diferentes. El OpenMobility Manager no intentará sincronizar RFP más allá de los límites de un grupo. Todos los clústeres se muestra en la barra de navegación a la izquierda y la RFP OMM se indica en negrita. Cuando las RFP se están conectando al OMM, envían su tipo de HW. Este tipo se muestra en la página web de la lista de RFP Creación y cambios de RFP Botones nuevo, cambiar y borrar Se pueden agregar nuevas RFP al sistema pulsando el botón "Nuevo. Aparecerá una ventana emergente que proporcionará la configuración de una nueva RFP. Aastra depl-0900/0.4 Página: 53 (112)

54 Cada RFP se identifica a través de su dirección MAC (formato hexadecimal de 6 bytes, separada por dos puntos). La dirección Ethernet es única y se puede encontrar en la parte de atrás del bastidor. Para una administración más fácil, cada RFP se puede asociar con una cadena de ubicación. La cadena de ubicación puede contener hasta 20 caracteres. La funcionalidad DECT se puede activar o desactivar para cada RFP. Si el DECT está activo, la RFP se puede añadir a un clúster. La sección WLAN sólo está disponible para RFP L42 WLAN. En la sección 'Configuración de WLAN de la página se puede seleccionar Perfil, Diversidad de antena, Antena, Nivel de salida de potencia y Canal. En general, Diversidad de antena debería desactivarse (es decir, marcarse) para que el AP pueda seleccionar automáticamente la antena con las mejores características de transmisión y recepción. Nota importante: Una RFP que esté configurada como OMM no puede funcionar simultáneamente como Punto de Acceso WLAN. Para más detalles acerca de la configuración WLAN puede consultar el capitulo La misma ventana emergente se puede abrir, para una RFP existente, haciendo clic en el icono de herramienta de la RFP correspondiente. Una RFP se puede eliminar pulsando el icono de la papelera. Una ventana emergente similar pedirá la confirmación, mostrando la configuración actual de esa RFP Importar archivos de configuración También se puede configurar un conjunto de RFP de forma semiautomática mediante la importación de un archivo de configuración. Haga clic en el botón Importar para acceder al menú correspondiente: Seleccione su archivo de configuración y haga clic en el botón Importar (ver Anexo para obtener información sobre la estructura del archivo). Puede leerse un protocolo de edición si se hace clic en el botón Archivo de registro. Todos los registros de datos importados correctamente se presentan en una lista: Aastra depl-0900/0.4 Página: 54 (112)

55 Para añadir las RFP a la base de datos del OMM, selecciónelas mediante el botón circular y haga clic en Añadir. Todos los registros almacenados correctamente se marcan en verde en la columna llamada Añadido (los registros fallidos muestran una estrella roja y pueden obtenerse pistas sobre el error en el correspondiente archivo de registro o en una traza de syslog) Captura de RFP Las RFP que estén asignadas al OMM por las opciones de DHCP o por los parámetros del OM Configurator se pueden conectar al sistema. Pulse el botón Iniciar correspondiente en la página de lista de RFP. Después de un tiempo, en la página de lista aparecen las direcciones MAC de aquellas RFP que han intentado registrarse en el OMM. Tenga en cuenta que estas entradas no se almacenan realmente (se pierden después de un reinicio). Haciendo clic en el icono de herramienta de la RFP correspondiente se pueden añadir más datos y guardar la RFP. Aastra depl-0900/0.4 Página: 55 (112)

56 Estados de una RFP Para cada RFP se muestra el estado del subsistema DECT. Los estados son: Síncrono La RFP está conectada y funcionando. La RFP reconoce y es reconocida por otras RFP de su cluster a través de su interfaz inalámbrica y ofrece una señal de reloj síncrona a los PP. Asíncrono La RFP no ha sido de sincronizarse con sus vecinas todavía. No es posible la comunicación DECT. Sin embargo, la RFP ya ha podido conectarse al OMM. Esta fase suele durar normalmente sólo unos segundos, tras el inicio de la RFP o del OMM: Si este estado dura más, indicaría un fallo del hardware o de la red. Buscando La RFP ha perdido la sincronización con sus vecinas. No es posible la comunicación DECT. Esta fase suele durar normalmente sólo unos segundos, tras el inicio de la RFP o del OMM: Si este estado dura más o se vuelve a entrar en él tras un estado síncrono, indicaría una ubicación incorrecta de la RFP. Inactiva La RFP se ha conectado al OMM, pero la interfaz inalámbrica no se ha activado todavía. En el caso de cualquier RFP con la funcionalidad DECT activada, esta fase debería durar sólo unos cuantos segundos tras el inicio de la RFP. Si este estado dura más, indicaría un fallo del hardware. No conectada La RFP se configuró, pero no se ha conectado con el OMM todavía. Por lo tanto, la columna de dirección IP está vacía. Aastra depl-0900/0.4 Página: 56 (112)

57 Modelo de HW del RFP Cuando las RFP se están conectando al OMM, envían su tipo de HW. Este tipo se muestra en la página web de la lista de RFP Verificación de la versión del software del OMM / RFP Cuando las RFP se están conectando al OMM envían su versión de software. Si está versión difiere de la versión de software del OMM, la conexión con la RFP se rechaza. Esto podría pasar cuando se utilizasen varios servidores DHCP con diferentes versiones de software OpenMobility. En este caso, la RFP se marca con un mensaje de error. Además, se muestra un mensaje global de error la página web de la lista de las RFP si, al menos, dos versiones de software no concuerdan entre sí Configuración de los Terminales En la página web de Dispositivos finales se encuentran todos los terminales DECT (Terminales Móviles) ordenados por su número. Para que la lista sea breve, la lista completa se divide en sublistas que contienen hasta 100 terminales. El usuario puede moverse hacia delante y hacia atrás en grupos de 100 terminales. Como la función de navegador no se puede utilizar para buscar un cierto terminal en todas las sublistas, hay disponible una función de búsqueda, que permite encontrar un terminal por un número o IPEI determinado. Aastra depl-0900/0.4 Página: 57 (112)

58 La columna Descarga sólo se muestra si la función "Descarga inalámbrica" se ha iniciado correctamente y da información sobre el estado de descarga (ver capítulo 6) Creación y cambios de PP Botones nuevo, cambiar y borrar Añadir Terminales al sistema SIP - DECT Se pueden añadir nuevos terminales PP al sistema pulsando el botón "Nuevo. Aparecerá la siguiente ventana emergente, que permite la configuración de un nuevo dispositivo PP. El parámetro Nombre representa el campo Nombre SIP que se muestra en pantalla. Este parámetro es opcional pero se recomienda. El Número es el número de cuenta SIP o la extensión de la PP. El IPEI es el número IPEI del terminal DECT 142 que se puede encontrar en el menú Opciones del Sistema del terminal DECT 142. El código de autentificación DECT se utiliza durante la inscripción DECT inicial como una opción de seguridad y se puede establecer aquí para cada Aastra depl-0900/0.4 Página: 58 (112)

59 PP, de manera individual. Si se ha introducido un código de autenticación DECT en la página web en el apartado de Configuración de Sistema, este será utilizado aquí por defecto. Este parámetro es opcional. Nota: El código de autentificación sólo se puede cambiar si la PP no está inscrita. El nombre de la PP se puede cambiar, pero no tendrá efecto hasta que se inscriba la PP de nuevo. El ID adicional puede utilizarse como medio de búsqueda de datos dentro del registro libre (debido a que el IPEI no está configurado, de otra forma se seleccionarían los datos). El Nombre de Usuario de Autentificación SIP es opcional pero se recomienda. Representa el nombre que se utilizará durante el registro y la autentificación SIP. Si no se proporciona ningún nombre, se utilizará de manera predeterminada el número. La contraseña se utilizará durante el registro y la autentificación SIP. Modificar Terminales en el sistema SIP - DECT Cuando se configure una PP existente haciendo clic en el icono de herramienta, aparecerá una ventana emergente. La única diferencia entre la ventana emergente para añadir PP o para modificarlas es la casilla de eliminar el registro. Si se selecciona esta opción, el registro de la PP se borrará. Eliminación de Terminales del sistema SIP - DECT La eliminación de un PP se puede realizar pulsando el icono de la papelera. Aparecerá una ventana emergente solicitando la confirmación Importar archivos de configuración También se puede configurar un conjunto de PP de forma semiautomática mediante la importación de un archivo de configuración. Haga clic en el botón Importar para acceder al menú correspondiente: Seleccione su archivo de configuración y haga clic en el botón Importar (ver Anexo para obtener información sobre la estructura del archivo). Puede leerse un protocolo de edición si se hace clic en el botón Archivo de registro. Todos los registros de datos importados correctamente se presentan en una lista: Aastra depl-0900/0.4 Página: 59 (112)

60 Para añadir los PP a la base de datos del OMM, selecciónelos mediante el botón circular y haga clic en Añadir. Todos los registros almacenados correctamente se marcan en verde en la columna llamada Añadido (los registros fallidos muestran una estrella roja y Aastra depl-0900/0.4 Página: 60 (112)

61 pueden obtenerse pistas sobre el error en el correspondiente archivo de registro o en una traza de syslog) Registro Preparación mediante el servicio OMM WEB Tras añadir la configuración de una PP al OMM, la PP se debe registrar. Primero, se debe activar el OMM para que permita el registro de terminales PP. Esto se realiza haciendo clic en los siguientes botones de la página web Dispositivos finales OMM. Botón de inicio de la sección Registro con IPEI configurados Este botón habilita el registro para las siguientes 24 horas. o Botón de inicio e intervalo de tiempo de la sección Registro libre Este botón habilita el Registro libre para el tiempo seleccionado. Después de expirar el plazo, el Registro con IPEI configurados seguirá habilitado durante 24 horas. Para facilitar la primera instalación de un sistema DECT, el registro estará permanentemente habilitado mientras al menos una PP (con IPEI) esté configurada dentro de la base de datos y ninguna PP esté registrada. Después del registro correcto de la primera PP, el registro seguirá habilitado durante 24 horas. Pasos del registro de un PP Una vez que la configuración de los PP está completa en el OMM y que el OMM está permitiendo nuevas subscripciones, se debe registrar cada PP en el sistema. En cada terminal PP, el administrador o usuario debe registrarse en el sistema SIP - DECT a través del menú Sistema / Subscripciones. Para registrarse en el sistema, se deberá introducir el código PARK específico para el sistema SIP - DECT. IMPORTANTE:el código PARK en formato numérico se puede encontrar en la esquina superior derecha de la página web Dispositivos finales OMM. Cada instalación SIP - DECT tendrá un código PARK único, suministrado con el kit de activación OMM. Si el administrador ha configurado un código de autentificación Dispositivo final DECT global o individual, el administrador / usuario deberá introducir el código antes de registrar la PP en el sistema. En caso de Registro libre, tenga en cuenta que puede configurarse un ID adicional (ver sección Registro libre), que debe ser introducido en ese momento. Aastra depl-0900/0.4 Página: 61 (112)

62 Si un administrador / usuario tiene algún problema con el registro en el sistema SIP - DECT, se recomienda que apaguen su terminal PP y reintenten el registro. Con esto se finaliza el proceso de registro de una PP en el sistema SIP - DECT Registro con IPEI configurado Los datos a asignar al PP que se está registrando se identifican mediante el IPEI. Además, el IPEI ofrece mayores garantías para no recibir registros no autorizados incluso si no se ha configurado AC como medio de mejorar la seguridad. Para permitir registros, haga clic en el botón Inicio de la sección Registro con IPEI configurados : Registro libre El OMM permitirá un registro de terminales PP configurados pero no registrados sólo durante una hora. El administrador debe pulsar una vez más el botón Suscribir para permitir que más PP se registren en el sistema SIP - DECT. Con el fin de minimizar el esfuerzo administrativo, también es posible el registro si el IPEI no está configurado. Pero debido a la pérdida de seguridad por no comprobar el IPEI, este tipo de registro sólo está permitido en un intervalo corto de tiempo, por defecto 2 minutos. Para permitir los registros, haga clic en el botón Inicio de la sección Registro libre y aumente el intervalo de tiempo si fuera necesario (o refresque el permiso de registro): El OMM permitirá un registro libre durante el intervalo de tiempo definido. En caso de que expire el temporizador se perderá el permiso. Sólo permanece activo el registro con IPEI dentro del límite fijo de una hora (ver el capítulo anterior). Para lograr una selección de datos durante el registro (por ejemplo, el nombre de usuario asignado al PP) puede definirse el campo ID adicional en los datos del OMM. Si el OMM recibe un ID adicional válido durante el registro, se asignan los datos correspondientes al PP. Si es necesario el ID adicional para un registro de datos, el usuario del PP tendrá que teclearlo. ID adicional puede definirse en el menú de código de autenticación. Introduzca la clave-r y escriba el ID adicional. Advertencia:La entrada del ID adicional sólo es posible con el terminal Aastra 142 DECT / Aastra 142d. No existe la posibilidad de introducir ese valor en teléfonos GAP de otros fabricantes. Si los teléfonos GAP se registran mediante registro libre, se seleccionará y asignará el primer registro de datos libre del PP sin ningún ID adicional. Aastra depl-0900/0.4 Página: 62 (112)

63 Búsqueda en la lista de PP Búsqueda de Terminales en el sistema SIP - DECT Si el usuario desea encontrar un cierto terminal, puede utilizar la función de búsqueda. Haciendo clic en el botón Buscar mostrará la siguiente ventana emergente. El usuario puede introducir el número o el IPEI del terminal. Al menos se habrá de fijar uno de los parámetros. El número o IPEI introducido ha de concordar exactamente con el número o IPEI del terminal. Si se proporciona un número y un IPEI determinados, para que aparezca un terminal, éste ha de concordar con los dos parámetros, si no se producirá un fallo en la búsqueda. Si se encuentra un terminal con el número y / o IPEI especificados se mostrará una lista con dicho terminal como primera entrada. La función de búsqueda se puede utilizar también para obtener la sublista correcta en un paso. Aastra depl-0900/0.4 Página: 63 (112)

64 3.3.5 Configuración de WLAN (sólo RFP L42 WLAN) La configuración correcta de una RFP con un terminal WLAN requiere primero la configuración correcta del terminal DECT. El segundo paso es especificar el campo normativo de la red WLAN en la página web del sistema en el servicio web OMM. Campo normativo País 0x10: FCC EE.UU., Australia 0x20: IC Canadá 0x30: ETSI Europa (excepto España y Francia) 0x31: ESPAÑA España 0x32: FRANCIA Francia 0x40: MKK Japón 0x41: MKK1 Japón (MKK1) Esta configuración depende del país y está definida por las leyes del mismo. Sólo debe utilizarse la configuración definida para ese país. El tercer paso es especificar los parámetros de la WLAN en un perfil. Aquí se introduce el nombre (SSID) de la red WLAN y otros parámetros. Los procedimientos de cifrado y autenticación son especialmente importantes y deben planificarse en detalle con antelación. Aastra depl-0900/0.4 Página: 64 (112)

65 El punto de acceso puede asignarse a una VLAN que cumpla 802.1q. Todos los datos que se reciban desde los clientes WLAN y que se envíen a dichos clientes son transportados por una VLAN. Todos los datos que no cumplan esta condición, como paquetes de VoIP, datos de configuración o datos de autenticación (Radius), reciben el código de VLAN de la RFP. El puerto del elemento de red al que se conecta el punto de acceso debe estar configurado como puerto de enlaces. Los parámetros del perfil tienen valores predefinidos. Parámetro Rango Notas Periodo de señalización 50 65,535 milisegundos La duración de los intervalos entre señales o balizas. Periodo DTIM señales El número de señales entre dos transmisiones DTIM (Delivery Traffic Indication Map, o mapa de indicación de tráfico de entrega). Umbral RTS Bytes Las tramas de monodifusión y gestión que superen el valor umbral aquí especificado se transmiten a través de un procedimiento de intercambio de saludo RTS/CTS. Umbral de fragmentación Bytes Las tramas de monodifusión que superen el valor aquí especificado serán fragmentadas. Tasa máxima 1; 2; 5,5; 6; 9; 11; 12; 18; 22; 24; 36; 48; 54 Mbps La tasa máxima de transmisión entre el punto de acceso WLAN y el cliente WLAN. Modo b/g Mixto, sólo b, sólo g Modo de conexión SSID oculto Sí / No Cancela la transmisión del SSID. Eliminación de Sí / No Un procedimiento para evitar Aastra depl-0900/0.4 Página: 65 (112)

66 interferencias Parámetros de seguridad Filtro de acceso MAC Aislamiento de BSS Longitud del cifrado Intervalo de distribución Parámetros de Radius Parámetros de SSID múltiple interferencias. Parámetros de cifrado (ver abajo) 1 64 Clientes autorizados (lista blanca) Sí / No Evita que los clientes WLAN se detecten entre sí. 64 / 128 / 256 Bits La longitud de la clave utilizada en los modos de seguridad. Segundos Dirección IP, Puerto, Secreto Nombre del SSID, parámetros de VLAN y Seguridad El intervalo entre intercambios de la clave. Parámetros del servidor Radius. 1 a 3 SSID adicionales Se puede configurar un sistema abierto, es decir, un sistema en el que todos los procedimientos de autenticación y cifrado estén desactivados, seleccionando el elemento Sistema abierto. El parámetro Aislamiento de BSS evita que los clientes WLAN contacten entre sí a través del mismo AP. Nota:La RFP L42 WLAN debe estar conectada a un Ethernet 100BaseT para que el servicio WLAN funcione Optimización de la WLAN Intervalo de señalización La transmisión de señales o balizas requiere capacidad de transmisión. Reduciendo la duración del intervalo de señalización se aumenta la capacidad de la red WLAN para detectar señales, mejorando así su disponibilidad. Al mismo tiempo, esto aumenta la capacidad de la red para ajustar la intensidad de la señal, negociada de forma mutua. Un valor mayor, es decir, un mayor intervalo de señalización, reduce indirectamente el consumo de potencia del cliente WLAN. Umbral RTS Si el caudal de la red es bajo o hay muchas retransmisiones, puede activarse el aclarado de RTS reduciendo el valor del umbral RTS. Esto puede mejorar el caudal, especialmente en aquellos entornos en los que la reflexión y la atenuación causen problemas en HF. Umbral de fragmentación En entornos en los que existan muchas interferencias y la calidad del canal radio sea mala, reducir el tamaño de los fragmentos puede mejorar el caudal eficaz. Sin embargo, en este caso las tramas transmitidas tienen que ser fragmentadas más a menudo, lo que implica una mayor carga para el procesador del AP. Aastra depl-0900/0.4 Página: 66 (112)

67 Periodo DTIM El periodo DTIM especifica el intervalo entre transmisiones de los paquetes de broadcast y multidifusión. Todos los clientes WLAN deben estar activos durante este intervalo. Un aumento del periodo DTIM reduce ligeramente el consumo de potencia del cliente. Sin embargo, no todos los programas pueden gestionar el aumento en los tiempos de respuesta Seguridad de la WLAN con Radius Para lograr que las comunicaciones en la red WLAN sean seguras pueden tomarse varias medidas. Primero, los paquetes de datos transmitidos a través de la interfaz radio abierta y visible deben estar cifrados, y segundo, todos los componentes que formen parte de la red o que proporcionen servicios deberían autenticarse. Para lograr esto, se crea lo que se denomina un sistema AAA (Autenticación, Autorización, Contabilización). La RFP L42 WLAN funciona como un servidor de acceso a red y un servidor Radius actúa como servidor AAA. La RFP L42 WLAN funciona como el servidor de red y puede redirigir la Autenticación a un servidor Radius de la red. El cifrado de los datos transmitidos entre la RFP L42 WLAN y el cliente WLAN se realiza mediante WPA (Acceso protegido a Wi-Fi) con 802.1x (Radius) o 802.1x (Radius) con cifrado WEP. Es necesario introducir la dirección IP, el puerto y la contraseña común del servidor en el perfil Radius. Un servidor Radius (Servicio de usuario de marcación para autenticación remota) maneja la Autenticación 802.1x y autoriza al cliente. Recomendamos utilizar un servidor Radius con EAP-TLS (por ejemplo, FreeRadius o MS Windows 2003 IAS Server) y una Autoridad de Certificación (CA). Su cliente WLAN deberá soportar estos métodos de autenticación y debe disponer de los certificados relevantes (la mayoría de los clientes WLAN pueden hacerlo). Es necesario un sitio de certificación para generar las claves, el cual debe ser conocido para el cliente WLAN y para el servidor Radius. Debe introducirse la dirección IP, el puerto y el secreto común del servidor Radius en la sección de configuración de Radius. Aastra depl-0900/0.4 Página: 67 (112)

68 En el último paso, hay que asignar un perfil a las RFP y a los Puntos de Acceso (AP). Todos los AP deben estar configurados a un canal. Por ello, asegúrese de que las frecuencias de los canales AP no se solapan. Los AP que se encuentren en el rango de otros AP deben estar al menos a cinco canales de distancia. Esto se configura en la pantalla de configuración de AP. Cuando se realice la planificación radio, deben de tenerse en cuenta los AP de cualquier otra WLAN que pueda funcionar en sus proximidades. Aastra depl-0900/0.4 Página: 68 (112)

69 Cuando planifique la cobertura radio para un área bidimensional, tenga en cuenta que la distancia entre dos estaciones base cualquiera que funcionen con la misma frecuencia deben estar al menos al doble de distancia de su rango. El rango se puede ajustar con la ayuda del parámetro de nivel de salida de potencia. A través del menú Partes Fijas de Radio pueden agregarse nuevos AP y asignarse RFP configuradas a una red WLAN. A tal efecto, seleccione la entrada Perfiles WLAN en la lista Ordenado por. Aastra depl-0900/0.4 Página: 69 (112)

70 En la sección Configuración de WLAN de la página se puede seleccionar Perfil, Diversidad de antena, Antena, Nivel de salida de potencia y Canal. En general, Diversidad de antena debería desactivarse (es decir, marcarse) para que el AP pueda seleccionar automáticamente la antena con las mejores características de transmisión y recepción. La sección WLAN sólo está disponible para la RFP L42 WLAN. IMPORTANTE: Una RFP que esté configurada como OMM no puede funcionar simultáneamente como Punto de Acceso WLAN Requisitos para la WLAN Para el funcionamiento de clientes WLAN, es un prerrequisito utilizar adaptadores WLAN que cumplan el estándar b o el g. En lo referente al cifrado WEP y WPA y a la utilización de infraestructura Radius, es necesario asegurar que los adaptadores de la red WLAN que funcionen bajo el sistema operativo del cliente soporten los modos requeridos. Sin embargo, siempre es necesario comprobar la operabilidad de los adaptadores antes de su puesta en servicio Propiedades del sistema Configuración centralizada del acceso LDAP Los siguientes parámetros se configuran por medio del servicio web OMM. La configuración es válida para todos los terminales PP para los que se haya habilitado la llamada por nombre LDAP. El OMM soporta el enlace simple de LDAP Aastra depl-0900/0.4 Página: 70 (112)

71 Descripción del campo: Nombre del servidor y puerto (obligatorio) - Nombre del servidor o dirección IP del servidor - Puerto del servidor (predeterminado: 389) Nota: SSL (puerto predeterminado 689) no se soporta Directorio raíz La base de búsqueda debe ser editada (p. ej. "ou=people, o=my com"). Nombre de usuario y contraseña de usuario El nombre de usuario (un nombre característico) y la contraseña deben ser introducidos, si así lo requiere el servidor LDAP. De lo contrario se crea un enlace anónimo. Nota: El DECT IP OMM soporta el enlace simple de LDAP Atributos de búsqueda Las búsquedas se realizarán para uno de los siguientes atributos de búsqueda - Apellido (sn)-> (predeterminado) // apellido - Nombre (nombre de pila) Atributos de visualización Se puede elegir una de las dos siguientes opciones - Nombre (de pila) y apellido (sn) - Nombre (de pila) y apellido (sn) Tiempo de búsqueda del servidor (rango: 1 99 segundos) Serán válidos los resultados de la búsqueda dentro del límite de tiempo. Aastra depl-0900/0.4 Página: 71 (112)

72 Tratamiento de los dígitos El tratamiento de dígitos sustituye, borra o inserta dígitos en los números recibidos por el Directorio Corporativo basado en Ldap. Los dígitos se tratan en dos pasos: Para empezar todos los caracteres inválidos como el espacio o los guiones se eliminan del número (p.ej. "+49 (30) " se sustituye por ). En un segundo paso se busca la mayor coincidencia con la lista de prefijos configurada. El prefijo se sustituye (p.ej. la mayor coincidencia para el número es el prefijo con la substitución ; el resultado es 4492 ). El tratamiento de dígitos se efectúa antes de que el número se envíe al menú del terminal. El rango de valores y sus límites: Hasta 128 entradas si el OMM está corriendo en una estación base IP DECT y 750 entradas si el OMM está corriendo en un servidor linux. Cada prefijo consta de los dígitos (0-9) y de los caracteres '* y #. De acuerdo con los estándares LDAP el primer carácter puede ser el '+. Se aceptan hasta 15 dígitos por secuencia. Los espacios están permitidos. Cada substituto consta del dígito (0-9) y de los caracteres "*" y "#" Códigos de acceso a funciones Los códigos de acceso a funciones permiten realizar acciones específicas en el OMM desde cualquier terminal DECT registrado. Aastra depl-0900/0.4 Página: 72 (112)

73 Para activar un código de acceso a funciones, seleccione un número FAC único, active la casilla de verificación apropiada e introduzca un código de acción asignado. A continuación podrá ejecutarse la acción apropiada marcando el Número FAC, seguido del Código de acción FAC en bloque desde cualquier terminal DECT registrado. En el ejemplo anterior, un usuario registrado puede activar el registro OMM DECT marcando 99999*4701# en bloque. Advertencia: La emisión solapada no será soportada para el FAC. El Número FAC y el Código de acción FAC deben introducirse en bloque. Las funciones FAC serán confirmadas al usuario mediante una indicación audible (señales acústicas dentro de la banda). Aastra depl-0900/0.4 Página: 73 (112)

74 4 Seguridad 4.1 El concepto de seguridad Además del acceso por https del OMM, cada RFP individual dispone de dos opciones de acceso, el OM_Configurator y un acceso por ssh. Cada uno de estos 3 tipos de acceso independientes utiliza los mismos datos de cuenta o datos de acceso. Los datos de cuenta pueden ser modificados en la interfaz https del OMM. El OMM ofrece todos los datos de cuenta necesarios a todas las RFP conectadas. Las RFP guardan los datos de cuenta en su memoria permanente. Esto tiene algunas implicaciones: Una RFP recién sacada de su caja utiliza los datos de cuenta por defecto hasta que no se conecte al OMM. Una RFP que se haya conectado al menos una vez con el OMM utilizará los datos de cuenta del OMM. Cuando se cambian los datos de cuenta en el OMM, cualquier RFP no conectada continuará utilizando las contraseñas anteriores. 4.2 Tipos de cuenta Existen 3 tipos de cuenta diferentes: 1. Acceso total Este tipo de acceso es el acceso normal para todas las operaciones de configuración. Mediante este acceso está permitido configurar el OMM y todas las RFP. El tipo de acceso permite iniciar una sesión en la interfaz ssh de una RFP para obtener información de depuración, como hacer ping a otra RFP para comprobar la visibilidad entre ellas. Los parámetros de serie para esta cuenta son Nombre 'omm' Contraseña: 'omm' Activo: 'n/a' 2. Acceso de sólo lectura Como el nombre indica, con este tipo de acceso no se puede configurar ningún elemento de la instalación del OMM. Este tipo de acceso sólo está permitido en la interfaz https. La cuenta puede estar desactivada. Los parámetros de serie para esta cuenta son Nombre: 'user' Contraseña: 'user' Activo: 'sí' 3. Acceso de root Este tipo de acceso sólo aplica en la interfaz ssh de una RFP. Su propósito es el de obtener información detallada, como por ejemplo los parámetros del kernel. El acceso mediante este tipo de cuenta no Aastra depl-0900/0.4 Página: 74 (112)

75 es alcanzable desde otros sistemas, por lo que es necesario utilizar un acceso de tipo total para iniciar la sesión. IMPORTANTE: Se recomienda encarecidamente no utilizar este tipo de cuenta. Su propósito es servir de acceso exclusivamente para el soporte técnico. Los parámetros de serie para esta cuenta son Nombre: 'root' Contraseña: '22222' Activo: 'n/a' https OM Configurator ssh Acceso total permitido permitido permitido Acceso de sólo lectura Permitido (pero con permiso para cambiar la configuración) No permitido No permitido Acceso de root No permitido No permitido Permitido (pero no directamente desde otros sistemas) 4.3 Cambio de los datos de cuenta El OMM forzará al usuario a modificar los datos de cuenta por defecto y definir su propia configuración. Mientras que no se cambien las contraseñas, el OMM no permitirá realizar ninguna otra configuración. Para cambiar la contraseña es necesario introducir de nuevo la contraseña anterior. El OMM tiene varias reglas para comprobar la complejidad de las nuevas contraseñas, por lo que no se aceptará una nueva contraseña cuando se incumpla alguna de estas reglas: cuando la contraseña nueva no sea de 5 o más caracteres de longitud, Aastra depl-0900/0.4 Página: 75 (112)

76 cuando la contraseña nueva no contenga caracteres de al menos 3 de los siguientes grupos: minúsculas, mayúsculas, números u otros caracteres, cuando la contraseña nueva tenga un 50% o más del mismo carácter ('World11111' o 'W1o1r1l1d1') o la contraseña nueva contenga uno de los siguientes elementos (ya sea en mayúsculas o en minúsculas, y ya sea en sentido normal o al revés): nombre de la cuenta nombre del sistema (dirección IP) contraseña anterior o 4.4 Obstáculos potenciales algunos caracteres adyacentes en el teclado (como por ejemplo 'qwert'). Cuando una RFP ha sido configurada por medio del OM Configurator y se utiliza fuera de su instalación la RFP puede que ya no funcione: Cuando esta RFP se vuelva a iniciar, encontrará una configuración válida en su memoria permanente. Por tanto, ignorará la consulta DHCP en su arranque. Pero cuando esta configuración ya no sea válida, (porque, por ejemplo, el servidor TFTP tenga una dirección IP nueva) la RFP no será capaz de completar el inicio y por tanto no podrá conectarse al OMM. La RFP no podrá obtener contraseñas nuevas del OMM. Por ello se recomienda apagar el OM Configuration antes de sacar la RFP de su instalación. Aún así, el OM Configurator permite reiniciar la memoria de una RFP (debe estar conectado el soporte Aastra DeTeWe). Aastra depl-0900/0.4 Página: 76 (112)

77 5 Redundancia de OMM Para lograr la redundancia de OMM, deben existir dos OpenMobility Managers en una red OMM. Uno funcionará como OMM maestro y el otro funcionará como OMM redundante o secundario. En caso de que la RFP designada como OMM maestro falle, la otra RFP designada como OMM secundario asume automáticamente el papel de OpenMobility Manager. 5.1 Cómo funciona la redundancia de OMM Durante el arranque del sistema, cada RFP IP obtiene una dirección IP de OMM (si no hay redundancia de OMM) o dos (si está configurada la redundancia de OMM), y ambas tratan de conectarse entre sí. El OMM activo o maestro tratará todas las conexiones de las RFP s. El OMM redundante o secundario rechazará todos los intentos de conexión de las RFP IP. 5.2 Introducción Durante el funcionamiento normal, tanto el OMM activo como el OMM redundante o secundario están en contacto y monitorizan su respectivo estado de funcionamiento. Intercambian continuamente sus estados actuales de redundancia y el OMM secundario recibe una copia de cualquier cambio de configuración realizado en el OMM activo. Siempre que ambos OMM estén en contacto entre sí, sus bases de datos se sincronizarán automáticamente. Si falla el OMM primario, el OMM secundario asume todas las responsabilidades del OMM con el fin de mantener el funcionamiento. Cuando esto ocurre, se muestra una advertencia de Sin redundancia en la interfaz web del OMM, indicando que ya no hay dos OMM funcionando en la red o en el cluster. Los cambios de configuración realizados en esta situación no son en modo seguro. Si falla el OMM activo, el OMM inactivo reconoce esta situación y comienza a actuar como OMM activo, iniciando el servicio web. Todas las RFP IP mantenidas por el OMM serán reiniciadas y todos los Terminales Móviles (PP) serán sincronizados de nuevo. Si falla la conexión entre los dos OMM, la red o el cluster se rompe en dos partes operacionales. El OMM redundante o secundario pasa entonces a ser el OMM activo. En este punto, los dos OMM no pueden detectarse entre sí y, por ello, no se pueden sincronizar. Cuando la conexión entre los dos OMM se restablece, la sincronización de los OMM fuerza a uno de ellos a convertirse en secundario de nuevo. Una vez que la RFP IP que falló recientemente vuelve a estar disponible y pasa a ser el OMM inactivo, no vuelve a asumir el papel de OMM activo otra vez. Aastra depl-0900/0.4 Página: 77 (112)

78 5.3 Configuración de la redundancia de OMM Cada RFP del sistema DECT tiene que ser configurada con dos direcciones IP de OMM. Estas direcciones de OMM se pueden configurar bien mediante DHCP (ver el capítulo 3.1.1) o con el OM_Configurator (ver el capítulo 3.2). 5.4 Situaciones de cambio de OMM activo El cambio de estado ocurre en los siguientes casos: - Se produce un error en el software de OMM en el OMM activo - La RFP actuando como OMM activo se apaga o se reinicia desde la consola ssh - El OMM se reinicia desde el menú del navegador web. - El OMM activo no responde El OMM redundante o secundario pasa a ser el OMM activo en los siguientes casos: - Se puede llegar al Proxy SIP o Servidor de registros - El otro OMM tiene una dirección IP mayor mientras no haya ningún OMM activo, y ambos OMM están en contacto entre sí (normalmente durante el arranque del sistema). Cuando los OMM pueden contactar entre sí de nuevo: - Ambos OMM comprueban cuál de ellos ha estado funcionando durante más tiempo. El que lo haya estado pasa a ser el OMM activo. El otro pasa a ser el OMM secundario. 5.5 Situaciones de fallo en el cambio de OMM activo Ocurrirá un fallo en el cambio de estado en los siguientes casos: - La conexión IP entre OMM falla y no se llega al Proxy SIP o el Servidor de registros configurado. En este caso, el OMM activo deberá esperar hasta que pueda llegar al Proxy SIP o Servidor de registros. El siguiente diagrama de estados muestra los estados de redundancia de OMM: Aastra depl-0900/0.4 Página: 78 (112)

79 OMM Reset with exit code 46 OMM sync NOK and PBX reachable OMM Start up or Restart OMM star up sync OK OMM Reset with exit code 45 OMM sync NOK and PBX unreachable PBX not reachable (registration and OPTIONS request failes) Unsynchronised Inactive OMM OMM sync OK OMM sync NOK Synchronised Inactive OMM OMM sync OK other OMM is active PBX reachable (registration or OPTIONS request OK) No OMM is active and I have the lowest IP address PBX not reachable (registration and OPTIONS request failes) Unsynchronised Active OMM OMM sync OK OMM sync NOK Synchronised Active OMM Another OMM is running for a longer period In this state the DECT air interface might not be in a definite state, when both OMMs are active but do not see each other! In this case a network problem occurs (broken into two parts) which is very theoretical and we can not handle. There might be two DECT systems with the same PARK active. For this case it is random which RFP is connected to the one or to the other OMM. In this state hand over might be reduced (not all RFPs might be synchronised). OMM sync OK only one OMM is active OMM sync OK means: OMMs are synchronised with each other and are able to exchange their operational states OMM sync NOK means: OMMs are not synchronised with each other and are not able to exchange their operational states 5.6 Situaciones específicas de redundancia Es necesario tener en cuenta algunos aspectos en caso de que cambie el estado de un OMM cuando no estén sincronizados Cómo pasa a ser activo un OMM redundante Como muestra la figura anterior, en caso de un estado no sincronizado de OMM, el OMM secundario tiene que decidir si se convierte en activo o no. Por ello, el OMM intenta contactar con el proxy SIP y servidor de registros configurados. El OMM inicia un registro SIP para el terminal con el menos número de teléfono y envía una petición de tipo OPTIONS al proxy configurado. Si hay respuesta, el proxy SIP o servidor de registros se considera como alcanzable y el OMM pasa a ser activo Funcionamiento cuando ambos OMM no están sincronizados En un estado de redundancia OMM sin sincronización, la conexión entre los OMM se rompe. En caso de un problema de red, ambos OMM pueden estar en este estado. Durante este periodo, el sistema OpenMobility es inconsistente y funciona con ciertas restricciones. Aastra depl-0900/0.4 Página: 79 (112)

80 El servicio WEB notificará el hecho con la advertencia Sin redundancia para ambos OMM y es posible que los cambios de configuración realizados en este estado no se guarden. En cualquier caso, cuando ambos OMM vuelven a estar en contacto de nuevo entre sí, el que haya estado funcionando durante más tiempo pasa a ser el activo, y ese OMM sobrescribirá el archivo de base de datos en el OMM secundario. Cualquier configuración realizada en este OMM que ahora pasa a ser el secundario se perderá! Dos interfaces inalámbricas DECT En caso de que ambos OMM se encuentren en un estado no sincronizado y activo al mismo tiempo, están funcionando completamente. Las RFP que pierdan la conexión con el OMM porque se haya caído la red podrían conectarse al otro OMM. Habría dos interfaces inalámbricas DECT presentes pero funcionando en paralelo. Nota: Ambas interfaces inalámbricas utilizan el mismo PARK. Luego no se puede determinar sobre qué OMM tiene éxito un registro de ubicación. En cuanto a los PP, es posible encontrarse con diferentes situaciones: - No se dan cuenta de esta situación o las llamadas activas siguen establecidas, dependiendo de las condiciones de la red o Los PP pueden hacer y recibir nuevas llamadas, dependiendo de la disponibilidad de la conexión a la PABX o Los PP pueden hacer una transferencia a las RFP conectadas al mismo OMM o Los PP pueden llamar a otros PP que estén registrados en el otro OMM - Pierden su estación base RFP y realizan un nuevo registro de ubicación o las llamadas activas se desconectan o Los PP pueden hacer y recibir nuevas llamadas, dependiendo de la disponibilidad de la conexión a la PABX o Los PP pueden hacer una transferencia a las RFP conectadas al mismo OMM o Los PP pueden llamar a otros PP que estén registrados en el otro OMM - Pierden su estación base RFP y buscan la red DECT sin encontrar otra o las llamadas activas se desconectan o Los PP siguen buscando una red hasta que vuelve a existir una interfaz inalámbrica disponible Nota: No es posible la transferencia entre PP ubicados en RFP que estén controladas por diferentes OMM. Aastra depl-0900/0.4 Página: 80 (112)

81 Cuando los OMM vuelven a estar en contacto entre sí, termina esta situación de funcionamiento inconsistente del sistema OpenMobility. Aastra depl-0900/0.4 Página: 81 (112)

82 6 Descarga inalámbrica La función "Descarga inalámbrica" permite actualizar el firmware del terminal, sin ninguna interacción por parte del usuario ni interrupción del servicio telefónico, a través de la interfaz aire DECT existente. Esta función está actualmente disponible para los tipos de terminal 610d, 620d y 630d. 6.1 Cómo funciona la descarga inalámbrica Si está activada la función "Descarga inalámbrica", el OMM actúa como un servidor de descarga que proporciona el firmware para las descargas. La PP envía su versión de firmware real dentro del procedimiento de conexión DECT. Si la versión del firmware no coincide con la versión proporcionada por el OMM, la PP se pondrá en la cola de espera de actualización. Posteriormente las PP en cola de espera serán localizadas para establecer una conexión de descarga. Una vez establecida la conexión, el OMM enviará su versión de firmware PP real y la PP solicitará un archivo de descripción de terminal. Después de recibir el archivo de descripción de terminal, la PP decidirá qué archivos faltan o deben ser actualizados. Si hay archivos que faltan o deben ser actualizados, la PP iniciará el procedimiento de descarga. El OMM se encargará automáticamente de los siguientes escenarios de descarga. Si un terminal se vuelve ilocalizable, por ejemplo cuando el terminal está apagado, el OMM actualizará el terminal cuando la PP vuelva a estar disponible. El OMM se encargará de la descarga de software mientras el usuario se desplaza entre las estaciones base (roaming) y áreas de la localización. El OMM tiene la capacidad de reanudar una descarga en el punto en el que fue interrumpido por última vez, por ejemplo si el usuario abandona el área de cobertura durante la descarga o si el terminal se queda sin batería. El OMM actualizará los nuevos terminales registrados en el sistema. Mientras el terminal esté bloqueado (p. ej. si la batería está baja o la descarga inalámbrica está deshabilitada en el menú local) se pospondrá la descarga. La descarga se produce sin ninguna intervención del usuario. Durante la descarga, los servicios telefónicos y los procedimientos de roaming y transferencia seguirán estando disponibles. La descarga se detendrá automáticamente si, por ejemplo, la PP abandona el área de cobertura o si la RFP está ocupada. La descarga se reanudará automáticamente cuando se haya eliminado la causa de la detención. Aastra depl-0900/0.4 Página: 82 (112)

83 Los terminales 610d / 620d / 630d tienen dos particiones en la memoria flash interna con el fin de tener 2 versiones de software distintas. Durante la descarga, el nuevo firmware se escribe en una de las particiones y la PP se ejecuta desde la otra. El nuevo firmware no se activará hasta que: - El firmware se haya descargado completamente - Una prueba de consistencia se haya superado correctamente - El terminal se encuentre en estado libre. La descarga de una sola PP con un firmware de 1 MB dura alrededor de 90 minutos. Existen algunos motivos para que el terminal bloquee la descarga: Batería baja La potencia de la batería es inferior al 50 % y la PP no está conectada a la estación de acoplamiento o a la interfaz USB Software bloqueado La descarga inalámbrica está deshabilitada en el menú local del terminal Descarga fallida La cantidad de descargas fallidas es excesiva Sistemas múltiples Una PP puede estar registrada en varios sistemas OpenMobility. El primer sistema en el que se registre el terminal será automáticamente el sistema maestro. La PP sólo descargará desde el sistema maestro. En el menú local del terminal podrá seleccionarse un sistema maestro diferente. La cantidad de PP que pueden descargarse depende de los recursos disponibles del sistema. 6.2 Cómo configurar la descarga inalámbrica La función "Descarga inalámbrica" puede activarse o desactivarse en la pagina web Ajustes del sistema. Aastra depl-0900/0.4 Página: 83 (112)

84 El firmware de la PP forma parte de cada paquete de software OpenMobility suministrado por Aastra. El firmware de la PP se suministra en el archivo comprimido aafon6xxd.dnld. Este archivo comprimido deberá situarse en el mismo servidor tftp y en la misma ruta en donde la OMM-RFP obtiene su archivo de imagen de arranque (p. ej. omm_ffsip.tftp). Importante: Antes de situar un nuevo paquete de firmware del terminal en un servidor tftp, la función "Descarga inalámbrica" deberá desactivarse en la página web Ajustes del sistema. Después de la copia o instalación, la función "Descarga inalámbrica" podrá activarse de nuevo. El servicio de descarga inalámbrica se retrasa por un tiempo después de un arranque del sistema para que se active el sistema DECT completo. Esto puede durar varios minutos. Si está activada la función "Descarga inalámbrica", el estado del servicio de descarga inalámbrica se presentará en la página web Estado, junto con algunos datos estadísticos. El estado de descarga individual de cada PP se visualiza en la página web Parte Móvil. Aastra depl-0900/0.4 Página: 84 (112)

85 El terminal está ocupado. Aastra depl-0900/0.4 Página: 85 (112)

86 Los diferentes iconos y textos en la columna Descarga tienen el siguiente significado: Descarga Significado - Imposible descargar el firmware al terminal (p.ej. ningún 610d, 620d o 630d) xx kbytes restantes La PP es localizada para establecer una conexión de descarga. En el caso de establecerse correctamente la conexión, la PP calculará el número de bytes a descargar. Esto puede durar varios segundos. La descarga está en curso y faltan xx kbytes. El firmware de esta PP está al día. La PP se pone en cola de espera para la actualización (pendiente). Advertencia. La descarga está bloqueada por uno de los siguientes motivos: - La PP está ocupada (estado temporal) - La batería está baja - Éste no es el sistema de descarga maestro - La descarga está deshabilitada en el terminal La causa específica se muestra como tooltip. Error La descarga ha fallado por uno de los siguientes motivos: - Error de suma de verificación - Error del sistema de archivos - Error al escribir el firmware en la memoria flash - Versiones diferentes - Error al expandir el contenedor del firmware La causa específica se muestra como tooltip. Info La descarga no es posible porque - El terminal no está localizable - El terminal está apagado La causa específica se muestra como tooltip. Aastra depl-0900/0.4 Página: 86 (112)

87 7 Mantenimiento 7.1 Equipamiento de evaluación de un lugar de instalación Si se ha de planificar una instalación SIP - DECT, es necesaria una distribución suficiente de las RFP que satisfaga los requisitos de sincronización y conectividad fiables a los terminales. El equipo de evaluación le puede ayudar. Contiene: Una RFP de medida con su propia alimentación. Batería para la RFP / el tripode opcional. Dos PP de referencia, con cargadores. Cargadores de batería. Un terminal de medida, que puede mostrar las bases de radio DECT de otros fabricantes (opcional). 7.2 Comprobación de la versión de firmware del terminal Aastra DECT 142 / Aastra 142d Puede ver la información de la versión del Aastra DECT 142 Handset / Aastra 142d en sólo unos pasos. Compruebe la versión de firmware para determinar si se requiere una actualización para solucionar cualquier problema. 1. Pulse la tecla programable Menú 2. Seleccione Sistema (sólo para destacarlo) 3. Pulse OK. 4. Seleccione Número versión 5. Pulse OK. En la pantalla aparecerá la versión de software y hardware del Aastra DECT 142 Handset / Aastra 142d. 7.3 Diagnóstico Modo de evaluación de un lugar de instalación del Aastra DECT 142 / Aastra 142d El Aastra DECT 142 / Aastra 142d puede ponerse en "modo de evaluación de un lugar de instalación" en sólo unos pasos. En este modo, el teléfono mostrará las RFP y la intensidad de campo real de la señal recibida, en dbm. 1) Pulse la tecla programable Menú 2) Introduzca la secuencia de teclas siguiente R***76# 3) Seleccione Site Survey 4) Pulse OK. Para salir de este modo, apague y vuelva a encender el teléfono. En el Aastra DECT 142 Handset / Aastra 142d se mostrará lo siguiente: Aastra depl-0900/0.4 Página: 87 (112)

88 PARK: 1F-10-FF-F0-21 RFP ID: 02* RFPI 10FFF21 02 Frame error FE PP: FP: Field strength RFP ID -dbm RPN Menu Phonebook RFP ID: 02* *The ID of RFP to which the PP is currently associated to. En este ejemplo, la PP está conectada actualmente a la RFP con el número 02. La RFP 01 y 00 están también visibles. El número 10FFF de arriba a la derecha se refiere al PARK (ejemplo 1F-10-F2-21) del sistema SIP - DECT y a la RFP a la que el teléfono está actualmente conectado Modo de prueba autollamada del Aastra DECT 142 / Aastra 142d El Aastra DECT 142 / Aastra 142d puede ponerse en "modo de prueba autollamada", en sólo unos pasos. En este modo, el teléfono llamará a un número especificado de manera cíclica. Puede utilizar esta función para generar tráfico y realizar pruebas. Este modo está también activo si el teléfono está en el cargador. 1) Pulse la tecla programable Menú 2) Introduzca la secuencia de teclas siguiente R***76# 3) Seleccione Auto Call Test 4) Pulse OK. 5) Introduzca el número de teléfono al que se llamará. 6) Pulse OK. 7) Introduzca un número de segundos entre dos llamadas. 8) Pulse OK. 9) Introduzca el número de segundos que una llamada estará activa. 10) Pulse OK. La prueba comenzará automáticamente. Para detenerla, apague y vuelva a encender el teléfono Modo de prueba autorrespuesta del Aastra DECT 142 / Aastra 142d El Aastra DECT 142 / Aastra 142d puede ponerse en "modo de prueba autorrespuesta" en sólo unos pasos. En este modo el teléfono responderá a las llamadas entrantes automáticamente. Puede utilizar esta función junto Aastra depl-0900/0.4 Página: 88 (112)

89 con la de autollamada, para realizar pruebas. Este modo está también activo si el teléfono está en el cargador. 1) Pulse la tecla programable Menú 2) Introduzca la secuencia de teclas siguiente R***76# 3) Seleccione Auto Answer 4) Pulse OK. 5) Introduzca el número de segundos que el teléfono sonará antes de que responda a la llamada. 6) Pulse OK Syslog 7) Introduzca el número de segundos que una llamada estará activa. 8) Pulse OK. La prueba comenzará automáticamente. Para detenerla, apague y vuelva a encender el teléfono. El OpenMobility Manager y las RFP son capaces de transmitir mensajes syslog, de acuerdo con /8/. Esta función se puede configurar, al igual que la dirección IP del host que recopila dichos mensajes. El Syslog se ha de activar a través de DHCP, utilizando las public options 227 y 228. Configurando el servidor y el puerto syslog daemon a través de la interfaz de la web. El configurar el syslog a través del DHCP o del OM Configurator tiene la ventaja de que los syslogs están disponibles en fases más tempranas del arranque de la RFP. Aastra depl-0900/0.4 Página: 89 (112)

90 El nivel de los mensajes del syslog en el estado predeterminado permite al usuario tener un control sobre el estado general del sistema y sobre los principales fallos ssh user shell La ssh shell de cada RFP tiene muchos comandos. La mayoría de los cuales son útiles para hacer diagnósticos y puede servir de ayuda a los expertos para la resolución de problemas. Nota: Algunos comandos pueden ser dañinos para el sistema. El acceso a la ssh de una RFP está abierto si - La RFP está conectada a un OMM y el Acceso Remoto" está habilitado - la RFP no está conectada a un OMM Para habilitar el acceso ssh de una RFP con conexión a un OMM, active la casilla del "Acceso Remoto" en la página web de ajustes del sistema OMM Login El procedimiento es el siguiente: Inicie una sesión ssh con la estación base IP DECT utilizando el nombre de usuario completo e introduzca la contraseña para el acceso completo La pantalla debería ser similar a la siguiente: Welcome to IP RFP OpenMobility SIP Only Version 1.6.x Jun :12:16 Release (BUILD 0) Aastra depl-0900/0.4 Página: 90 (112)

91 last reset cause: hardware reset (Power-on reset) password: > Resumen de comandos Introduzca help para ver un resumen de los comandos exit,quit,bye : cerrar la sesión ommconsole : consola omm ip_rfpconsole : consola rfp flash : muestra la información de la memoria flash link : muestra el estado de la interfaz ethernet ldb : ver / ajustar la configuración local (OmConfigurator) setconsole : duplica los mensajes de la consola noconsole : no duplica los mensajes de la consola dmesg : mensajes del último arranque logread : últimos mensajes su : cambia al usuario root ping : el conocido ping traceroute : el conocido traceroute free : el conocido free ps : el conocido ps top : el conocido top ifconfig : el conocido ifconfig uptime : el conocido uptime reboot : el conocido reboot Aastra depl-0900/0.4 Página: 91 (112)

92 Comandos de consola RFP Si introduce ip_rfpconsole podrá utilizar los siguientes comandos con todas las RFP: heap - muestra estadísitcas del heap buffer help - muestra la tabla de ayuda para comandos lec - ajusta los parámetros del cancelador de ecos media - muestra el estado de los canales de medios mutex - lista todos los MXP mutexes creados queues - lista todas las colas MXP creadas reset - reinicia la aplicación IPRFP rsx - habilita la conexión RSX al BMC por TCP sem - lista todos los semáforos MXP creados spy - set/display spy levels: [ <key #> <level #> ] tasks - lista todas las tareas MXP que se están ejecutando voice - muestra el estado del procesamiento de voz exit - salir de la consola IP-RFP Nota:El comando spy le permite aumentar el nivel de mensajes del syslog. Solamente deber ser utilizado bajo la instrucción de la organización de soporte ya que puede dañar el funcionamiento del sistema Comandos de consola OMM Una vez iniciada la sesión en el OMM RFP si introduce ommconsole podrá utilizar los siguientes comandos relacionados con el OpenMobility Manager (OMM): omm@ > ommconsole Bienvenido a la consola omm, introduzca? para ver un listado de comandos omm# help Comando Descripción ? Muestra la tabla de ayuda de comandos cmi comandos cmi cnf Muestra los parámetros de configuración dsip comandos dsip help Muestra la tabla de ayuda para comandos exit salir de la consola heartbeat configura el mecanismo de heartbeat para las IP-RFPs ipc muestra la comunicación por socket ipl muestra los RFPs configurados ki Monitor KI quit salir de la consola logger mandar una cadena de caracteres al demonio del syslog mon cambiar la funcionalidad del monitor msm muestra los estados dentro del MediaStreamManagement mutex lista todos los MXP mutexes creados Aastra depl-0900/0.4 Página: 92 (112)

93 queues lista todas las colas MXP creadas rspy configuración remota de los niveles de spy en los IP-RFPs rsx muestra los RFPs configurados sem lista todos los semáforos MXP creados spy ajustar / mostrar los niveles spy: [ <key #> <level #> ] standby muestra los OMMs redundantes sync comandos para la sincronización RFP tasks lista todas las tareas MXP que se están ejecutando tasks lista todas las tareas MXP que se están ejecutando tzone comandos tzone uptime muestra el tiempo que el sistema lleva en funcionamiento ver información de versión wlan muestra los estados del Gestor de LAN inalámbrica omm# Nota:El comando spy le permite aumentar el nivel de mensajes del syslog, especialmente para subsistemas del OMM. Solamente deber ser utilizado bajo la instrucción de la organización de soporte ya que puede dañar el funcionamiento del sistema Captura de ficheros de volcado de memoria (core files) En caso de que se produzca un error fatal en el OMM y el software deje de funcionar, el OMM creará un volcado de memoria. Si envía a soporte los ficheros de volcado de memoria, estos les servirán de ayuda para la resolución de problemas. El OMM puede grabar los ficheros de volcado de memoria generados por el servidor TFTP de su red local. Para habilitar la generación de ficheros de volcado de memoria, introduzca en la línea de comandos del OMM: local_db core=yes local_db core_srv=server-ip dirección IP del servidor TFTP local_db core_path=ruta del fichero en el servidor TFTP (debe tener permisos de escritura) Si local_db_core_srv ylocal_db_core_path no están configurados, el OMM intentará grabar los ficheros de volcado de memoria en el servidor TFTP y en la ruta de donde se descargó la aplicación OMM/RFP. Después de reiniciar el OMM, los ficheros de volcado de memoria se transfieren de manera automática al servidor TFTP. NOTA:El servidor TFTP debe permitir la escritura de ficheros nuevos, lo cual no suele ser el caso de manera predeterminada Para deshabilitar la captura de ficheros de volcado de memoria, introduzca en la línea de comandos: local_db core= Aastra depl-0900/0.4 Página: 93 (112)

94 7.3.7 Monitor DECT El Monitor DECT facilita una mejor detección de errores en el sistema IP DECT. El Monitor DECT en un programa autónomo para MS Windows. Permite obtener una visión global en tiempo real del estado de la estación base IP DECT activa y de los teléfonos en el sistema IP DECT. Las funciones del Monitor DECT son las siguientes: Ver la configuración DECT de un sistema IP DECT. Se puede guardar la configuración en un fichero ASCII. Mostrar las transacciones DECT entre los teléfonos y la estación base IP DECT en formato tabular, resaltando las situaciones de handover. Pantalla de tiempo real. La visualización de otros eventos relativos al estado o a las acciones de las estaciones base IP DECT y teléfonos en el sistema IP DECT. Los eventos se pueden grabar también en un fichero de captura. Visualización de la relación de sincronización entre las RFPs. Monitorización de sistemas de hasta 256 estaciones base IP DECT y 512 PPs Lectura y visualización de datos estadísticos IP DECT RFP, de una sola IP DECT RFP o de todas las IP DECT RFPs. Visualización de datos centralizados DECT del sistema IP DECT. El programa del Monitor DECT cuando la casilla del Monitor DECT de la configuración de sistema OMM esté habilitada. NOTA:Por motivos de seguridad, el valor de la casilla de activación del monitor DECT no se guarda de manera permanente en la memoria flash interna del OMM/RFP. Después de un reinicio la casilla de activación del monitor DECT queda siempre deshabilitada. El programa de monitorización DECT se utiliza junto con un sistema IP DECT. Aastra depl-0900/0.4 Página: 94 (112)

95 Cuando se arranca el programa, el usuario debe introducir la dirección IP del IP DECT RFP o del servidor donde se esté ejecutando le software del OpenMobility Manager (OMM). Puede haber varias razones para que no se pueda crear la conexión con éxito: El monitor DECT no está habilitado en el OMM. Utilice el servicio web para activar el monitor DECT. La dirección IP no es correcta. Tiene que ser la dirección del RFP donde se está ejecutando el OMM No se soporta un enlace al RFP. El programa muestra la dirección IP que se utilizó la última vez. Cuando se arranca el programa, se crea de manera automática una conexión con el OMM y la ventana del programa muestra todas las ventanas secundarias y tablas del usuario. Una vez que se han creado todas las conexiones, los datos DECT del sistema se leen de manera automática y se introducen en las tablas RFP- Table" y "PP-Table". Este proceso se llama Config Request. A continuación, las opciones definidas de traceo (Máscara de Eventos) se envían al OMM. Las opciones que se envían al OMM son siempre las mismas que se utilizaron la última vez que se ejecutó el programa. Si la opción de traceo Establecer/liberar transacción está habilitada, el OMM enviará todas las transacciones existentes. Una vez acabado, el sistema OMM envía la información de traceo deseada. El usuario puede comunicarse con el programa de manera interactiva (ver Aastra depl-0900/0.4 Página: 95 (112)

96 más abajo) o puede simplemente activar un fichero de captura en el que se grabarán todos los datos. Al finalizar la inicialización, el usuario puede llevar a cabo las siguientes modificaciones: Los ajustes de traceo pueden ser modificados a través del menú Opciones-Máscara de Eventos El envío al OMM se realiza una vez que los ajustes son confirmados con <OK>. Se puede enviar de nuevo un Config Request al OMM. Se puede activar un fichero de captura. A través de distintos diálogos, los datos de configuración de los teléfonos, RFPs y módulos de control se pueden ver y grabar en ficheros ASCII. La siguiente información se muestra de manera dinámica en las tablas: Transacciones entre los teléfonos y el sistema DECT. Estas se muestran en ambas tablas. Transacciones simples se muestran en negro sobre fondo blanco; durante el handover, ambas transacciones involucradas se muestran en blanco sobre fondo rojo. Los eventos de Registro de Ubicación y Desconexión se muestran en las tablas durante aproximadamente 1-2 segundos desde que se producen (fondo en verde claro), si es posible. No se muestra nada en la tabla FP cuando no queda ninguna columna libre. Cuando el evento ya ha sido mostrado, se puede sobrescribir en cualquier momento. Los eventos no se muestran si se producen durante una transacción en curso. Independientemente de si los eventos se muestran en las tablas, siempre se introducen en la ventana FP/PP-events y en el fichero de captura (siempre que este se encuentre abierto). El siguiente esquema de colores se utiliza para mostrar los RFPs en la tabla RFP: RFP azul grisáceo La estación base IP DECT está desactivada (no está conectada o da fallo) RFP negro La estación base IP DECT está activa Los datos de una RFP se muestran en un cuadro de dialogo cuando se hace click en el campo RFP correspondiente en la tabla RFP. Desde este cuadro de dialogo podemos recuperar los datos estadísticos de la RFP. El siguiente esquema de colores se utiliza para mostrar los teléfonos en la tabla PP: PP negro El terminal está registrado Se asume que hay acceso al terminal. PP azul Probablemente no tenemos acceso al terminal Se ha recibido una orden de desconexión, o cuando se ha realizado un intento de llamar al teléfono y el terminal no contesta. Aastra depl-0900/0.4 Página: 96 (112)

97 PP azul grisáceo El terminal no está registrado. Los datos de un terminal se muestran en un cuadro de dialogo cuando se hace click en el campo teléfono correspondiente en la tabla FP. La ventana hija Sync Info contiene todas las estaciones base IP DECT y muestra su estado de sincronización y relación entre ellas. Seleccionando las estaciones base IP DECT con el botón derecho del ratón, el usuario puede cambiar la visibilidad y puede incluso forzar la resincronización de una estación base IP DECT. Se pueden seleccionar una serie de ventanas hijas opcionales. Más abajo se puede consultar un listado con todas ellas y más información acerca de los sistemas IP DECT. Se trata principalmente de estadísticas y para uso interno exclusivamente. Aastra depl-0900/0.4 Página: 97 (112)