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

Transcripción

1 Instalación, Administración y Mantenimiento de la solución DECToverIP using SIP Versión 1.6 Id. del documento : depl-0794 Versión: 2.0 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 Inicio del OpenMobility Manager Arranque Cliente DHCP Solicitud DHCP Oferta DHCP Reintentos Cliente TFTP Aplicación 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. Selección del servidor DHCP adecuado Estado del LED de la RFP Gráfico de estado de las fases de inicio CONFIGURACIÓN LOCAL ESTÁTICA DE UNA RFP CONFIGURACIÓN DEL OPENMOBILITY MANAGER Procedimiento de Inicio de Sesión en el Servicio Sistema Ajustes del sistema Reinicio del OMM Codificación Campo normativo SIP Cuenta de usuario Zonas horarias Copia de seguridad 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 Registro con IPEI configurado Registro libre Búsqueda en la lista de PP Aastra depl-0794/2.0 Página: 2 (95)

3 3.3.5 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 SEGURIDAD EL CONCEPTO DE SEGURIDAD TIPOS DE CUENTA CAMBIO DE LOS DATOS DE CUENTA OBSTÁCULOS POTENCIALES REDUNDANCIA DE OMM CÓMO 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 MANTENIMIENTO EQUIPAMIENTO DE EVALUACIÓN DE UN LUGAR DE INSTALACIÓN COMPROBACIÓN DE LA VERSIÓN DE FIRMWARE DEL AASTRA DECT 142 HANDSET DIAGNÓSTICO Modo de evaluación de un lugar de instalación del Aastra DECT Modo de prueba autollamada del Aastra DECT Modo de prueba autorespuesta del Aastra DECT 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 INFORMACIÓN DE REGULACIÓN 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 CONFIGURACIÓN PREVIA Archivo de configuración de los PP (base de datos del OMM) Instrucciones soportadas Campos de la sección de datos Ejemplo Archivo de configuración de la RFP / central (base de datos del OMM) Instrucciones soportadas Campos de la sección de datos Ejemplo Archivo de configuración de la RFP / local (OM Configurator) Instrucciones soportadas Campos de la sección de datos Ejemplo PROTOCOLOS Y PUERTOS...94 Aastra depl-0794/2.0 Página: 3 (95)

4 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-0794/2.0 Página: 4 (95)

5 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-0794/2.0 Página: 5 (95)

6 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 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 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-0794/2.0 Página: 6 (95)

7 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-0794/2.0 Página: 7 (95)

8 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-0794/2.0 Página: 8 (95)

9 2.2 Acerca de los Puntos de Acceso (RFP) Aastra DeTeWe proporciona 3 tipos de Puntos de Acceso: - RFP 32 Punto de Acceso DECT, modelo para interiores - RFP 34 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-0794/2.0 Página: 9 (95)

10 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-0794/2.0 Página: 10 (95)

11 RFP 32 NA / RFP L32 IP Unused LED LED green (Application) LED orange (Application) LED red (Booter) Ethernet jack Power supply in line with Power ov er Ethernet standard IEEE 802.3af Power jack (120 V/230 V AC adapter) RFP L42 WLAN LED for WLAN LED 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-0794/2.0 Página: 11 (95)

12 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 (RT) / Protocolo de Control en Tiempo Real (RTCP) entre el teléfono SIP y la puerta de medios, y una conexión RTP / RTCP entre la puerta de medios y la RFP. En el esquema siguiente se ilustra esta situación. Aastra depl-0794/2.0 Página: 12 (95)

13 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í. También es posible dirigir el flujo de medios para conectar directamente el teléfono IP y la RFP, como se muestra en las figuras siguientes. Aastra depl-0794/2.0 Página: 13 (95)

14 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-0794/2.0 Página: 14 (95)

15 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-0794/2.0 Página: 15 (95)

16 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 franjes 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-0794/2.0 Página: 16 (95)

17 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 o terminal móvil) es terminología estándar de DECT y, dentro del contexto de la solución DECToverIP using SIP, se puede utilizar indistintamente a Aastra DECT 142 Handset y Aastra 142d. Tenga en cuenta las diferencias normativas entre Norteamérica y todas las demás zonas del mundo. Estas diferencias llevan a diversas variantes de RFP 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 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) Además del Aastra DECT 142 Handset / Aastra 142d, existen teléfonos estándar DECT GAP de otros fabricantes que funcionan 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-0794/2.0 Página: 17 (95)

18 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 Los siguientes servicios se deberían proporcionar: 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 Comunicar a través de un servidor DHCP en el momento de inicio, 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-0794/2.0 Página: 18 (95)

19 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 inicio, cada RFP intenta determinar su propia dirección IP y otras configuraciones 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 inicio Inicio 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: OpenMobility obligatorio Solicitud DHCP Identificador de clase del fabricante (code 60) El cliente DHCP envía el identificador de clase del fabricante OpenMobility Aastra depl-0794/2.0 Página: 19 (95)

20 Lista de parámetros solicitados (código 55) 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-0794/2.0 Página: 20 (95)

21 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 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. Aastra depl-0794/2.0 Página: 21 (95)

22 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 Significado Longitud Obligatoriedad Específica del Fabricante option 10 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 redundancia o secundario. Esta opción debe seleccionarse si se desea utilizar la función de Redundancia de OMM (ver el capítulo 5). 4 No 2 No 2 No x No 4 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. Aastra depl-0794/2.0 Página: 22 (95)

23 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. 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. Aastra depl-0794/2.0 Página: 23 (95)

24 3.1.5 Estado del LED de la RFP Las imágenes siguientes muestran el estado del LED de una RFP según las diferentes fases durante el inicio. La RFP L32 IP tiene tres LED distintos (uno rojo, uno naranja y otro verde) para mostrar los diferentes estados durante el inicio. 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 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 Aastra depl-0794/2.0 Página: 24 (95)

25 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 Estado del LED WLAN Rojo continuo apagado apagado WLAN desactivada por velocidad de 10 Verde intermitente 1 Mbps 1 Hz WLAN activa y funcionando Verde RFP L42 WLAN LED for WLAN LED green (Application) LED orange (Application) LED red (Booter) Ethernet jack Power supply in line with Power over Ethernet standard IEEE 802.3af Power jack (120 V/230 V AC adapter) 1 La RFP L42 WLAN debe estar conectada a un Ethernet 100BaseT para que el servicio WLAN funcione. Aastra depl-0794/2.0 Página: 25 (95)

26 3.1.6 Gráfico de estado de las fases de inicio 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-0794/2.0 Página: 26 (95)

27 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-0794/2.0 Página: 27 (95)

28 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: configuración obligatorio Dirección IP obligatorio Dirección IP de la RFP Máscara de red obligatorio Máscara de subred Dirección del Servidor TFTP Nombre de Archivo TFTP obligatorio obligatorio El parámetro define si se deben utilizar los valores de configuración local al arrancar o no. Dirección IP del servidor TFTP El fichero de arranque debe ser leído del servidor TFTP durante el arranque. Dirección IP del OMM 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 Aastra depl-0794/2.0 Página: 28 (95)

29 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.3 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-0794/2.0 Página: 29 (95)

30 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-0794/2.0 Página: 30 (95)

31 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-0794/2.0 Página: 31 (95)

32 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-0794/2.0 Página: 32 (95)

33 La primera vez que el usuario entra en una nueva versión de OpenMobility, el usuario tiene que aceptar la licencia End User Licence Agreement (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-0794/2.0 Página: 33 (95)

34 Tras el inicio de sesión, hay disponibles las siguientes opciones: 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-0794/2.0 Página: 34 (95)

35 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 Aastra depl-0794/2.0 Página: 35 (95)

36 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 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 Aastra depl-0794/2.0 Página: 36 (95)

37 Please, enter the PARK key as labelled on the OpenMobility CD 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. Aastra depl-0794/2.0 Página: 37 (95)

38 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 SIP 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). 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 Aastra depl-0794/2.0 Página: 38 (95)