Diseño e implementación de VoIP en Océ España

i Agradecimientos En primer lugar quiero agradecer a Miquel Soriano la generosidad de haberse ofrecido como ponente de este PFC. Igualmente agradezco a Javier Ozón su paciencia. Sin su ayuda no hubiera finalizado este proyecto. En segundo lugar quiero agradecer a mi familia, en especial a Carol, el apoyo y paciencia que han tenido. Después de tantos años, parece que al final acabaré el proyecto. Por último a mis compañeros en Océ España y en especial a Cristina Lucea, mi jefa durante la realización del proyecto. Gracias por confiar en mí. ii • Índice 1. Introducción..........................................................................................................1 1.1. Red original.......................................................................................................2 1.2. Red modificada .................................................................................................5 2. Cálculos de Tráfico ...............................................................................................9 2.1. Tráfico de voz hacia la PSTN ............................................................................ 9 2.1.1. Tráfico de la sede central (Barcelona)................................................................ 9 2.1.2. Tráfico de la sucursal de Madrid........................................................................9 2.1.3. Tráfico de la sucursal de Valencia ................................................................... 10 2.1.4. Tráfico de la sucursal de Sevilla ...................................................................... 11 2.1.5. Tráfico de la sucursal de Bilbao....................................................................... 12 2.2. Tráfico WAN .................................................................................................. 12 3. Introducción al servicio VoIP.............................................................................. 15 3.1. Protocolos VoIP .............................................................................................. 16 3.1.1. H.323 .............................................................................................................. 16 3.1.2. SIP .................................................................................................................. 17 3.1.3. MGCP............................................................................................................. 17 3.1.4. SCCP .............................................................................................................. 18 3.1.5. RTP/RTCP...................................................................................................... 18 3.2. Componentes de la Telefonía IP ...................................................................... 18 3.2.1. Infraestructura de red....................................................................................... 19 3.2.2. Proceso de llamadas ........................................................................................ 19 3.2.3. Call Manager (CCM)....................................................................................... 19 3.2.4. Dispositivos IP ................................................................................................ 20 3.2.5. Control de admisión de llamadas (CAC).......................................................... 20 3.2.6. Calidad de la VoIP .......................................................................................... 21 3.2.7. FAX ................................................................................................................ 22 3.3. Arquitectura de la telefonía IP ......................................................................... 22 3.4. Flujo de la llamada VoIP................................................................................. 23 3.4.1. Llamada entre dos teléfonos IP........................................................................ 23 3.4.2. Llamadas Off-Net............................................................................................ 25 4. Infraestructura de Red ......................................................................................... 27 4.1. Electrónica Central Barcelona ......................................................................... 27 4.2. Electrónica Sucursal de Madrid ....................................................................... 27 4.3. Diagrama de Red............................................................................................. 29 4.4. Teléfonos IP utilizados.................................................................................... 29 4.5. Infraestructura LAN y WAN ........................................................................... 30 4.5.1. Switch 3550-3750 ........................................................................................... 30 4.5.2. Router 3745..................................................................................................... 31 4.5.3. Configuración RIP........................................................................................... 35 5. Implementación de VoIP..................................................................................... 39 5.1. Plan de marcación y configuración de teléfonos IP .......................................... 39 5.2. Configuración del servicio de telefonía en el CCM de Barcelona..................... 40 5.3. Iguales de conexión (Dial peer) ....................................................................... 54 5.3.1. Circuitos de llamadas salientes ........................................................................ 55 5.3.2. Circuitos de llamadas entrantes........................................................................ 57 5.3.3. Otras opciones de Dial peers ........................................................................... 57 5.3.4. Dial peers en las sucursales para telefonía fija ................................................. 60 5.3.5. Dial peers en las sucursales para telefonía móvil ............................................. 63 iii 5.4. Configuración FAX. Cisco ATA 186............................................................... 65 5.5. Configuración de enlaces a la PSTN................................................................ 68 5.5.1. Oficina central de Barcelona y Madrid ............................................................ 68 5.5.2. Sucursales Valencia, Sevilla y Bilbao.............................................................. 69 5.6. Cisco IP 7960 con modulo de extensión 7914 (Centralita)............................... 70 6. Calidad de servicio en redes con servicio VoIP ................................................... 73 6.1. Encolamiento Class-Based Weighted Fair ....................................................... 73 6.2. LAN QoS en la central de Barcelona ............................................................... 74 6.3. Características del tráfico de voz y datos ......................................................... 75 6.4. QoS en terminales IP....................................................................................... 75 6.5. LAN QoS en Sitios Remotos........................................................................... 76 6.6. WAN QoS en Sitios Remotos.......................................................................... 79 6.7. Mapeos DSCP a CoS....................................................................................... 80 6.8. Mapeos Cos-DSCP en Routers Remotos.......................................................... 81 6.9. Configuración de las colas en la interfaz WAN................................................ 82 6.10. Diseño de QoS en los routers centrales ............................................................ 83 6.11. Configuración Class Map ................................................................................ 84 6.12. Configuración de Policy Map .......................................................................... 85 6.13. Resumen QoS en las comunicaciones.............................................................. 86 7. Coste del proyecto............................................................................................... 87 7.1. Planificación del proyecto ............................................................................... 87 7.2. Business Case.................................................................................................. 89 8. Conclusiones y líneas futuras. ............................................................................. 95 Bibliografía ……………………………………………………………………….97 1 1. Introducción La finalidad del presente proyecto es documentar la solución adoptada para telefonía fija por la empresa Océ España S.A. Este proyecto es el resultado de un año de trabajo y su objetivo se centra en satisfacer las nuevas demandas de servicios e inversión tecnológica. El proyecto se basa en el cambio del servicio de la telefonía tradicional al servicio de telefonía de voz sobre IP (VoIP). Océ España S.A forma parte del Grupo Océ, líder mundial en productos y servicios de alta calidad para la impresión y gestión de documentos en entornos profesionales. El Grupo Océ se compone de diferentes Operation Companies (OPCO) que a su vez se dividen en diferentes sucursales. La OPCO Océ España S.A está compuesta por la sede central en Barcelona y las sucursales de Madrid, Sevilla, Valencia y Bilbao. El servicio de telefonía previo de Océ España S.A. se desarrollaba a través de la telefonía tradicional PSTN, tanto para llamadas internas como para llamadas externas. La sede central situada en Barcelona se comunicaba telefónicamente con las sucursales mediante la red PSTN, con el coste que conlleva este tipo de llamadas. La implantación del servicio VoIP y la configuración del Less Cost Routing (LCR) permiten la realización de llamadas a través de la red interna de Océ España, reduciendo por tanto el coste de las llamadas, con un gasto fijo mucho menor. Este tipo de llamadas sobre IP conlleva una serie de mejoras que se detallan en la presente memoria. El dimensionado de los enlaces entre sucursales se calculó con el método del tráfico de las llamadas en la hora de máxima carga y con las tablas de Erlang y el porcentaje máximo permitido de bloqueo de llamada. Este cálculo se realizó tanto para las llamadas externas como para las llamadas internas (capítulo 2). Para el enlace entre todas las sucursales y la sede principal, se ha optado por una red MPLS con servicio VPN y con un ancho de banda garantizado tanto para telefonía como para datos. Este tipo de red presenta una serie de beneficios importantes como la seguridad y la velocidad de tráfico, puesto que como se verá más adelante el encaminamiento de los paquetes se realiza mediante un intercambio de etiquetas. La solución adoptada ha sido una VoIP con productos Cisco y con servicio MacroLan de Telefónica (MPLS). De este modo, se han integrado la voz y los datos en una única red que, como veremos, divide los paquetes en distintas categorías y permite priorizar, por tanto, el tráfico de voz sobre el de datos con el objeto de garantizar una determinada calidad de servicio (llamada también QoS o Quality of Service). Para la red interna de la empresa se han empleado los switches de interconexión Cisco Catalyst 3750 y 3550, que sirven además de fuente de alimentación para los teléfonos, con la subsiguiente simplificación de la infraestructura. Como router de interconexión entre las sucursales se ha optado por el Cisco 3745. El capítulo cuarto detalla con más profundidad el tipo de conexiones empleado para la comunicación de la telefonía IP y del tráfico de datos. Cisco Call Manager (CCM) es el software de gestión de Cisco para el control, encaminamiento y seguimiento de llamadas, que da servicio a los teléfonos IP 7940G, destinados a los usuarios, y tambén a los 7960G con extensión 7914, destinados a las centralitas. El protocolo de comunicación entre el Call Manager y los terminales es el 2 SCCP (Skinny Call Control Protocol). El Call Manager actúa a su vez como un Proxy de señalización para los eventos generados por otros protocolos (H.323, SIP, ISDN, MGCP, etc.) [1]. El establecimiento y finalización de las llamadas se realiza a través del CCM que gestiona la señalización. En cambio la conversación se mantiene directamente a través de los terminales VoIP. Además del CCM, otros elementos integrados en AVVID (arquitectura para voz, video y datos integrados) utilizados en este proyecto son: • Terminales de voz IP (Cisco IP Phone-SCCP), concretamente los modelos 7940G y 7960G, equivalentes a los clientes H.323. • Tarjetas PRI y BRI para la conexión con la red PSTN, incluidas en el gateway de voz (router 3745). • Switches 3750, 3755 con función power-in-line (alimentación de dispositivos via Ethernet). • Router 3745, que hace la función de gateway de voz. Para trasladar un servicio de telefonía tradicional a un servicio de VoIP se debe generar un plan de marcación global. Los principales puntos de un plan de marcación son: • Direccionamiento final. Todos los terminales (teléfonos IP, fax, módems, teléfonos analógicos, etc.) y todas las aplicaciones (buzones de voz, contestadores, conferencias) deben tener asignado por lo menos un número de directorio (DNs). • Selección de rutas. Dependiendo del origen, destino y del elemento de la llamada, pueden seleccionarse diferentes rutas. Además, una ruta secundaria puede ser usada cuando una ruta primaria no está disponible (por ejemplo, una llamada puede ser transparentemente encaminada sobre PSTN durante un fallo de la red IP WAN). • Preferencia de llamadas. En algunos casos, es necesario manipular las cadenas de marcación antes de ser encaminadas para el proceso de las llamadas. Por ejemplo, cuando se encamina sobre la PSTN una marcación original a través de un código de acceso limpio, o cuando se tiene que expandir o abreviar un código (como el 0 para el operador) en una extensión. 1.1. Red original Océ España está formada por una central situada en Barcelona con 220 personas, y de cuatro sucursales ubicadas en Madrid (150 personas), Valencia (10 personas), Sevilla (10 personas) y Bilbao (10 personas) Las llamadas externas se han cursado hasta ahora desde cada una de las sucursales o central directamente hacia la PSTN. De este modo, el coste de la llamada dependía de 3 un origen fijo (sucursal o central) y del destino (móvil, local, interprovincial, nacional, internacional). Como veremos, VoIP permite que una llamada generada en Barcelona con destino Madrid utilice el enlace a la PSTN de Madrid, lo que se traduce en un coste de llamada local para una llamada que en el sistema tradicional sería nacional. Las llamadas internas se realizaban de igual modo, es decir, a través de los enlaces a la PSTN de las sucursales. VoIP permite encaminar las llamadas entre sucursales sin necesidad de utilizar la PSTN y, por tanto, sin generar un coste directo por consumo. La infraestructura de comunicaciones de cada sucursal consistía en un cableado específico para voz (RJ11) y un cableado específico para datos (RJ45). La conexión a la PSTN se realizaba a través de Liceas en las sucursales pequeñas (Valencia, Sevilla, Bilbao) y de primarios en Madrid y Barcelona según la siguiente tabla: Sucursal Llamadas de fijo a fijo Llamadas de fijo a móvil Barcelona 3E1 (30B+D) x3 E1 (30B+D) Madrid 2E1 (30B+D) x2 E1 (30B+D) Valencia 5Bri (2B+D)x5 Sevilla 4Bri (2B+D)x4 Bilbao 6Bri (2B+D)x6 Tabla 1.1. Enlaces de telefonía. Los enlaces estaban claramente sobredimensionados ya que el volumen de llamadas generado por Barcelona, aun siendo muy superior al de una sucursal más pequeña como por ejemplo Bilbao, nunca llegaba a superar el 40% de canales (llamadas concurrentes). Para el tráfico de telefonía entre sucursales no resultaba necesaria la red WAN que conecta las oficinas con la sede central, dado que las llamadas internas se realizaban a través de la red PSTN. La red WAN se utilizaba para el tráfico de datos, siendo esta red una Frame Relay de 2.5 Mbps para la sucursal de Barcelona y las detalladas en la tabla 1.2 para el resto de las sucursales. Sucursal Ancho de Banda Cir Barcelona 2.5 Mbps 2 Mbps Madrid 1.5 Mbps 1 Mbps Valencia 256 Kbps 256 Kbps Sevilla 256 Kbps 256 Kbps Bilbao 256 Kbps 256 Kbps Tabla 1.2. Ancho de banda para el tráfico de datos. 4 FRAME RELAY SUCURSALES SEVILLA BILBAO VALENCIA MADRID Shiva Lan Rover E56 E1 (2B+D) BARCELONA Portatil Workstation Cisco 1721 S45 Cisco 3640 Cisco 2501 Cisco 2501 Cisco 2501 Cisco 3620 PSTN 5 LINEAS RTB Teléfono Teléfono Teléfono Teléfono Teléfono PSTN 6 LINEAS RTB PSTN 4 LINEAS RTB PSTN 2+1 E1 PSTN 3+1 E1 2,5 Mbps 1,5 Mbps 256 Kbps 256 Kbps 256 Kbps Figura 1.1. Infraestructura de red anterior a la implantación de VoIP. Como se puede observar en la figura anterior, la situación descrita llevaba implícita una serie de costes asociados a la tecnología utilizada. Así, por ejemplo, las llamadas a móviles cursadas desde Sevilla, Valencia o Bilbao se efectuaban con la tarifa de fijo a móvil, mucho más elevada que la de móvil a móvil. Paralelamente se disponía de dos E1 para telefonía móvil infrautilizados puesto que sólo podían cursarse las llamadas desde Madrid o Barcelona. Por otro lado, los factores económicos que determinaron la necesidad de un cambio tecnológico fueron principalmente el elevado coste de las líneas de comunicaciones (Frame Relay), el aumento de llamadas a móviles con el agravante del coste de fijo a móvil y la necesidad de una inversión elevada para actualizar las PBX si se decidía mantener el mismo sistema. Otro aspecto importante era la dificultad de implantar restricciones en las llamadas a ciertos números, establecer audio-conferencias, y de realizar en general todas las tareas administrativas asociadas a telefonía como movilidad de usuarios, altas, bajas, etc. Llegados a este punto, se presentó al bloque directivo de Océ España una propuesta para implantar una solución de VoIP basada en equipos de Cisco y tramitada a través de Getronics S.A, uno de sus principales socios en España. 5 1.2. Red modificada En el presente proyecto se ha implantado el servicio de telefonía IP tanto en la sede central de Océ España como en el resto de las sucursales, con el fin de mejorar su infraestructura y servicios. Los teléfonos adquiridos, los Cisco IP Phone 7940, se ocupan de la conexión tanto telefónica como de la red de datos, y conectan a través de un segundo puerto el PC al switch 3550, en el cual se configuran dos VLAN, una de datos y otra de voz. El propio teléfono, como se explica más adelante, se ocupa de clasificar con prioridad los paquetes de voz, la señalización y los paquetes de datos. Los switches 3550 están conectados a dos switches Core 3 de Cisco 3750, que comunican con el router que hace de gateway de voz, un Cisco 3745. Este router es el encargado de direccionar todas las llamadas externas hacia la red PSTN a través de sus tarjetas PRI para la sede de Barcelona y Madrid, y de tarjetas BRI para las sucursales de Valencia, Sevilla y Bilbao. La red, como en el apartado anterior, presenta una estructura centralizada que concentra los servicios en la sede central de Barcelona. En esta sede se encuentran los administradores de redes, encargados de la atención de los usuarios. En la figura 1.2 se detalla la infraestructura modificada, con el servicio de VoIP. 1 2 ABC 3 DEF 4 5 JKL 6 MNOGHI 7 8 TUV 9 WXYZPQRS * 0 OPER # 7940 CISCO IP PHONE i messagesdi rectories settingsservices 1 2ABC 3DEF 4 5 JKL 6 MNOGHI 7 8 TUV 9 WXYZPQRS * 0 OPER # 7940CISCO IP PHONE i messagesdi rectories settingsservices 1 2 ABC 3 DEF 4 5 JKL 6 MNOGHI 7 8 TUV 9 WXYZPQRS *0 OPER # 7940 CISCO IP PHONE i messagesd irectories settingsse rvices 1 2 ABC 3 DEF 4 5 JKL 6 MNOGHI 7 8 TUV 9 WXYZPQRS * 0 OPER # 7940 CISCO IP PHONE i messages d irectories settingsservices 1 2 ABC 3 DEF 4 5 JKL 6 MNOGHI 7 8 TUV 9 WXYZPQRS * 0 OPER # 7940 CISCO IP PHONE i messages d irectories settingsservices 1 2 ABC 3 DEF 4 5 JKL 6 MNOGHI 7 8 TUV 9 WXYZPQRS * 0 OPER # 7940 CISCO IP PHONE i messagesd irectories settingsservices 1 2ABC 3DEF 4 5 JKL 6 MNOGHI 7 8 TUV 9 WXYZPQRS * 0OPER # 7940CISCO IP PHONE i messages d irectories settingsservices 1 2 ABC 3 DEF 4 5 JKL 6 MNOGHI 7 8 TUV 9 WXYZP QRS * 0 OPER # 7940 CISCO IP PHONE i messagesd irectories settingsservices 1 2 ABC 3 DEF 4 5 JKL 6 MNOGHI 7 8 TUV 9 WXYZPQRS * 0 OPER # 7940 CISCO IP PHONE i messages d irectories settingsservices Sucursal Ancho de Banda Barcelona 5 Mbps Madrid 3 Mbps Valencia 1 Mbps Sevilla 1 Mbps Bilbao 1 Mbps Figura 1.2. Infraestructura de red actual con VoIP 6 Los beneficios del servicio VoIP, mencionados con mayor detalle en capítulos posteriores, son los siguientes: • Las llamadas entre sucursales a través de la red WAN no se encaminan hacia la PSTN. A esto se le denomina Toll Bypass. • Los routers incorporan los gateways de voz mediante tarjetas PRI y BRI. • Se descarga del tráfico de voz y del tráfico de fax a la PSTN. • Acceso universal de servicios de mail de voz y mail de fax. • Unificación de enlaces de voz y datos, todo se realiza con la misma red. Además de todos estos beneficios, se deben mencionar los servicios y aplicaciones que incorpora la telefonía IP [2]: • Cisco Personal Assistant (PA): es una aplicación de telefonía basada en IP que entrega personalizaciones, es fácil de usar y mejora las comunicaciones, racionalizando las llamadas con reglas. • Cisco Integrates Contact Distribution (ICD): provee la distribución de llamadas de voz automáticas dentro de una empresa. • Cisco IP PPS: es una aplicación personal de los Cisco IP Phones que permite a los usuarios comprobar el email, email de voz, e información personal de la llamada, usando el display. • Cisco Unity de mensajería: es un componente clave en la solución Cisco IP Telephony (CIPT), que provee de funcionalidad Vitual Mailbox (VM). • Cisco IP Contact Center (IPCC): combina CIPT y la solución de Cisco para Contact Center. El IPCC tiene un juego integrado de productos que habilita agentes usando Cisco IP Phones para recibir llamadas de tipo TDM y VoIP. El IPCC es usado para la integración de la plataforma del centro de llamadas y de redes. Esto provee una ruta de comunicación al cliente basado en IP. • IP/TV e IP/: productos de video-conferencia que mejoran la colaboración y el aprendizaje a distancia. • IVR Interactive Voice Response: productos de reconocimiento de voz y encaminamiento lógico. • Cisco WebAttendant: reemplaza la tradicional consola manual PBX; WebAttendant provee una flexibilidad y escalabilidad derivada de IP. • Cisco IP Communicator: provee transportabilidad en las comunicaciones, lo que incrementa la eficiencia personal e incentiva la colaboración. 13 En la tabla 2.2 se especifican las características del enlace WAN para el tráfico de voz IP. Enlace WAN Router Velocidad ATM % u tilización concurrente CIR Madrid-Barcelona 3745 1Mbps 60 % 1Mbps Valencia-Barcelona 3745 256 kps 50 % 256 Kbps Sevilla-Barcelona 3745 256 kps 50 % 256 Kbps Bilbao-Barcelona 3745 256kps 50 % 256 Kbps Barcelona 3745 2Mbs 50 % 2 Mbps Tabla 2.2. Características de los enlaces WAN. También es necesario determinar la sobrecarga de nivel 2 que se provee para el ancho de banda del tráfico de VoIP. Sólo se especifica para la conexión Ethernet y para la ATM [3]. Esto se puede observar en la tabla 2.3. Codec Sampling Rate Ethernet 14 bytes of header ATM 53-Byte Cells with a 48-Byte Payload G.711 at 50.0 pps /20 ms sampling rate 85.6 Kbps 106 Kbps G.729 at 50.0 pps /20 ms sampling rate 29.6 Kbps 43.4 Kbps Tabla 2.3. Consumo de Ancho de banda (con cabecera de la capa 2) Los paquetes de voz son transportados por RTP, UDP e IP. La cabecera IP son 20 bytes, la cabecera UDP son 8 bytes, y la cabecera RTP son 12 bytes. Esto hace un total de 40 bytes. Después de los 40 bytes de la cabecera de información, dos frames de 10 bytes (para el códec G.729a) de carga útil son transportados, en total otros 20 bytes de carga útil. A simple vista se observa que la cabecera duplica la carga útil, por lo que existe un mecanismo de compresión de la cabecera RTP llamado compressed RTP (cRTP). Esto reduce la cabecera a 2 o 4 bytes y, en consecuencia, el ancho de banda por llamada, como se muestra en la tabla 2.4 [3]. Codec ATM 53 byte Cell with a 48 Byte Payload G.711 at 50.0 pps 85 Kbps G.729 at 50.0 pps 21.2 Kbps Tabla 2.4. Consumo de ancho de banda con cRTP. 14 Una vez se ha determinado el códec seleccionado (G.729a) y el tipo de enlace WAN (ATM), se calcula el ancho de banda que se ha de contratar para las llamadas entre sucursales. Esto se detalla en la tabla 2.5. Criterio Madrid Valencia Sevilla Bilbao Número de teléfonos 100 10 10 10 Ancho de banda del enlace de voz 1Mbps 256 Kbps 256 Kbps 256 Kbps Número de llamadas de voz simultáneas 35 5 5 5 Número de llamadas de faxes 1 1 1 1 Códec usado para llamadas de voz G.729 G.729 G.729 G.729 Códec usado para llamadas de fax G.711 G.711 G.711 G.711 Ancho de banda para llamadas de voz (llamadas de voz simultáneas x 21.2 por llamada) 742 Kbps 106 Kbps 106 Kbps 106 Kbps Ancho de banda para llamadas de fax (una llamada de fax por 85 Kbps por llamada) 85 Kbps 85 Kbps 85 Kbps 85 Kbps Total de ancho de banda de llamadas de voz y de llamadas de fax 827 Kbps 191 Kbps 191 Kbps 191 Kbps Control de voz 10 Kbps 8 Kbps 8 Kbps 8 Kbps Ancho de banda de datos 1.5 Mbps 256 Kbps 256 Kbps 256 Kbps Ancho de banda del enlace total 2.5 Mbps 512 Kbps 512 Kbps 512 Kbps Tabla 2.5. Cálculos del ancho de banda En la tabla 2.6 se calcula orientativamente el ancho de banda para el tráfico de datos. Criterio Madrid Valencia Sevilla Bilbao Conexiones AS/400 (tráfico fijo) 1Conexión x 8Kbps 320 Kbps 56Kbps 56Kbps 56Kbps Otro tipo de tráfico variable (Internet / outlook/Aplicac.) 1Conexión x 25Kbps 100 Kbps 175 Kbps 175 Kbps 175 Kbps Ancho de banda de datos 1320 Kbps 231 Kbps 231 Kbps 231 Kbps Tabla 2.6. Cálculo del ancho de banda de datos. Una vez se ha detallado el ancho de banda entre las sucursales y la sede central de Barcelona, se calcula el ancho de banda de esta como la suma de todas las demás. De este modo, el ancho de banda contratado por la sede central ha de ser de 4.5 Mbps, de los cuales 2 Mbps son para voz (VoIP) y 2.5 Mbps para el tráfico de datos. El enlace WAN contratado a la Telefónica, como se verá posteriormente, ha de ser de una red MPLS ATM con el servicio VPN de 2Mbps para voz y 2.5 Mbps para datos, priorizando el tráfico de voz sobre datos. La red WAN MPLS ATM con el servicio VPN se describe en detalle en el capítulo 4. 15 3. Introducción al servicio VoIP Las empresas requieren cada vez más la combinación de los servicios de voz y datos a través de la misma red con el objeto de reducir costes y beneficiarse de los servicios y aplicaciones de la transmisión de voz por paquetes. Esta transmisión por paquetes de voz permite a un dispositivo (teléfono IP) enviar tráfico de voz a través de redes como Frame Relay, ATM o, en el caso que se describe en este proyecto, a través de una red IP y una red MPLS ATM con el servicio VPN para mayor seguridad de los datos de la empresa. Para VoIP, el DSP (Digital Signal Procesor) segmenta la voz en frames. El voice gateway los combina para formar un paquete IP y enviarlo sobre una red IP. Una vez recibida la información, el receptor efectúa el proceso inverso y convierte los paquetes IP en señal de voz. Cuando los paquetes VoIP cruzan la red IP, estos son transportados mediante el RealTime Transport Protocol (RTP) y RTP Control Protocol (RTCP) y se utiliza User Datagram Protocol (UDP) como protocolo de transporte. RTP utiliza mecanismos para la sincronización de los frames de la voz como los timestamps y números de secuencia. RTCP provee mecanismos para informar de la calidad de la voz de las llamadas mediante medidas de retraso, jitter y paquetes perdidos. VoIP no utiliza TCP como protocolo de transporte debido a que TCP, que garantiza las retransmisiones, introduce para ello mecanismos de acuse de recibo, lo que conlleva retrasos intolerables en el tráfico de voz. VoIP usa, además de los citados protocolos (RTP/UDP/IP) para el transporte de llamadas, otros protocolos de señalización para el establecimiento y la desconexión de las llamadas, para transmitir la información de búsqueda de usuarios, y para el intercambio de algoritmos de compresión de la voz. Los protocolos más usuales son H.323, Media Gateway Control Protocol (MGCP), Session Initiation Protocol (SIP), y Skinny Client Control Protocol (SCCP) propietario de Cisco. Los protocolos empleados en el presente proyecto son el H.323 y el SCCP. Como mejora, en un futuro se tiene previsto sustituir el protocolo H.323 por el MGCP, que abrevia y mejora el desarrollo de VoIP. Un router con capacidad para fragmentar la voz en paquetes se denomina también “voice gateway” e incluye el servicio conocido como toll bypass. Este servicio reduce en su conjunto los gastos gracias al encaminamiento de llamadas entre sucursales sobre una WAN basada en paquetes, procedimiento que evita el gasto de las llamadas entre diferentes localizaciones. Con este método, las llamadas realizadas desde Barcelona a Madrid, que antes eran de tipo interprovincial, se encaminan ahora desde el gateway de voz de Barcelona a través de la WAN al gateway de voz de Madrid, y desde allí sale a la PSTN como si fuera una llamada de Madrid. Si existen problemas en la WAN (por ejemplo un enlace caído), el gateway de voz se comunica con la PSTN y cursa la llamada de manera tradicional. Dentro del voice gateway se localizan los DSP que tienen la capacidad de manejar diferentes tipos de algoritmos de compresión como G.711, G.723.1, G.726, G.728 y G.729. Los tipos seleccionados para la implementación de este proyecto son el G.711 para llamadas internas y llamadas a la misma provincia y el G.729 para llamadas entre sucursales y a otras provincias. La utilización de estos codecs y del protocolo 16 compressed RTP (cRTP), reduce considerablemente el ancho de banda del tráfico de VoIP. En las redes VoIP se debe imponer un control de admisión de llamadas (CAC) para que la transmisión de nuevas llamadas no degrade otras llamadas cuando apenas hay ancho de banda disponible. Igualmente, se debe realizar un buen dimensionamiento de la red y se deben aplicar mecanismos de calidad de servicio (QoS). La solución que provee cisco a la integración de voz, video y datos a través de la misma red se llama Cisco AVVID. En el diseño del proyecto se ha reemplazado la PBX tradicional por un servidor Cisco Call Manager que procesa las llamadas basadas en IP. A su vez, los teléfonos analógicos se han sustituido por Cisco IP Phones. Como mejora, en un futuro se prevé reemplazar el sistema de mensajería por un sistema de mail de voz basado en IP, conocido como Cisco Unity. 3.1. Protocolos VoIP Existen dos tipos de protocolos en la operativa de VoIP: • Protocolos que proveen el control de la llamada y la señalización. • Protocolos que transportan la carga útil (RTP, RTCP, UDP, e IP). Los protocolos de control y de señalización se utilizan para el establecimiento y la desconexión de las llamadas entre dos dispositivos de la red VoIP. Se pueden utilizar diferentes protocolos, como por ejemplo: • H.323: modelo punto a punto. • Session Initiation Protocol (SIP): modelo punto a punto. • Media Gateway Control Protocol (MGCP): modelo cliente-servidor. • Skinny Client Control Protocol (SCCP): protocolo patentado por Cisco que utiliza el modelo cliente-servidor. En la red desarrollada en el presente proyecto se ha utilizado el protocolo H.323 y el protocolo Skinny. Como mejora se propone en un futuro la utilización del protocolo MGCP. El Call Manager también actúa como un protocolo traductor. El Call Manager se comunica con el gateway de voz mediante H.323 o MGCP y con el teléfono IP mediante SCCP. 3.1.1. H.323 El protocolo H.323 es una especificación de la Internacional Telecommunication Union (ITU) para transportar tráfico de voz en tiempo real sobre una red IP. Este protocolo se compone de: 17 • H.225. Establece una conexión IP entre dos dispositivos H.323. • H.245. Permite a H.323 negociar sus características, como por ejemplo los códecs disponibles. • RAS. Los dispositivos H.323 usan este tipo de protocolo para comunicar con los gatekeepers H.323 para gestionar el registro, la administración y el status. Estos tres componentes usan TCP como protocolo de transporte. 3.1.2. SIP Este protocolo es un estándar RFC de Internet Engineering Task Force (IETF). SIP es un protocolo punto a punto. En este contexto, los puntos de la comunicación, también llamados user agents (UAs), actúan como clientes (UAC) para iniciar una petición SIP o como servidores (UAS) cuando se comunican con el cliente y responden a su petición. Los clientes SIP son los teléfonos IP y las entidades de encaminamiento son los servidores. Existen tres tipos de SIP Server: el proxy, el redirect y el registrador, que utilizan seis tipos de mensajes para realizar sus funciones: register message, invite, ack, bye, cance y option. Cada dispositivo SIP utiliza una dirección única como un e-mail ID. 3.1.3. MGCP Este protocolo está basado en un modelo cliente servidor y usa el Session Description Protocol (SDP) para describir y negociar las características del medio. SDP es parecido a H.245 en H.323. Los componentes principales de MGCP son: • MGCP Gateway (MG). Es la interfaz entre una red de telefonía tradicional o una PBX y una red VoIP. Puede ser un router como los utilizados en este proyecto, un Cisco de la serie 37xx. • Media Gateway Controller (MGC). Controla los mensajes de estado durante la llamada. También se conoce como agente de control (CA). Cisco Call Manager actúa como un CA para proveer las funciones de procesamiento de llamadas y control del MG. Los mensajes MGCP son enviados entre CA y MG a través de UDP/IP. El tráfico de voz es transportado a través de RTP/UDP/IP. MGCP es independiente del medio de transporte y puede ser usado para controlar ATM o el gateway de los circuitos conmutados. MGCP utiliza comandos simples en el proceso de negociación entre MG y AC y usa el protocolo UDP para transmitir sus mensajes. Los mensajes pueden ser: CRCX para la creación de la conexión, MDCX para la modificación de la conexión, DLCX para suprimir la conexión, RQNT para la notificación de la petición, NTFY para notificar 18 mensajes de señalización, AUEP para auditar el dispositivo, AUCX para auditar la conexión y RSIP para restaurar llamadas cortadas. 3.1.4. SCCP Este protocolo, del que es propietario Cisco, está basado en un modelo cliente-servidor. Cisco Call Manager, que en este contexto es el servidor, posee toda la inteligencia, mientras que los teléfono IP, que son los clientes, poseen sólo un mínimo de inteligencia. Cisco Call Manager debe conocer por tanto las características del cliente, controlar el establecimiento de las llamadas, suprimir las llamadas, enviar las notificaciones de la señalización, etc. Cisco Call Manager se comunica con los teléfonos IP mediante SCCP y con los gateway mediante H.323. En un futuro se prevé que utilice como mejora el MGCP. 3.1.5. RTP/RTCP Una vez establecida la llamada a través de los anteriores protocolos, el RTP/RTCP se encarga de la transmisión de datos entre el dispositivo de origen y el dispositivo final. Estos dos protocolos utilizan UDP como protocolo de transporte. La cabecera de información IP que transporta paquetes RTP/RTCP tiene 40 bytes de información repartida en 20 bytes de cabecera IPv4, 8 bytes de cabecera UDP y 12 de RTP. Después de esta cabecera se añaden 2 frames de 10 bytes (utilizando el códec G.729) de carga útil de voz. De este modo, la cabecera ocupa inicialmente el doble de espacio que la carga útil, por lo que se utiliza el método de compresión RTP para reducir la cabecera y pasar de 40 bytes a 2 o 4 bytes de longitud. 3.2. Componentes de la Telefonía IP Los componentes de la telefonía IP son: • Infraestructura de red • Proceso de llamadas • Call Manager • Dispositivos finales de la telefonía IP • Control de admisión de llamadas (CAC) • Calidad de voz • Fax 19 3.2.1. Infraestructura de red Se debe tener un especial cuidado con la infraestructura de red y se debe diseñar adecuadamente para soportar la integración de la voz y los datos en la misma red IP. Se deben establecer mecanismos de calidad de servicio (QoS) para evitar los retardos, el jitter, la pérdida de paquetes, etc. Los teléfonos IP se han configurado en el entorno LAN. Los teléfonos IP se conectan a switches que tienen configuradas dos VLAN, una para voz y otra para datos. La conexión con los routers incluye una clasificación de paquetes para dar mayor prioridad a unos sobre otros, mientras que en el entorno WAN se ha utilizado la red MPLS ATM con servicio VPN para garantizar la seguridad y el ancho de banda. 3.2.2. Proceso de llamadas El dispositivo principal en la tecnología VoIP desarrollada por Cisco es el Cisco Call Manager. Este dispositivo lleva a cabo todo el procedimiento de las llamadas, las peticiones y las contestaciones a los dispositivos que requieren su utilización. Cisco Call Manager es un software que se ejecuta sobre Windows 2003 Server. Los servidores Cisco Call Manager están agrupados en un cluster para soportar un mayor número de dispositivos. El Publisher Server escribe y lee de una base de datos Microsoft SQL que almacena toda la información disponible en el cluster. El otro tipo de servidor, el Cisco Call Manager Subscriber, solamente puede leer de esta base de datos. Si el Publisher funciona el Subscriber sólo se utiliza como backup. Si el Publisher cae, no se pueden añadir ni administrar dispositivos, pero el encaminamiento de las llamadas permanecerá activo a través del Subscriber. Cisco Call Manager también puede actuar como un Trivial File Transfer Protocol (TFTP) y como un Music-on-hold Server. Cisco Call Manager almacena la configuración de los teléfonos IP en el TFTP Server. Los teléfonos IP descargan las configuraciones y los firmware de los servidores TFTP. Los teléfonos IP reciben la información del TFTP Server mediante la opción 150 del servidor CDP. 3.2.3. Call Manager (CCM) Call Manager está enlazado con un directorio Lighweight Directory Access Protocol (LDAP) denominado DC directory (DCD). Este es un producto patentado por Cisco. Cisco Call Manager almacena sistemas y configuraciones de los dispositivos en la base de datos Miscrosoft SQL. Los scripts de aplicaciones y la información sobre la autorización y autenticación del usuario, los perfiles de extensiones, los perfiles personales, información internacional, la personal address book (PAB), el nombre del llamante, marcación rápida y toda la información de llamadas son almacenadas en el DCD. 20 3.2.4. Dispositivos IP Los dispositivos IP aceptan o inician las sesiones de VoIP. Estos dispositivos pueden ser: teléfonos IP, SoftPhone, Wireless IP Phone, Voice Gateways, Survivable Remote Site Telephony (SRST) y Call Manager Express CME. Existen varios modelos de teléfonos IP. Como se detalla más adelante, en este proyecto se han utilizado el 7940 y el 7960 con extensiones como centralita. La configuración de los teléfonos IP consta de una parte automática: el descubrimiento del teléfono por parte del Call Manager, así como la posterior configuración del teléfono con su dirección IP, máscara, gateway, DNS y TFTP. En la configuración de este proyecto los teléfonos IP obtienen la información de red IP a través de DHCP. Softphones son aplicaciones basadas en software que se ejecutan en el ordenador como un teléfono IP. Los voice Gateways conectan la red de telefonía IP a la PSTN o a una PBX. Call Manager soporta varios gateways de voz. El gateway de voz que se utiliza en la red es el Router 3745. El Call Manager se comunica con los gateways a través de los protocolos MGCP, H.323 y SIP. El protocolo MGCP no necesita un plan de marcación , y no hace falta configurar Dial peers en los routers. Con H.323 hace falta configurar un plan de marcación y configurar Dial peers en el router. En el router de la red de este proyecto se configura la señalización de voz mediante primarios de voz E1 (PRI) en las sucursales de Barcelona y Madrid, y mediante BRI en el resto de sucursales. El método Survivable Remote Site Telephony (SRST) provee soporte de fallo para los teléfonos IP que son conectados al router que soporta SRST. Durante un período de funcionamiento normal, cuando Cisco Call Manager está activo y los enlaces WAN están disponibles, los teléfonos IP se comunican a través de los enlaces WAN para llamadas entre sucursales. La característica SRST se activa en un router tan pronto como se detecta un fallo en la red WAN. El router detecta el fallo por la caída de un enlace y los terminales IP detectan el fallo cuando no reciben tres acuses, Keepalive, desde el Cisco Call Manager. En este caso en que falla la red WAN, la característica SRST provee el manejo de llamadas básicas a los teléfonos IP. Sin esta característica no podrían realizarse llamadas ante la caída de un enlace. 3.2.5. Control de admisión de llamadas (CAC) En las redes VoIP, el control de admisión de llamadas (CAC) realiza la administración eficiente del ancho de banda. CAC se asegura de que existe suficiente ancho de banda antes de permitir al gateway cursar la llamada a través de la red WAN. Este proceso se puede aplicar tanto al Call Manager como al gateway de voz. En el Cisco Call Manager, como se verá con posterioridad, se aplica un límite de ancho de banda en el envío de llamadas a través de la red IP WAN. Para ello se configuran varias locations (una por sucursal) y se asigna un ancho de banda a cada enlace. Este ancho de banda dependerá de la cantidad de teléfonos IP y del códec utilizado. El Call Manager comprueba las tablas de las locations para determinar si existe el suficiente ancho de banda para cursar la llamada. 21 En los gateways de voz se provee este control de admisión de llamadas para garantizar el ancho de banda en el establecimiento de las llamadas. Este método simplifica la configuración del router. 3.2.6. Calidad de la VoIP El tráfico de voz difiere del tráfico de datos en los siguientes puntos: • Los datos a menudo forman ráfagas, mientras que la voz sigue una pauta más determinista. • Las aplicaciones de datos reenvían los paquetes perdidos, mientras que las aplicaciones de voz tratan de “disimular” los paquetes perdidos. • Las aplicaciones de datos pueden tolerar algunos retardos, mientras que las aplicaciones de voz deben minimizar el retardo. Estas diferencias provocan el uso de estrategias diferentes de QoS para obtener una estricta prioridad del tráfico de voz y garantizar de un lado la transmisión correcta de los datos y de otro un retardo mínimo en las redes que transportan voz y datos. Retardos El retardo se mide como el tiempo que tardan los paquetes de VoIP en viajar de un dispositivo final a otro extremo de la red. Dada la velocidad de los enlaces y el tiempo de procesado de los dispositivos intermedios, es inevitable un retardo mínimo de transmisión. Sin embargo, debe tratar de minimizarse el retardo total de la transmisión. El oído humano acepta un retardo de 150 milisegundos. Se puede medir el retardo fácilmente usando un test de ping de duración distinta, en días distintos y con distintas cargas de tráfico de red. Jitter Aunque el retardo excesivo puede impedir una conversación normal, los retardos de longitudes variables (también conocidos como jitter) pueden tener un efecto parecido y afectar la inteligibilidad de la llamada. El jitter no suele ser un problema en las llamadas PSTN dado que en este caso existe un ancho de banda reservado. Sin embargo, en las redes VoIP en las que la voz convive con el tráfico de datos, las ráfagas de datos pueden llegar a afectar la calidad de las llamadas. Los gateways de voz de Cisco contienen un jitter-buffering con el objetivo de compensar, dentro de un margen determinado, los efectos negativos del jitter en la calidad de la voz. 22 Serialización La serialización describe lo que ocurre cuando un router intenta enviar paquetes de voz y datos simultáneamente a través de una interfaz. En general, los paquetes de voz son más pequeños (de 80 a 256 bytes) que los paquetes de datos (de 1500 a 18000 bytes). En enlaces lentos, como conexiones WAN, los paquetes grandes pueden tardar en ser enviados. Cuando estos paquetes están mezclados con pequeños paquetes de voz, el excesivo tiempo de transmisión puede llevar a retardos y jitter [4]. Consumo de ancho de banda Una conversación de voz tradicional consume un ancho de banda de 64 Kbps [4]. Cuando se transmite a través de una red VoIP, la información de voz puede ser comprimida y digitalizada. Esta compresión puede reducir el ancho de banda a cantidades próximas a los 5 Kbps. Para transmitir los paquetes de voz a través de una red IP, deben añadirse como se ha dicho las cabeceras apropiadas de IP/UDP/RTP. Esto puede requerir un substancial aumento de ancho de banda para cada llamada (sobre 40 bytes por paquete). La compresión de cabeceras RTP, sin embargo, puede reducir el tamaño de dichas cabeceras, como queda dicho, hasta los dos bytes solamente [4]. 3.2.7. FAX En los gateways de voz existen tres métodos para la transmisión de faxes: Fax passthrough, Cisco fax relay, y T.38 Fax relay. Como se verá más adelante, en el presente proyecto se ha empleado las tarjetas adaptadoras ATA 186 para adaptar los faxes a la red de telefonía IP. 3.3. Arquitectura de la telefonía IP En el presente proyecto se ha optado por una arquitectura centralizada en la sede principal de Barcelona, en la que se ha instalado el Cisco Call Manager que procesa todas las llamadas de la compañía. En la figura 3.1 se muestra el esquema de esta arquitectura que dibuja una topología de hub-and-spoke, en la cual el hub es la sede principal de Barcelona y los spokes representan las sucursales. Cada sucursal se define como una location en el Cisco Call Manager, que tiene asignado un acho de banda y un codec para cada posible llamada entre dos locations. Call Manager mantiene la comprobación del ancho de banda del enlace para el establecimiento de nuevas llamadas[4]. Se utiliza el códec G.711 dentro de la LAN y el codec G.729 para las llamadas entre sucursales. Como se verá con posterioridad, se ha configurado una QoS en el enlace WAN mediante la clasificación del tráfico y su priorización. Este tipo de arquitectura provee un plan de marcación claro, una administración sencilla, y un coste reducido en las llamadas entre sucursales. 29 4.3. Diagrama de Red En las sedes de Barcelona y de Madrid se utilizan routers 3745 para acceder a la WAN (MPLS) y a la PSTN. Para las sucursales de Bilbao, Sevilla y Valencia se usan asimismo los routers 3745. Como sistema de backup se utiliza una red ADSL de 10 Mbps de COLT con túneles IPSEC entre todas las sucursales. De acuerdo con el dimensionado de las llamadas realizado en el capítulo 2, tanto en Madrid como en Barcelona se usan Tarjetas de Primarios de Voz. En las sucursales de Bilbao, Sevilla y Valencia se usan 2 BRI para la conexión a la red PSTN. Los tráficos de voz y datos son separados mediante VLAN en los switch 3550. Estos switchs proporcionan tensión a los teléfonos IP, con lo que se ahorra hardware de fuentes de alimentación para cada teléfono IP. Figura 4.3. Diagrama de red. 4.4. Teléfonos IP utilizados Los teléfonos utilizados Cisco IP Phone 7940G tienen las siguientes características: • Pixel Display Large. • Dynamic Soft Keys. • Max. line (Calls) 2, (4). • Headset jack (conectores para auriculares). • Speaker phone only monitor. • Inline Power. • Ethernet Switch. 30 Figura 4.4. Terminal IP. Además de este teléfono se utiliza el modelo 7960 con extensiones para proporcionar el servicio de recepción de llamadas en todas las sucursales. Existe un apartado que detalla con más claridad este concepto. 4.5. Infraestructura LAN y WAN 4.5.1. Switch 3550-3750 Los teléfonos IP se conectan mediante el switch Catalyst 3550-24 PWR a dos VLAN, una para el tráfico de datos y otra para el tráfico de voz. De este modo, el PC se conecta a través del mismo conector del teléfono IP. Este tipo de switch diferencia los paquetes de voz y de datos mediante el análisis de paquetes. Si el paquete está “taggeado” (es decir, si contiene en la cabecera la VLAN auxiliar), se asocia con la VLAN de voz, y si no está “taggeado”, se asocia con la VLAN de datos. Los switch Cisco permiten la configuración de una VLAN auxiliar o VLAN de voz que simplifica la configuración de los puertos. Al configurar un puerto con una VLAN de voz se crea automáticamente una interconexión entre las diferentes VLAN disponibles en el switch mediante el protocolo de red 802.1q (trunking). De este modo, los teléfonos conectados a un puerto configurado con VLAN de voz son reconocidos automáticamente por el switch mediante CDP (Cisco Discovery Protocol). El protocolo 802.1q también permite marcar los paquetes en el switch añadiendo 4 bytes después de la dirección MAC. Este marcado permite, como veremos en el capítulo 6, establecer la QoS conjuntamente con los bits ToS[4] Se ha optado por este tipo de switch para implementar el servicio de power-in-line, por lo que el switch proporciona tensión a los teléfonos IP. Esto conlleva un ahorro de fuentes de energía y una simplificación de las instalaciones. A continuación se detalla la configuración del switch situado en la sede central de Barcelona. 31 Configuración del Switch de Barcelona SW3550P1(config)# interface range fastethernet 0/2 – 24 SW3550P1(config)# no shutdown SW3550P1(config-if-range)# mls qos trust cos SW3550P1(config-if-range)# switchport voice vlan 201 SW3550P1(config-if-range)# switchport acces vlan 101 SW3550P1(config-if-range)# switchport priority extend cos 0 SW3550P1(config-if-range)# priority-queue out SW3550P1(config-if-range)# spanning-tree portfast SW3550P1(config-if-range)# switchport mode trunk SW3550P1(config-if-range)# switchport trunk encapsulation dot1q Con esta configuración se crean la VLAN 101 para el tráfico de datos y la VLAN 201 para el tráfico de voz. Además se confía en los valores CoS establecidos por el teléfono IP, y se desconfía del puerto del PC localizado en el puerto del teléfono IP. Por último, se configura el enlace con IEEE 802.1q trunk. La misma configuración debe repetirse en el puerto uplink que conecta con el router 3745, con la salvedad del comando mls qos trust dscp en el que se confía en el marcado dscp de los paquetes que vienen desde el router WAN. 4.5.2. Router 3745 La red WAN debe configurarse de tal forma que incluya QoS y el control de admisión de llamadas (CAC). En la telefonía tradicional, cuando se tiene una PBX con un primario y se están utilizando todos los canales, las siguientes llamadas son rechazadas durante el establecimiento de llamada. Esto no pasa con la Telefonía IP. Si el ancho de banda proporcionado cubre dos llamadas simultáneas y entra una nueva llamada, esta se procesa y se deteriora la calidad de servicio de las otras dos. Para evitar esto se usa CAC en los enlaces WAN. La tecnología escogida para la red WAN es la de una MPLS VPN basada en ATM para garantizar el ancho de banda. De este modo, se proporciona un servicio VoIP eficiente y sin degradación en las llamadas. De este modo, en telefonía IP deben emplearse tecnologías capaces de garantizar ancho de banda mediante QoS. Además de la MPLS se podía haber optado por líneas dedicadas como Frame Relay, ATM e IPSec V3PN. Existen otras tecnologías no apropiadas para este servicio como cable o DSL. La razón es que estas redes usan Internet para transportar los datos y la voz, e Internet se basa en una política de best-effort que no garantiza los retardos máximos ni la prioridad necesarias para el tráfico de voz. En la siguiente tabla se indica el ancho de banda contratado para el transporte de la telefonía IP entre sucursales. 32 Enlace WAN Router Velocidad ATM % de u tilización concurrente CIR Madrid 3745 1Mbps 60 % 1Mbps Valencia 3745 256 Kbps 50 % 256 Kbps Sevilla 3745 256 Kbps 50 % 256 Kbps Bilbao 3745 256 Kbps 50 % 256 Kbps Barcelona 3745 2 Mbps 50 % 2 Mbps Tabla 4.1. Características de los enlaces WAN. La voz IP es un servicio de nivel de aplicación. Por tanto, previamente a la configuración de este servicio deberemos implementar una infraestructura de red con conectividad total IP. Para ello, vamos a realizar la consiguiente asignación de IP por LAN, identificando en cada sede la puerta por defecto y los rangos reservados, tal como se indica en las siguientes tablas. El plan de direccionamiento IP se basa en la distinción de las sucursales y sus VLANs mediante la tercera parte de la dirección IP. En la tabla 4.2 se detallan las direcciones IP para las diferentes sucursales. Sede Red IP LAN VLAN voz VLAN datos VLAN Gestión Barcelona 10.34.[1-19].0 10.34.12.0 10.34.11.0 10.34.10.0 Madrid 10.34.[3-39].0 10.34.31.0 10.34.3.0 10.34.30.0 Valencia 10.34.[5-59].0 10.34.51.0 10.34.5.0 10.34.50.0 Sevilla 10.34.[6-69].0 10.34.61.0 10.34.6.0 10.34.60.0 Bilbao 10.34.[7-79].0 10.34.71.0 10.34.7.0 10.34.70.0 Tabla 4.2. Direcciones IP. En la tabla 4.3 se detallan las direcciones IP de los enlaces LAN tanto para voz como para datos, los enlaces WAN y la red de gestión donde se encuentran todos los servidores, como el Call Manager y el servidor DHCP. LAN DATOS LAN VOZ WAN DHCP Call Manager Barcelona 10.34.11.0/24 10.34.12.0/24 172.16.1.1 10.34.1.50 10.34.12.1 Madrid 10.34.3.0/24 10.34.31.0/24 172.16.3.1 10.34.3.230 10.34.12.1 Valencia 10.34.5.0/24 10.34.51.0/24 172.16.5.1 10.34.1.50 10.34.12.1 Sevilla 10.34.6.0/24 10.34.61.0/24 172.16.6.1 10.34.1.50 10.34.12.1 Bilbao 10.34.7.0/24 10.34.71.0/24 172.16.7.1 10.34.1.50 10.34.12.1 Tabla 4.3. Direcciones IP de los routers de la red corporativa. En la tabla 4.4 se especifican las direcciones IP de origen y destino de los enlaces entre la sede central de Barcelona y las diferentes sucursales mediante la red MPLS. 33 WAN ORIGEN WAN DESTINO BCN/MAD 172.16.1.1 / 172.16.1.2 172.16.3.2 / 172.16.3.1 BCN/VAL 172.16.1.1 / 172.16.1.2 172.16.5.2 / 172.16.5.1 BCN/SEVILLA 172.16.1.1 / 172.16.1.2 172.16.6.2 / 172.16.6.1 BCN/BILBAO 172.16.1.1 / 172.16.1.2 172.16.7.2 / 172.16.7.1 Tabla 4.4. Direcciones IP de los routers de la red del proveedor. Las conexiones entre las sucursales se realizan mediante la red WAN MPLS VPN. Los routers periféricos pertenecientes a la empresa, denominados Routers CE, se conectan a la red MPLS VPN a través de una interfaz fast-ethernet, tal y como se muestra en la configuración siguiente. Configuración del router de la sucursal de Valencia (GWCEVAL). Enlace red WAN Interface fastethernet 0/1 Ip address 172.16.5.1 Duplex auto Speed auto Una vez se ha identificado todos las interfaces y subredes dentro de la red corporativa, se han configurado las interfaces del router de Valencia accediendo a la consola del router mediante un programa de emulación. La configuración del programa de emulación es la siguiente: • Velocidad 9600 bits/s • Sin paridad • 8 bits de datos • Bit de parada (8N1) El procedimiento es el siguiente. En primer lugar se enciende el router. Debe aparecer la secuencia de mensajes de arranque. Esto confirma que la comunicación por el puerto de consola es correcta. Una vez ha arrancado el router, debe aparecer el prompt ‘Router>’. Entonces debe teclearse el comando ‘enable’ para pasar a modo Privilegiado. A continuación, se debe introducir el password. Una vez en modo Privilegiado, entramos en modo Configuración Global para especificar la configuración que corresponde a cada router, conforme el modelo que se detalla a continuación. Para comunicarse con la red interna, que está compuesta por dos VLAN (una VLAN de voz con IP 10.34.51.0 y otra de datos con IP 10.34.5.0), se configuran dos interfaces fast-ethernet. Configuración del router de la sucursal de Valencia (GWCEVAL). Enlace red LAN. 34 Router>enable Router#configure terminal Router(config)#hostname GWCEVAL !Interface para la vlan de datos GWCEVAL (config)#interface FastEthernet0/0.1 GWCEVAL (config-if)#ip address 10.30.5.254 255.255.255.0 GWCEVAL (config-if)#no shutdown !Interface para la vlan de voz GWCEVAL (config-if)#interface FastEthernet0/0.2 GWCEVAL (config-if)#ip address 10.30.51.254 255.255.255.0 GWCEVAL (config-if)#no shutdown GWCEVAL (config-if)#exit GWCEVAL (config)#line vty 0 4 GWCEVAL (config-line)#password cisco Al haber configurado una contraseña en el modo Configuración de Línea es posible acceder vía Telnet al router utilizando cualquiera de sus direcciones IP. Sin embargo, al no definir un password para acceso Privilegiado solo podremos obtener dicho acceso desde la misma consola del router. De este modo, evitaremos posibles interferencias por modificación de la configuración desde otros ordenadores malintencionados. Al finalizar la configuración de los routers debemos tener conectividad a nivel unicast en toda la red, cosa que comprobaremos enviando pings a las diferentes interfaces de los routers. Como el ping utiliza la IP más próxima al router destino, la de la interfaz de salida, debemos ejecutar ping con opciones avanzadas (o ping extendido), de forma que el router tome como IP la de sus interfaces LAN, que es donde van a conectarse los teléfonos VoIP. Por tanto, para comprobar la conectividad desde todas las redes, utilizaremos el ping extendido: en la consola del router ejecutamos un ping sin ningún argumento y vamos contestando lo que nos pide, entrando en opciones avanzadas y seleccionando el IP origen las de las LAN asociadas [4]. El encaminamiento en toda la red interna se realiza mediante la versión 2 del protocolo RIP. Esto quiere decir que en todos los routers de las sucursales se ha configurar el protocolo de encaminamiento RIP v2. Este protocolo, como se verá en el capítulo de red WAN MPLS, se ocupa además de informar de las redes LAN de todas las sucursales al router PE (Provider Edge o router del proveedor) de la red MPLS VPN. Por otro lado, el router PE informa al router PE de otra sucursal mediante el protocolo iBGP (internal Border Gateway Protocol) y así el router CE (Customer Edge o router del cliente) descubre las redes disponibles sin necesidad de configurarlas manualmente. Las redes que deben ser distribuidas entre routers se configuran mediante el comando Redistribute. El encaminamiento de la red se ha realizado, como queda dicho, mediante RIP v2. A continuación de detalla su configuración. 35 4.5.3. Configuración RIP Routing Information Protocol (RIP) es un protocolo de encaminamiento clásico de vectordistancia. RIP usa paquetes de datos broadcast User Datagram Protocol (UDP) para intercambiar información de encaminamiento. El software Cisco IOS envía actualizaciones de encaminamiento cada 30 segundos. Este proceso se califica como “publicaciones”. Si un router A no recibe una actualización desde otro router B durante 180 segundos o más, el router A marca como “no disponible” la ruta servida por el router B. Si todavía no se ha recibido ninguna actualización después de 240 segundos, el router A elimina todas las entradas de la tabla de encaminamiento para el router B [3]. La métrica utilizada por RIP para evaluar el valor de las diferentes rutas es el recuento de saltos. Una red directamente conectada tiene una métrica igual a cero. Una red inalcanzable tiene una métrica de 16. Este limitado rango de métricas hace que RIP no funcione bien en grandes redes. El router puede tener una ruta por defecto por la que encamina todo el tráfico que no tiene una ruta explícita. RIP trata la ruta 0.0.0.0 como una red para implementar la característica de encaminamiento por defecto. RIP permite configurar las rutas por defecto con una métrica para que un router que adquiere una ruta por defecto y tiene una ruta estática, pueda cursar el trafico por la mejor de las dos. RIP envía actualizaciones a las interfaces de las redes específicas. Si una interfaz de red no está especificada, este no se anunciará en ninguna actualización RIP. Cisco implementa la versión 2 de RIP que soporta texto plano y autentificación MD5, resumen de rutas, classless interdomain routing (CIDR), y máscaras de longitud variable de subredes (VLMs). Lista de Tareas para la Configuración de RIP Para configurar RIP, se debe completar las siguientes tareas: Habilitar RIP Se usa el comando router rip y network network-number Permitir Unicast Updates para RIP Se usa el comando neighbor ip-address Aplicar Offsets para las Métricas de encaminamiento Se usa el comando offset-list [access-list-number | name] {in | out} offset [type number] Ajustes de Temporizadores Se usa el comando timers Basic update invalid hoddown fush [sleeptime] Especificar la versión de RIP Se usa el comando version { 1 | 2 }, ip rip send | receive version 1 | 2 | 1 2 36 Habilitar la autentificación RIP Se usa el comando ip rip authentication key-chain name-of-chain, ip rip authentication mode {text | md5} Deshabilitar el resumen de rutas Se usa el comando no auto-summary A continuación se define el protocolo de encaminamiento RIP versión 2 para el router de Barcelona y de Valencia. Router>enable Router#configure terminal Router(config)# router rip GWCEBCN(config-router)# version 2 GWCEBCN (config-router)#network 10.34.1.0 GWCEBCN (config-router)#network 10.34.12.0 GWCEBCN (config-router)#network 10.34.10.0 GWCEBCN (config-router)#network 172.16.1.0 Router>enable Router#configure terminal Router(config)# router rip GWCEVAL (config-router)# version 2 GWCEVAL (config-router)#network 10.34.5.0 GWCEVAL (config-router)#network 10.34.51.0 GWCEVAL (config-router)#network 172.16.5.0 Para visualizar la tabla de encaminamiento local del router de la oficina de Valencia se debe introducir el siguiente comando. Router>show ip route show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is 172.16.51.2 to network 0.0.0.0 C 172.16.5.0/24 is directly connected, FastEthernet0/1 37 R 172.16.1.0/30 [120/3] via 172.16.5.2, 00:00:13, FastEthernet0/1 R 172.16.6.0/30 [120/3] via 172.16.5.2, 00:00:14, FastEthernet0/1 R 172.16.3.0/30 [120/3] via 172.16.5.2, 00:00:06, FastEthernet0/1 R 172.16.7.0/30 [120/3] via 172.16.5.2, 00:00:13, FastEthernet0/1 C 10.34.5.0/24 is directly connected, FastEthernet0/0.1 C 10.34.51.0/24 is directly connected, FastEthernet0/0.2 R 10.34.11.0/24 [120/3] via 172.16.5.2, 00:00:7, FastEthernet0/1 R 10.34.12.0/24 [120/3] via 172.16.5.2, 00:00:7, FastEthernet0/1 R 10.34.51.0/24 [120/3] via 172.16.5.2, 00:00:7, FastEthernet0/1 R 10.34.31.0/24 [120/3] via 172.16.5.2, 00:00:21, FastEthernet0/1 R 10.34.61.0/24 [120/3] via 172.16.5.2, 00:00:22, FastEthernet0/1 R 10.34.71.0/24 [120/3] via 172.16.5.2, 00:00:23, FastEthernet0/1 . . R* 0.0.0.0/0 [120/3] via 172.168.5.2, 00:00:09, FastEthernet0/1 [120/3] via 172.168.5.2, 00:00:09, FastEthernet0/1 El encaminamiento de la red se realiza a través de RIP v2, pero si se quisiera configurar una dirección IP estática para encaminar el tráfico entre las sucursales, se haría de la siguiente manera. “ip route red máscara siguiente-salto” Por ejemplo, para llegar desde Barcelona a Madrid, debe introducirse en Barcelona la siguiente ruta estática: “ip route 10.34.31.0 255.255.255.0 172.16.1.2” 38 45 En el séptimo paso, se establece el plan de marcación o Dial Plan. En el presente proyecto, se ha asignado un número directo de PSTN, Direct Inward Dial (DID), a cada extensión Directory Number (DN) de cada teléfono IP para las sucursales de Barcelona y Madrid. El resto de sucursales no disponen de DIDs para cada DN ya que los enlaces no lo permiten. La Tabla 5.7 detalla el plan de marcación final, el rango de teléfonos DID y el rango de extensiones DN. En el octavo paso, se definen los requerimientos del encaminamiento de las llamadas. Las llamadas se clasifican en dos tipos. • Llamadas internas: realizadas dentro de las sucursales, cuyos números pertenecen por tanto al plan de marcación del Call Manager. • Llamadas externas: realizadas a la PST y cuyos números no pertenecen al plan de marcación del Call Manager. En este caso, el Call Manager identifica el tipo de llamada en función del número marcado y envía la llamada al gateway especificado para el LessCostRouting. En este tipo de llamadas se utiliza el enlace WAN para el ahorro de coste. En caso de que no estuviera disponible el enlace WAN, las llamadas se establecerían a través del gateway de voz de la sucursal que realiza la llamada (para lo cual es necesaria la opción SRST en los gateway de voz 3745, que en la actualidad no poseen). En el noveno paso, se define el plan de encaminamiento del Call Manager. Este plan determina todos los aspectos del control de las llamadas, y se divide en tres elementos. • Route Pattern. Se utiliza para identificar diferentes grupos de números de teléfonos. Los Route Pattern pueden mapear destinos internos y destinos externos PSTN. • Route List. Provee varias rutas para encaminar la llamada. Se asocia un Route Pattern a una Route List. • Route Group. Es una lista de los dispositivos o gateways que pueden encaminar la llamada a diferentes destinos. El Route Group direcciona todas las llamadas a un dispositivo principal, y en el caso de ser inaccesible se configura un segundo dispositivo que suele ser el gateway de voz de la propia sucursal. Cuando un número marcado es mapeado por un Route Pattern, Call Manager encamina la llamada a través del Route Group que se especifica en la Route List. Estas opciones se configurarán posteriormente (paso duodécimo). En el décimo paso, se configuran las partitions o particiones, que definen grupos de dispositivos con características similares. Las opciones más destacadas que se pueden añadir a una partición son el Route Pattern y el directory number del teléfono IP. Las particiones se mapean en base a criterios como las llamadas locales, llamadas de larga distancia, internacionales, números internos, números de emergencia, etc. Las particiones sirven para flexibilizar las restricciones a los teléfonos. Por ejemplo, si un teléfono solamente realiza llamadas internas, se añade una partición de llamadas locales a su Calling Search Space (CSS). Y si a este teléfono se le permitiese también realizar llamadas internacionales, se le 46 añadiría la partition SR a su CSS. En la tabla 5.8 se detallan las particiones que se han configurado en el Call Manager. Y en la figura 5.7 se crean las particiones en Call Manager. Partition Descripción BarcelonaNac Llamadas de larga distancia realizadas desde Barcelona. BarcelonaInt Llamadas internas dentro de la sucursal de Barcelona BarcelonaSR Llamadas sin restricciones de Barcelona, incluye las llamadas internacionales MadridNac Llamadas de larga distancia realizadas desde Madrid MadridInt Llamadas internas dentro de la sucursal de Madrid MadridSR Llamadas sin restricciones de Madrid, incluye las llamadas internacionales. ValenciaNac Llamadas de larga distancia realizadas desde Madrid ValenciaInt Llamadas internas dentro de la sucursal de Valencia ValenciaSR Llamadas sin restricciones de Valencia, incluye las llamadas internacionales. SevillaNac Llamadas de larga distancia realizadas desde Madrid SevillaInt Llamadas internas dentro de la sucursal de Sevilla SevillaSR Llamadas sin restricciones de Sevilla, incluye las llamadas internacionales. BilbaoNAc Llamadas de larga distancia realizadas desde Madrid. BilbaoInt Llamadas internas dentro de la sucursal de Bilbao BilbaoSR Llamadas sin restricciones de Bilbao, incluye las llamadas internacionales. Tabla 5.8. Asignación de particiones. Figura 5.7. Creación de particiones. 47 En la figura 5.8 se muestra la configuración de la partición para las llamadas internas de la sucursal de Barcelona. Figura 5.8. Configuración de la partición de Barcelona. Figura 5.9. Calling Search Space Configuration. En el undécimo paso, se configura la Calling Search Space, que es una lista ordenada de particiones que el teléfono busca antes de permitir emplazar la llamada. Las CSSs son asignadas a los dispositivos que pueden iniciar las llamadas (es decir, los teléfonos IP y los 48 gateways) para determinar a dónde pueden llamar. Los teléfonos solamente pueden llamar a las particiones de la CSS que tiene asignados. Con la Calling Search Space se da permiso al establecimiento de llamadas. El teléfono que realiza la llamada tiene asignada una CCS. Si dentro de la CCS está la partición que incluye el teléfono de destino, entonces se puede cursar la llamada. De esta manera, se pueden prohibir por ejemplo las llamadas a números 800 (es decir, las llamadas con coste adicional). En la figura 5.9 se detalla la configuración de la Calling Search Space de los teléfonos de Barcelona Nac. Y en la tabla 5.9 se detallan las particiones asociadas a las Calling Search Space. CSS Partitions CSSBarcelona BarcelonaNac; BarcelonaInt; BarcelonaSR; MadridNac; MadridInt; MadridSR; ValenciaNac;ValenciaInt;ValenciaSR; SevillaNac; SevillaInt; SevillaSR BilbaoNac; BilbaoInt; BilbaoSR CSSMadrid MadridNac; MadridInt; MadridSR; BarcelonaNac; BarcelonaInt; BarcelonaSR; ValenciaNac;ValenciaInt;ValenciaSR; SevillaNac; SevillaInt; SevillaSR BilbaoNac; BilbaoInt; BilbaoSR CSSValencia ValenciaNac;ValenciaInt;ValenciaSR; BarcelonaNac; BarcelonaInt; BarcelonaSR; MadridNac; MadridInt; MadridSR; SevillaNac; SevillaInt; SevillaSRBilbaoNac; BilbaoInt; BilbaoSR CSSSevilla SevillaNac; SevillaInt; SevillaSR; BarcelonaNac; BarcelonaInt; BarcelonaSR; MadridNac; MadridInt; MadridSR; ValenciaNac;ValenciaInt;ValenciaSR BilbaoNac; BilbaoInt; BilbaoSR CSSBilbao BilbaoNac; BilbaoInt; BilbaoSR; BarcelonaNac; BarcelonaInt; BarcelonaSR; MadridNac; MadridInt; MadridSR; ValenciaNac;ValenciaInt;ValenciaSR; SevillaNac; SevillaInt; SevillaSR Tabla 5.9. Calling Search Space. En la tabla 5.9 se observa que todos los teléfonos pueden llamar en un principio a todos los números. En el caso en que se quisieran hacer restricciones de llamadas, se eliminaría del Calling Search Space la partición asignada al teléfono que pretende restringirse. En este caso, dicho teléfono no podrá realizar llamadas a otros teléfonos, ya que el resto de teléfonos tendrá asociado el Calling Search Space sin la partición de dicho teléfono. En el duodécimo paso, se configuran los Route Group, que son el equivalente al trunk group de la terminología tradicional PBX. Cada Route Group contiene una lista priorizada de los gateways a través de los cuales un Route Pattern envía la llamada (conforme una Route List). El Route Group envía todas las llamadas hacia el principal dispositivo. Si este fuese inaccesible, se mandaría por el segundo dispositivo, y así sucesivamente. Todos los dispositivos en el Route Pattern han de tener las mismas características. En el paso décimotercero, se configuran las Route Lists, que son listas que especifican el encaminamiento de cada llamada a través del Route Group. Una Route List envía una llamada hacía el Route Group en orden de preferencia de la configuración. Por tanto, la Route List contiene uno o varios Route Groups, que a su vez contienen uno o varios gateways hacia los que se cursa la llamada. 49 La tabla 5.10 detalla las Route Lists que se han configurado. Se debe tener en cuenta la prioridad de los dispositivos, ya que el ahorro de coste en las llamadas dependerá del cumplimiento de dichas prioridades. Route List Gateway (ordenados por prioridad) BCN_FIJOS BCN1, MAD1 BCN_MOVILES BCN2, MAD2 MAD_FIJO MAD1, BCN1 MAD_MOVILES MAD2, BAR2 SEV_FIJOS SEV1, MAD1, BCN1 SEV_MOVILES MAD2, BCN1, SEV VAL_FIJOS VAL1, BCN1, MAD1 VAL_MOVILES BCN1, MAD1, VAL BIL_FIJOS BIL1, BCN1, MAD1 BIL_MOVILES BCN1, MAD1, BIL1 Tabla 5.10. Route Lists. Podemos observar, por tanto, que una llamada dirigida a la Route List VAL_FIJOS, intentará en primer lugar cursar la llamada a través del gateway situado en Valencia. Si no es factible, lo hará a través del gateway de Barcelona, y si tampoco fuera posible enviaría la llamada al gateway de Madrid. En el paso decimocuarto, se configuran los Route Pattern encargados de encaminar las llamadas a un Route List después de realizar un mapeado de los dígitos (y manipularlos en caso necesario) que recibe el Call Manager. Para configurar los Route Pattern, es conveniente utilizar wildcards o comodines. A continuación se detallan los wildcards y transformaciones más comunes: • Wildcards. En el Call Manager cada directory number o número de teléfono es un Route Pattern. Los wildcards se usan para mapear un grupo de números marcados. La tabla 5.11 define los caracteres wildcards más importantes. • Digit Transformations. Se realizan modificaciones de dígitos tanto en los números de origen como en los números de destino que han de ser transferidos a otros sistemas. Por ejemplo, si el teléfono IP con directory number 868 realiza una llamada al 93 444 44 44 se necesita realizar la transformación DN-DID, por lo que 868 se transformaría en 93 484 48 68 para poder ser encaminado a través de la PSTN. • Calling Party Transformations. Las transformaciones realizadas en este contexto cambian el Caller ID (identificador de cliente). Estas transformaciones se pueden realizar en tres puntos, dentro de la configuración del Call Manager. • Con Calling Partys External Phone Number Mask. Este campo se encuentra en el Directory Number Configuration. Se utiliza para encaminar llamadas externas. 50 • Con Calling Party Transform Mask. Se usa para añadir una máscara al calling party number antes de ser enviada. • Con Prefix Digit. Este campo permite añadir números como prefijos para el número. Wildcard Descripción 0,1,2,3,4,5,6,7,8,9,*,# Mapea exactamente un dígito X Cualquier dígito en el rango del 0 al 9 [xyz...] Un dígito de cualquiera de los dígitos interiores a los corchetes [∧x-y] Un dígito que no está en el rango definido Wildcard? Cero o más dígitos del wildcard anterior Wildcard+ Uno o más dígitos del wildcard anterior . Un posición del route pattern Tabla 5.11. Caracteres Wildcard [4]. Figura 5.10. Configuración del Route Pattern. 51 En la figura 5.10 se representa la configuración de un Route Pattern para llamadas realizadas a 91XXXXXXX desde dispositivos asociados a la Partition BarcelonaNac. Estas llamadas son encaminadas a través del Route Group MAD_FIJO, el cual tiene definido el gateway de voz de Madrid como principal, y el gateway de voz de Barcelona como secundario. De este modo, cualquier llamada realizada a una numeración empezada por 91, por ejemplo desde un teléfono interno de la sucursal de Barcelona, se encaminaría a través del enlace MPLS hasta el gateway de Madrid para salir por este hacia la PSTN, con el subsiguiente ahorro del coste de la llamada. Si este gateway no estuviese activo, la llamada se encaminaría por el gateway de Barcelona, que es la segunda opción en el Route Group MAD_FIJO. Si, por otro lado, un teléfono interno de la sucursal de Madrid llamase a un teléfono cuyo número empezase por 91, entonces la llamada se encaminaría directamente a través del router de Madrid hacia la PSTN. La tabla 5.12 especifica los Route Pattern más destacados de la solución de la VoIP del presente proyecto. Route Pattern Route_List Descripción 93XXXXXXX BCN_FIJO Llamadas con destino Barcelona 91XXXXXXX MAD_FIJO Llamadas con destino Madrid 96XXXXXXX VAL_FIJO Llamadas con destino Valencia 95XXXXXXX SEV_FIJO Llamadas con destino Sevilla 94XXXXXXX BIL_FIJO Llamadas con destino Bilbao Tabla 5.12. Route Pattern. . Figura 5.11. Phone Configuration. 52 En el paso decimoquinto y último se configuran los teléfonos IP. A medida que se van conectando los teléfonos, el Cisco Call Manager los registra y les asigna el modelo de teléfono IP y su configuración por defecto. Una vez registrado se puede realizar la búsqueda del dispositivo a través de su dirección MAC para la configuración manual del teléfono. En primer lugar se visualiza la dirección MAC, se le asigna un nombre al dispositivo y una descripción, y a continuación se asocia el dispositivo a un device pool y, lo más importante, a un Calling Search Space y también a una location. En este proceso se puede modificar el modelo o añadir un módulo de extensión 7914 al teléfono 7960 para aumentar el número de líneas y desempeñar así la función de centralita. En la figura 5.11 se muestra la configuración del teléfono IP con dirección MAC 00-0F-24-8A-89-FF Una vez registrado el teléfono, se debe configurar la línea asociada. En este contexto el campo más importante es el Directory Number, que indica la extensión del teléfono IP. En la figura 5.12 se asocia a dicho campo la extensión 868, perteneciente a un teléfono IP de la sucursal de Barcelona. También deben configurarse el campo de Calling Search Space y la partition. En esta configuración, en el apartado de Call Forward, se redireccionan las llamadas que no contestan o están ocupadas a la extensión 800. Figura 5.12. Configuración del Directory Number. En este momento ya tenemos configurado todos los dispositivos del servicio VoIP en el Cisco Call Manager, por lo que a continuación se pueden realizar llamadas entre los teléfonos IP internos de la empresa. En todo caso, todavía no se pueden realizar llamadas al exterior. Para ello se debe configurar los enlaces PSTN y Dial peers necesarios en los gateways de voz. Estos pasos se detallan en los siguientes capítulos. 53 Una vez modificado el plan de marcación en el CCM, podemos reinicializar los terminales VoIP para que vuelvan a registrarse y comprobar que el plan de marcación es correcto. Los teléfonos pueden reinicializarse marcando por teclado * * # * * seguido. A continuación, el terminal VoIP nos preguntará si queremos inicializar el terminal VoIP. Si el terminal VoIP se encuentra bloqueado, para desbloquearlo utilizamos la secuencia por teclado * * #. A continuación ya pueden comprobarse las IP asignadas a cada teléfono VoIP y su configuración. Mediante la página web del teléfono se puede observar la información del dispositivo y la configuración de red. Figura 5.13. Información del dispositivo 868. Una vez registrados los teléfonos, ya podemos realizar llamadas a las diferentes extensiones localmente, es decir dentro de la misma zona del CCM. Como en la compañía sólo existen dos Cisco Call Manager, un Publisher y un Subscriber como backup, situados en Barcelona, ya se pueden realizar llamadas internas desde todas las oficinas a todas las oficinas sin ningún coste por llamada. Si existiera otro Cisco Call Manager en otra sucursal, los teléfonos de esa sucursal se habrían registrado en su correspondiente CCM, de modo que todavía no se podrían hacer llamadas entre teléfonos registrados en diferentes CCM. A continuación vamos a suponer que tenemos dos CCM. Uno en Barcelona para registrar todos los teléfonos IP de Barcelona, Valencia y Bilbao. Y otro CCM en Madrid para registrar todos los teléfonos de Madrid y Sevilla. Para poder desviar las llamadas a los diferentes CCM, deberemos configurar los CCM explícitamente para que estén informados de la localización de otros CCM. Esta operación debe realizarse manualmente. 54 Por tanto, en el CCM de Barcelona debemos introducir la siguiente configuración (que se explica a reglón seguido) para desviar las llamadas propias de Madrid Barcelona(config)#dial-peer voice 10 voip Barcelona (config-dial-peer)# destination-pattern ... Barcelona (config-dial-peer)# session target ipv4:10.34.12.1 Barcelona (config-dial-peer)# exit y en el CCME de Madrid: Madrid(config)#dial-peer voice 10 voip Madrid (config-dial-peer)# destination-pattern ... Madrid (config-dial-peer)# session target ipv4:10.34.12.2 Madrid (config-dial-peer)# exit Con estas configuraciones indicamos que los vecinos de marcación o iguales de marcación (dialpeer) a través de VoIP (digital) con el plan marcación especificado (destination-pattern expresión-regular), deben desviar la llamada al CCM correspondiente (session target ipv4). Cabe destacar que en este encaminamiento de llamadas, la señalización empleada entre los CCM no es SCCP si no H.323, concretamente la H.225. En este caso particular, Barcelona desviará todas las llamadas con prefijo 2 al CCM de Madrid y por su parte, Madrid desviará todas las llamadas con prefijo 1 a Barcelona. Una vez realizada esta configuración, se comprueba que todos los teléfonos VoIP se pueden comunicar entre sí, incluso si se han registrado en diferentes CCMs. Dentro de cada zona gestionada por cada CCM, pueden localizarse los teléfonos, dado que el propio CCM los tiene registrados localmente. Es por ello, que con la configuración anterior, cuando realizamos las llamadas desde Madrid con destino a Barcelona o Valencia, el propio CCM de Barcelona, responde por dichas extensiones, dado que Barcelona y Valencia se han registrado en el CCM de Barcelona. Las expresiones regulares en “destination-pattern” de la configuración del Dial peer incluyen los siguientes caracteres ^[][^09,A-F#*.?+%()-]*T?(\$)?$. El punto “.” es comodín de un dígito en el plan de marcación dentro del comando “destination-pattern”. “T” es comodín de cualquier extensión en el plan de marcación dentro del comando “destination-pattern”, independientemente del número de dígitos utilizados. La opción “T” puede conllevar un retraso, debido a que el Call Manager debe detectar el final de la marcación. 5.3. Iguales de conexión (Dial peer) El Dial peer es una lista contenida en el router de cada sucursal donde se especifica el enlace por el que se ha de cursar cada llamada de salida. El Dial peer especifica, igualmente, lo que el router debe hacer con las llamadas entrantes, en este caso derivarlas siempre al Call Manager. Existen dos categorías de iguales de conexión telefónica, que se pueden configurar a través de los comandos “Dial peer” (es decir, de la configuración de un vecino de marcación o iguales de marcación). Los “Dial peer” son bidireccionales, es decir se utilizan tanto para llamadas entrantes como salientes. 61 siguiente configuración para el Dial peer de la sucursal de Valencia, el cual tiene 2 BRI (4 puertos) para enlazar con la PSTN. dial-peer voice 31 pots preference 1 destination-pattern 9........ direct-inward-dial port 1/0:0 forward-digits all dial-peer voice 32 pots preference 2 destination-pattern 9........ direct-inward-dial port 1/0:1 forward-digits all dial-peer voice 33 pots preference 3 destination-pattern 9........ direct-inward-dial port 2/0:0 forward-digits all dial-peer voice 34 pots preference 4 destination-pattern 9........ direct-inward-dial port 2/0:1 forward-digits all Para poder realizar esto, debe convertirse el número de la extensión (3 digitos) a un número de la red PSTN (9 digitos), con lo que se debe diseñar una translation-rule como se explicó en el capítulo de la configuración del Call Manager. Esto se hace desde la translation pattern. A continuación se detalla la configuración del router. translation-rule 2 Rule 1 ^7… 9348447… Rule 2 ^8… 9348448… Rule 3 ^9… 9348449… Además de este Dial peer POTS saliente, también se deben encaminar hacia el exterior otras llamadas como las que se hacen a números 800 (que podrían denegarse como se explicó en el capítulo de configuración del Call Manager), las llamadas realizadas al número de emergencia 112, las llamadas al sistema de información 118, etc. 62 Todo este tipo de llamadas, que se realizan con un Dial peer POTS saliente, se detallan en la configuración de los Dial peers siguientes. Todos estos Dial peers han de ser duplicados para el segundo primario de voz en el caso de Barcelona y Madrid, y para todos los puertos BRI para el resto de las sucursales. dial-peer voice 14 pots destination-pattern 8........ direct-inward-dial port 1/0:15 forward-digits all dial-peer voice 15 pots destination-pattern 112 direct-inward-dial port 1/0:15 forward-digits all dial-peer voice 12 pots destination-pattern 118.. direct-inward-dial port 1/0:15 forward-digits all Hasta ahora se han especificado los dials peers POTS salientes. Para los dials peers entrantes, como se explicó en el apartado de iguales de conexión VoIP, el esquema es similar a los anteriores. Este tipo de llamadas incluyen los teléfonos exteriores hacia una extensión de los teléfonos IP internos. En principio, debe configurarse otra translation-rule para convertir los dígitos del plan de marcación de la PSTN al plan de marcación basado en extensiones de la compañía. Para ello se realiza la siguiente translation-rule. translation-rule 3 Rule 1 ^9348447…% 7 Rule 2 ^9348448…% 8 Rule 3 ^9348449…% 9 Una vez se han traducido los dígitos a extensiones, se debe encaminar la llamada hacia el Cisco Call Manager. Esto se realiza mediante el comando session target ipv4:Call Manager dentro de la configuración del Dial peer específico, que tiene registrados todos los dispositivos del servicio VoIP y es el encargado del encaminamiento. Se debe configurar un Dial peer específico para cada sucursal, y se debe especificar en el patrón de destino la numeración DID (destination-pattern 934844...) para que haya una prioridad de selección del Dial peer entrante VoIP en vez de la selección del Dial peer saliente POTS (destinationpattern 9........). Si no se hiciera así, se realizaría el Dial peer POTS y no se podrían encaminar las llamadas entrantes al Call Manager. Además del patrón de destino, debe especificarse el códec del enlace. De este forma se crea un grupo de códecs para la negociación de codecs en diferentes tramos de la red. Esto se realiza de la siguiente manera. 63 voice class codec 1 codec preference 1 g711ulaw codec preference 2 g711alaw codec preference 3 g729br8 codec preference 4 g729r8 El Dial peer 9010 VoIP de la sucursal de Barcelona encamina todas las llamadas externas con destino alguna extensión hacia el Call Manager, quien encaminará la llamada hacia la extensión específica. Dial peer voip 9010 voip Destination-pattern 934844... Voice class codec 3 Session target ipv4:CCall Manager translate-outgoing called 1 Dtmf-realy h245-alphanumeric El Dial peer 9010 se ha configurar para cada sucursal en el router específico de la sucursal. Por ejemplo, el Dial peer 9020 es para la sucursal de Madrid. Este Dial peer también encamina la llamada hacia el Call Manager de Barcelona, que tiene registrados todos los teléfonos IP de la compañía. Dial peer voip 9020 voip Destination-pattern 913439... Voice class codec 3 Session target ipv4:CCall Manager translate-outgoing called 1 Dtmf-realy h245-alphanumeric 5.3.5. Dial peers en las sucursales para telefonía móvil Aunque el presente proyecto se centra en la telefonía fija, es importante hacer hincapié también en la telefonía móvil. De acuerdo con el volumen de tráfico de las sucursales de Madrid y de Barcelona, se ha contratado un primario de voz de telefonía móvil, así como un plan de marcación a Telefónica Móviles en el que todos los teléfonos empiezan por 55 más tres dígitos. En las llamadas entre móviles de la misma compañía y entre móviles internos y externos, la misma Telefónica Móviles se encamina las llamadas 55 a la red de telefonía móvil. Para las llamadas realizadas desde un teléfono fijo IP interno a la empresa con destino cualquier teléfono móvil, ya sea un número externo a la empresa (6T) o un número de una extensión de telefonía móvil de la empresa (55), en un principio el mismo Dial peer seleccionado se encarga de encaminarlo hacia el primario de voz externo de la empresa hacia la red de telefonía móvil. Para encaminar las extensiones hacia el número de telefonía móvil se debe hacer una regla traducción, como se ha detallado anteriormente, mediante el comando translation-rule. Los Dial peers utilizados se detallan a continuación. 6 4 Para la telefonía móvil, los Dial peers son un poco diferentes, pero siguen el mismo esquema. El primer Dial peer POTS saliente se utiliza para las llamadas realizas desde los teléfonos IP fijos de la sucursal a números móviles fuera de la empresa. Nosotros hemos optado por una traducción de la extensión a un número móvil contratado a Telefónica Móviles. Primero se define la translation rule número 5355 que después se aplica, dentro del Dial peer, al número de la extensión. Igualmente, en la definición del Dial peer 6000 se debe especificar un plan de numeración desconocida para ser encaminada por la red de telefonía móvil. Se ha optado por poner prefix 6, puesto que como se ha dicho anteriormente en un Dial peer POTS saliente se elimina la parte principal del patrón de destino “6”. translation-rule 5355 Rule 1 1…% 51 dial-peer voice 6000 pots description MOVILES numbering-type unknown destination-pattern 6T translate-outgoing ougoing calling 5355 port 3/0:15 prefix 6 El segundo Dial peer POTS saliente se utiliza para las llamadas realizadas desde un teléfono IP interno a una extensión de un móvil de la compañía. En primer lugar, se debe hacer la misma traducción del número de la extensión a un número válido de la red de telefonía móvil y después encaminar la llamada al primario de voz de telefonía móvil. dial-peer voice 9010 pots translation-profile outgoing calling 6 destination-pattern 7... port 3/0:15 prefix 7 Las llamadas que van de un teléfono móvil de la empresa a una extensión de los teléfonos IP internos, deben encaminarse hacia el Call Manager. Esto se realiza mediante el comando session target ipv4:CCall Manager, que tiene registrados todos los dispositivo de servicio VoIP y es el responsable del encaminamiento. Del mismo modo que en los casos anteriores, se debe especificar una regla de traducción para que el número llamado, que es un número perteneciente a la red PSTN, sea traducido a una extensión interna que pueda entender el Call Manager. A la vez, dentro de la configuración del Dial peer se utiliza el comando voice-class codec 1 para la negociación de los códecs de los enlaces. Además se asignan un no vad y un dtmf-relay h245-alphanumeric para la negociación de esta clase de llamadas. voice class codec 1 codec preference 1 g711ulaw codec preference 2 g711alaw codec preference 3 g729br8 codec preference 4 g729r8 65 translation-rule 5553 Rule 1 ^531..% 1 Rule 1 ^532..% 2 Rule 1 ^533..% 3 Rule 1 ^534..% 4 Rule 1 ^535..% 5 Rule 1 ^536..% 6 Rule 1 ^537..% 7 Rule 1 ^538..% 8 Rule 1 ^539..% 9 dial-peer voice 9030 voip preference 1 destination-pattern [1-5]... translate-outgoing called 1 voice-class codec 1 session target ipv4:CCall Manager dtmf-relay h245-alphanumeric no vad 5.4. Configuración FAX. Cisco ATA 186 En el presente apartado se detalla la configuración los adaptadores digitales-analógicos dentro de una red VoIP. En nuestro proyecto, aunque no existe ningún teléfono analógico, la red incluye faxes como dispositivos analógicos, configurados mediante un adaptador Cisco ATA 186. Para conectar el fax a la red SCCP se emplea por tanto el Cisco ATA 186, adaptador hardware con entradas Ethernet y RJ11, que permite a teléfonos analógicos (FAX) operar en una red de telefonía IP. SCCP (Skinny Client Control Protocol) es el estándar de Cisco para llamadas en tiempo real sobre IP. Con SCCP, los teléfonos IP de Cisco pueden coexistir en un entorno H.323. Cuando un Cisco Call Manager es unido con un Gatekeeper H.323, un Cisco ATA sobre SCCP interopera con terminales H.323 para establecer, controlar y realizar llamadas. Figura 5.15. Cisco ATA 186 [4]. El Cisco ATA incluye dos modos de servicios de fax, que emplean el codec G.711: 66 • Modo Fax pass-through. Detección de tono (called Station Identification ) con G.711 A-law o G.711 µ-law. • Modo Fax. Cisco ATA es configurado como G.711 El modo de configuración depende de los gateways de red empleados. Dependiendo de la red, puede ser necesario cambiar los valores de configuración por defecto. Para configurar el fax de las sucursales se debe establecer el modo Fax Pass-through en el dispositivo Cisco ATA 186. De esta manera, se obtiene una mayor flexibilidad de códec, por lo que se puede establecer una llamada de voz sobre cualquier códec y renegociar además el códec G.711 para las sesiones de fax. En consecuencia, podremos usar códecs como el G.729 para las llamadas de voz y el G.711 para llamadas de fax. El router se debe programar en modo global: VAL (config)#voice service voip VAL (config)# modem passthrough nse codec g711alaw Este tipo de mensaje, transportado como un Named Signaling Event (NSE) dentro de una cadena RTP, es usado para todas las señalizaciones de eventos de faxes. El Cisco ATA puede inicializar y responder a NSEs y puede funcionar como un gateway de origen o fin. Para utilizar SCCP, el Cisco ATA puede configurarse de dos maneras. • Mediante Cisco Call Manager TFTP Server. Es el método que recomienda Cisco y que permite establecer un fichero de configuración por defecto para todos los Cisco ATA de la red. Cuando se activa el Cisco ATA, automáticamente se descarga este fichero de configuración del servidor TFTP. • Usando configuración manual. Mediante el menú de configuración del teléfono, se debe de establecer una IP y activar el protocolo CDP. También se puede utilizar el navegador Web. Una vez se ha configurado el Cisco ATA mediante el TFTP, se tiene que registrar en el Call Manager. Para ello, hay que ir a la pantalla de Administración del Cisco Call Manager, seleccionar Dispositivos y Teléfono, hacer clic en “nuevo teléfono” y seleccionar la opción Cisco ATA 186. En la siguiente pantalla de configuración se especifica la dirección MAC del Cisco ATA y se selecciona la plantilla por defecto para el ATA 186. Una vez hecho esto se inserta mediante un “update”. A continuación, se especifica el directory number y la partition. Cisco ATA es un adaptador telefónico que puede interactuar con otros dispositivos VoIP mediante el Session Initiation Protocol (SIP), H.323, Media Gateway Control Protocol (MCGP) o SCCP. En un entorno de Cisco Call Manager, se utilizan los protocolos H.323 o SCCP en la comunicación entre el Cisco Call Manager y el ATA 186. En el caso de la configuración de la red de las diferentes sucursales se utiliza el SCCP (Skinny). Antes de realizar la configuración en el Call Manager, se debe asegurar que el cisco ATA 186 recibe la configuración de la red a través del Servidor DHCP. A continuación se ha de cargar la versión SCCP de software. 67 Mediante la página web de configuración del Cisco ATA 186 se puede comprobar la dirección IP asignada por el servidor DHCP, así como la dirección IP del Cisco Call Manager. En la siguiente figura se observa una configuración básica de este dispositivo. Para acceder a dicha página de configuración se introduce la dirección http://dirección IP del ATA 186/dev en el navegador web. La dirección IP se obtiene desde el panel de dispositivo ATA, pulsando 80#. Figura 5.16. Configuración Cisco ATA186. En la configuración del fax de la sucursal de Bilbao, se debe habilitar el servidor DHCP. En este caso, obtendremos la dirección IP 10.34.71.10 y la dirección IP del Cisco Call Manager de Barcelona 10.34.12.1, que a su vez actúa también como servidor TFTP. De este modo, cuando se reinicia el dispositivo ATA 186, se gestiona como un cliente SCCP. Una vez se han introducido las direcciones IP adecuadas, se debe verificar y configurar el Cisco ATA 186 desde la consola del Cisco Call Manager. Para ello, una vez entramos en el Call Manager, buscamos el dispositivo Cisco ATA 186 mediante el nombre de los dispositivos registrados, la dirección IP o la dirección MAC. Esto se podía realizar manualmente, añadiendo en la lista de teléfonos el Cisco ATA 186. Una vez realizado el registro de dicho dispositivo se deben actualizar los campos de la configuración del Cisco ATA. Los campos de configuración más relevantes son los siguientes: • En el campo device pool de ha de introducir “BIL” • En el campo Calling Search Space se ha de introducir “CSS_Bilbao” 68 Una vez se ha configurado el Cisco ATA, se debe introducir en la configuración del directory number la extensión correspondiente al fax de Bilbao, que es la 3500. Para los demás faxes se realiza el mismo procedimiento que para el fax de Bilbao. En la siguiente tabla se presentan los datos de configuración más importantes. Sucursal Direc IP Extensión Location Calling Search Space IP Call Manager BCN 10.34.12.190 1500 BCN CSSBarcelona 10.34.12.1 MAD 10.34.31.190 3000 MAD CSSMadrid 10.34.12.1 VAL 10.34.51.190 5000 VAL CSSValencia 10.34.12.1 SEV 10.34.61.190 6000 SEV CSSSevilla 10.34.12.1 BIL 10.34.71.190 7000 BIL CSSBilbao 10.34.12.1 Tabla 5.15. Plan de Marcación para los faxes. Con los dispositivos Cisco ATA 186 los faxes son tratados como un teléfono IP. De esta forma, se ahorra tiempo en configuraciones y pruebas de comunicaciones para la transmisión de fax. 5.5. Configuración de enlaces a la PSTN 5.5.1. Oficina central de Barcelona y Madrid Para el caso de la central de la compañía, situada como se ha dicho en Barcelona, se utilizan tres primarios de voz: dos para la telefonía tradicional y uno para la telefonía móvil. En el router de la central de Barcelona se deben configurar los primarios de voz E1. Los primarios de voz E1 tienen 30 canales de 64 bytes más 2 canales de 64 bytes de señalización. A continuación se detalla esta configuración, tanto para el primario de voz de telefonía fija, como la de telefonía móvil: isdn switch-type primary-net5 interface Serial1/0:15 description Telefonia Fija no ip address no logging event link-status isdn switch-type primary-net5 isdn incoming-voice voice isdn T310 60000 isdn bchan-number-order ascending no cdp enable controller E1 1/0 69 pri-group timeslots 1-31 voice-port 1/0:15 echo-cancel coverage 32 cptone ES isdn switch-type primary-net5 interface Serial3/0:15 description Telefonia Móvil no ip address ip mroute-cache no logging event link-status isdn switch-type primary-net5 isdn incoming-voice voice isdn sending-complete no fair-queue no cdp enable controller E1 3/0 framing NO-CRC4 pri-group timeslots 1-31 description Vodafone-voz voice-port 3/0:15 cptone ES 5.5.2. Sucursales Valencia, Sevilla y Bilbao Para el caso de las sucursales de Valencia, Sevilla y Bilbao se utilizan 2 BRI para la telefonía fija y una BRI para la telefonía móvil, conforme la cantidad de tráfico cursado. En el router de cada sucursal se le deben configurar los BRI de voz. Los BRI de voz tienen 2 canales de 64 bytes más un canal de 16 bytes de señalización. A continuación se detalla la configuración de un BRI. isdn switch-type basic-net3 interface BRI1/0 no ip address isdn switch-type basic-net3 isdn protocol-emulate network isdn layer1-emulate network isdn incoming-voice voice isdn skipsend-idverify line-power interface BRI1/1 no ip address 70 isdn switch-type basic-net3 isdn protocol-emulate network isdn layer1-emulate network isdn skipsend-idverify line-power voice-port 1/0/0 compand-type a-law cptone ES ! voice-port 1/0/1 compand-type a-law cptone ES 5.6. Cisco IP 7960 con modulo de extensión 7914 (Centralita) Para la función de centralita en las sucursales se ha escogido el teléfono IP 7960 en combinación con el módulo de expansión 7914. Este módulo, añadido al teléfono Cisco IP, proporciona 14 líneas extras o botones programables. Añadiendo un segundo módulo de expansión al teléfono IP se pueden lograr hasta 28 líneas adicionales. Figura 5.18. Teléfono IP 7960 con módulo de extensión 7914. El módulo de expansión incluye dos características. La primera es la pantalla, que muestra los números de teléfonos, números de marcación y servicios de teléfono. En el caso de las centralitas de las sucursales, se indican además las extensiones de líneas para recibir llamadas. La segunda característica son sus 14 botones, cada uno de los cuales corresponde a una línea. La iluminación de cada botón indica el estado de esa línea: • Línea disponible: luz apagada. • Línea en uso por el usuario: luz verde continua. • Línea en uso por otra persona: luz roja continua. • Línea en llamada: luz parpadeante ámbar. • Llamada en espera: luz parpadeante verde. • Llamada en traspaso: luz verde continua. 77 La interfaz que recibe los datos es una cola FIFO estándar (First In First Out) para las dos interfaces Fast Ethernet y Gigabit Ethernet. La interfaz de transmisión tiene cuatro colas con dos umbrales de substracción de paquetes en la interfaz de Gigabit Ethernet. Una de estas colas puede ser configurada como una cola con prioridad. La interfaz Fast Ethernet tiene otras cuatros colas pero no es posible configurar umbrales. El algoritmo de programación de las colas del switch se basa en el WRR (Weighted Round Robin). Este algoritmo transfiere los paquetes que esperan en la cola de prioridad 4 antes de servir los de las otras colas [5]. El switch 3550, en función de la prioridad de las colas, asigna a cada paquete un valor de CoS por defecto, según se indica en la tabla 6.3 [4]. Número de Cola Valor CoS 4 6,7 3 4,5 2 2,3 1 0,1 Tabla 6.3. Asignación cola-CoS. La cola cuatro es la cola con prioridad. Los paquetes entrantes de voz RTP desde los teléfonos IP, marcados con CoS 5, deberían ser recibidos por la cola 4. Los paquetes de control de voz IP, marcados con el valor CoS 3, deberían ser recibidos por la cola 2. En la tabla 6.4 se recogen estos cambios de configuración basados en los valores CoS del switch Catalyst 3550. Número de Cola Valor CoS 4 (cola prioritaria) 5 3 3,4,5,6 2 1,2 1 0 Tabla 6.4. Prioridad de colas. A continuación, se indican las configuraciones del swtich 3550 y del router 3745 para llevar a cabo esta asignación de prioridad de valores CoS siguiendo los pasos descritos por Cisco[4]. Configuración del switch Catalyst 3550 Primero, se ha de habilitar QoS globalmente en el switch. BCNS3550(config)#mls qos Segundo, se debe modificar el mapeo CoS a DSCP. BCNS3550(config)#mls qos map cos-dscp 0 8 16 26 34 46 48 56 78 Tercero, se debe modificar el mapeo DSCP a CoS. BCNS3550(config)#mls qos map dscp-cos 0 8 16 26 34 46 48 56 Cuarto, se debe activar la prioridad de encolamiento en la interfaz que conecta el teléfono IP. BCNS3550(config)#interface range fastehertnet 0/2 - 24 BCNS3550(config-if-range)#priority-queue out Quinto, se debe colocar el tráfico con el valor CoS 5 en la cola con prioridad, es decir en la cola 4, y el tráfico con valor CoS 3 dentro de la cola 3. Se debe notar que por defecto los valores CoS 6 y 7 son colocados en la cola 4 y los paquetes con valores de CoS 4 son colocados en la cola 3. BCNS3550(config)#interface range fastethernet 0/2 – 24 BCNS3550(config)#no shutdown BCNS3550(config)#duplex auto BCNS3550(config-if-range)#wrr-queue cos-map 1 0 BCNS3550(config-if-range)#wrr-queue cos-map 2 1 2 BCNS3550(config-if-range)#wrr-queue cos-map 3 3 4 6 7 Los paquetes con CoS 5 se mapean en la cola 4 BCNS3550(config-if-range)#wrr-queue cos-map 4 5 Sexto, se ha de habilitar las características QoS en los puertos del switch que conecta los teléfonos IP. BCNS3550(config)#interface range fastethernet 0/2 –24 BCNS3550(config-if-range)#mls qos trust cos A continuación se crean la VLAN para voz y la VLAN para datos. BCNS3550(config-if-range)#switchport voice vlan 21 BCNS3550(config-if-range)#switchport access vlan 211 Se desconfía dando valor 0 CoS al puerto configurado para el PC. BCNS3550(config-if-range)#switchport priority extend cos 0 BCNS3550(config-if-range)#spanning-tree portfast Séptimo, se habilita la característica QoS para uplink, para conectarse con el router. Todo el tráfico entrante debe tener los valores correctos DSCP. El router WAN se conecta al puerto Fast Ethernet 0/1 del switch Catalyst 3550. BCNS3550(config)# interface fastethernet 0/1 BCNS3550(config)#no shutdown BCNS3550(config)#priority-queue out BCNS3550(config-if)#wrr-queue cos map 1 0 BCNS3550(config-if)#wrr-queue cos map 2 1 2 BCNS3550(config-if)#wrr-queue cos map 3 3 4 6 7 BCNS3550(config-if)#wrr-queue cos map 4 5 Por último, se confía en la marcación dscp del router. BCNS3550(config-if)#mls qos trust dscp 79 BCNS3550(config-if)#switch port mode trunk BCNS3550(config-if)#switch port trunk encapsulation dot1q Configuración del Router 3745 del puerto Ethernet que conecta al switch del teléfono IP Primero, se añaden las VLAN a la base de datos BCNR3745#vlan database BCNR3745(vlan)#vlan 100 name BCN-DATAVLAN BCNR3745(vlan)#vlan 50 name BCN-VOICELAN Segundo, se selecciona la interfaz del router que conecta el teléfono IP BCNR3745(config)#interface FastEthernet0/1-16 Tercero, se debe encapsular con el formato 802.1q. Esta encapsulación sirve para soportar tráfico marcado o no marcado. BCNR3745(config-if)#switchport trunk encapsulation dot1q Cuarto, se configura el tráfico de PC, que es un tráfico no marcado en su correspondiente VLAN. BCNR3745(config-if)#switchport trunk native vlan 50 Quinto, se configura el puerto como un trunk port. BCNR3745(config-if)#swichport mode trunk Sexto, se configura la VLAN de voz. BCNR3745(config-if)#switchport voice vlan 100 Séptimo, se ignora la prioridad recibida desde un PC o cualquier dispositivo añadido al puerto del teléfono IP. BCNR3745(config-if)#switchport priority extend cos 0 Finalmente, se deshabilita el spanning tree. BCNR3745(config-if)#spanning-tree portfast 6.6. WAN QoS en Sitios Remotos El tráfico VoIP se divide en dos componentes: el tráfico portador de voz (RTP) y el tráfico de señalización o control. El tráfico de control transporta la señalización requerida para el establecimiento de llamada, desconexión y “reporting”. El tráfico portador de voz es el tráfico de voz durante una conversación. Aunque el tráfico de control VoIP puede basarse en UDP, normalmente se transmite sobre TCP. La portadora VoIP es siempre UDP. El tráfico de la portadora de VoIP se compone de muchos paquetes UDP, cada uno de los cuales transporta un fragmento vital de la conversación de voz. Estos paquetes deben ser administrados, por tanto, con una mínima probabilidad de pérdida o espera. El tráfico de control no es tan sensible a retrasos como la portadora de voz. Es por esto que el tratamiento 80 de las colas debe seguir una política de prioridades. Por último, debe recordarse que el tráfico de control transportado por TCP puede ser reenviado, mientras que el tráfico de la portadora de voz ha de pasar por mecanismos estrictos de colas. Debido a que cada tipo de tráfico VoIP requiere diferentes políticas, los elementos de la red deben disponer de un método de identificación y separación de flujos. Esto puede lograrse de modo eficiente combinando una prioridad de encolamiento (PQ) con una programación basada en Class-Based Weightd Fair Queueing (CBWFQ) para garantizar el ancho de banda en el tráfico de voz. La combinación de PQ y CBWFQ se conoce como LLQ [5]. La tabla 6.5 muestra la clasificación de tráfico usado para diferentes flujos de datos. El tráfico portador de voz es el que tiene una prioridad más alta. Nombre de Clase Valor DSCP Tráfico portador VoIP (RTP) EF (46) Tráfico de Control VoIP AF31 (26) Datos Criticos AF 21 (18) Otros Datos 0 Tabla 6.5. Valores DSCP. La aplicación de las políticas QoS requieren los siguientes procedimientos de configuración: • Class map: define clases de tráfico según criterios. • Policy map: define políticas QoS para el tráfico definido en el class map. • Service map: añade una política a una interfaz específica en el router. El diseño de QoS en los routers WAN implica tres tareas: • Mapeos DSCP a CoS. • Mapeos CoS a DSCP en routers remotos. • Configuración de colas en las interfaces WAN. 6.7. Mapeos DSCP a CoS Las conexiones entre los routers y los switches se realizan a través de enlaces 802.1q. Los routers son los responsables del mapeo de valores DSCP a CoS antes de que estos pasen a los switches de capa 2. El mapeo de DSCP a CoS se basa en la marcación de clases. Esto permite que los switches de capa 2 prioricen el tráfico adecuadamente. Con los switches Catalyst 3550 que están en la red este mapeo manual de valores DSCP a CoS no es necesario, ya que este tipo de switches puede confiar en valores DSCP de forma automática y por defecto. A continuación, se muestra una clasificación manual que examina los valores de capa 3 DSCP. Los paquetes de voz tienen un valor DSCP de EF, la señalización de AF31, y datos críticos de AF21 81 Class-map mach-all VOICE Match ip dscp ef Class-map match-all VOICE-CONTROL Match ip dscp AF31 Class-map match-all DATA Match ip dscp AF21 Después de clasificar el tráfico, se usa el comando policy map para establecer los valores CoS, como muestra el siguiente recuadro. Cualquier paquete con valores DSCP de EF será marcado con CoS de 5. Los paquetes marcados con DSCP de AF31 serán marcados con CoS de 3. Y los paquetes de datos críticos con valores de AF21 se marcarán con CoS de 2. Policy map DSCP2COS-VOICE Class VOICE Set cos 5 Class VOICE-CONTROL Set cos 3 Policy map DSCP2COS-DATA Class DATA Set cos 0 Class map y Policy map no son efectivos hasta que son asignados a una subinterfaz de voz y datos, como se muestra a continuación. Interface fastethernet 0/0.21 Service-policy output DSCP2COS-VOICE Interace fastethernet 0.0.211 Service-policy output DSCP2COS-DATA 6.8. Mapeos Cos-DSCP en Routers Remotos Los routers WAN deben establecer valores DSCP para paquetes entrantes desde los switches antes de enviarlos al enlace WAN. La clasificación de los paquetes utilizada es la misma de la tabla 6.5. En el siguiente ejemplo se muestra la clasificación de los paquetes a partir de los valores CoS de capa 2. Los paquetes de voz entrantes desde el teléfono IP tienen valor 5, y los paquetes de señalización tienen valor de CoS igual a 3. Los paquetes de datos críticos son mapeados con una access list, dado que no pueden ser mapeados con valores CoS de 2. De este modo, se usa una extended access list para identificar este tipo de tráfico. Class-map match-all COS5 Match cos 5 Class-map match-all COS3 Match cos 3 82 Class-map match-all COS2 Match access-group 101 Access list 101 permit tcp any host x.x.x.x eq 80 Access list 101 permit tcp x.x.x.x 0.0.0.255 host x.x.x.x eq 80 Después de clasificar el tráfico, se usa una policy map para establecer los valores DSCP. Policy map COSDSCP-VOICE Class EF Set dscp COS5 Class AF31 Set dscp COS3 Policy map COS2DSCP-DATA Class COS0 Set dscp 0 Al final de todo se asocia la policy map para voz y datos a una subinterfaz. Interface fastethernet 0/0.21 Service-policy input COSDSCP-VOICE Interface fastethernet 0/0.211 Service-policy input COSDSCP-DATA 6.9. Configuración de las colas en la interfaz WAN En el router, el tráfico de voz debe estar asignado a una LLQ, y el tráfico de control de voz necesita un mínimo ancho de banda a través de mecanismos CBWFQ. En este punto, en primer lugar debe calcularse el ancho de banda necesario para garantizar llamadas de voz y fax. Si utilizamos el códec G.729, se requieren aproximadamente 30 Kbps por llamada. Para llamadas de fax se usa el códec G.711, que consume aproximadamente 90 Kbps. En la tabla 6.6 se muestran los cálculos de ancho de banda para las sucursales de Barcelona, Madrid, Valencia y Sevilla. El ancho de banda para el control de tráfico depende del número de teléfonos IP de las sucursales. En esta tabla también se muestra el ancho de banda reservado para los datos. Criterio Madrid Valencia Sevilla Bilbao Número de teléfonos 100 10 10 10 Ancho de banda del enlace de voz 1Mbps 256 Kbps 256 Kbps 256 Kbps Número de llamadas de voz simultáneas 35 5 5 5 83 Criterio Madrid Valencia Sevilla Bilbao Número de llamadas de faxes 1 1 1 1 Codec usado para llamadas de voz G.729 G.729 G.729 G.729 Codec usado para llamadas de fax G.711 G.711 G.711 G.711 Ancho de banda para llamadas de voz (llamadas de voz simultáneas x 21.2 por llamada) 742 Kbps 106 Kbps 106 Kbps 106 Kbps Ancho de banda para llamadas de fax (una llamada de fax por 85 kps por llamada) 85 Kbps 85 Kbps 85 Kbps 85 Kbps Total de ancho de banda de llamadas de voz y de llamadas de fax 827 Kbps 191 Kbps 191 Kbps 191 Kbps Control de voz 10 Kbps 8 Kbps 8 Kbps 8 Kbps Ancho de banda de datos 1,5 Mbps 256 Kbps 256 Kbps 256 Kbps Ancho de banda del enlace total 2,5 Mbps 512 Kbps 512 Kbps 512 Kbps Tabla 6.6. Cálculo del ancho de banda. 6.10. Diseño de QoS en los routers centrales Las configuraciones de los switches habilitan QoS, clasifican y marcan los paquetes de portadora de voz , de control de voz, y los datos críticos. De este modo, los routers principales o de contorno han de clasificar los paquetes recibidos según los valores DSCP y a continuación, han de proporcionar prioridad mediante LLQ. En el recuadro siguiente, se muestra una clasificación de tráfico según el valor DSCP mapeado por el switch, que a través del teléfono IP ha obtenido los valores CoS de los paquetes portadores de voz, paquetes de control y datos del PC. En el ejemplo, el ancho de banda se clasifica según la clase. Esta función no la desempeña realmente el router de contorno, sino que es asumida por el router del proveedor de servicios (en este caso enlaces VPN MPLS para conectar las diferentes sucursales). La empresa contratada, en la actualidad Telefónica, se ocupa de proporcionar prioridad a los paquetes de voz sobre los paquetes de control de voz y de datos. MCQ es el sistema que Cisco implementa para configurar QoS. Este método se divide en tres partes, como se ha dicho con anterioridad, para obtener calidad de Servicio para IP en la LAN [4]. • Class map: define qué tráfico es interesante. • Policy map: aplica QoS al tráfico clasificado anteriormente. • Service policy: aplica el policy map a una interfaz. ! La clase map VOICE mapea todos los paquetes con el valor DSCP EF class map match-all VOICE 84 match ip dscp ef ! La clase map VOICE-CONTROL mapea todos los paquetes con el valor DSCP AF31 class map match-all VOICE-CONTROL match ip dscp af31 !La clase map DATA mapea todos los paquetes con el valor DSCP af21 class map match-all DATA match dscp 0 !Aplica una política de prioridad y ancho de banda para las clases de tráfico mapeadas policy map SIAG class VOICE priority 50 class VOICE-CONTROL bandwidth 10 class DATA bandwidth 40 !Aplica la política a lainterface interfaceX service-policy output SIAG 6.11. Configuración Class Map El método MCQ clasifica en primer lugar el tráfico en base a su importancia o interés. Por defecto, el comando class map contiene el parámetro all (que mapea todo los paquetes), y se asocia a un nombre, por ejemplo voice: Class map match-all voice Dentro de la configuración class map (config-map), se aplica el comando match para definir el tráfico que ha de ser mapeado sobre esta clasificación, según se observa en la tabla 6.7. Tipo de Match Función Sintaxis Access-group Combina una access list por su nombre o número Access-group {named acl-name | acl-number 1-2699} IP Combina paquetes específicos con valores DSCP o IP Precedente Ip {dscp valor | precedente valor | rtp valor} Mpls Combina paquetes con valores específicos de EXP Mpsl experimental 0-7 Tabla 6.7. Lista de parámetros del comando match [4]. En el siguiente ejemplo se clasifica el tráfico de valor MPLS exp 5 y se le asigna un 40% del ancho de banda: 85 Class-map match all voice Match mpls experimental 5 Policy-map llq Class voice Priority percent 40 En este otro ejemplo, el tráfico se clasifica según la interfaz de procedencia: Class-map match all voice Match mpls experimental 5 Match input-interface fastethernet 0/1 Por último, se define una clase por defecto para todo el tráfico restante, mediante el comando match any. 6.12. Configuración de Policy Map Después de definir las clases de tráfico, se deben aplicar los parámetros de calidad de servicio a cada clase definida. En la tabla 6.8 se muestran los parámetros principales del comando policy-map Policy map Función Sintaxis Bandwidth Esto es CBWFQ y configura la cantidad de ancho de banda asignado a esta clase Bandwidth, percent, y remaining percent Priority Configura la cantidad de ancho de banda, esto es LLQ Priority, percent Set Se establece valores DSCP,Ip Precedence o EXP a un paquete Set { ip { dscp | precedente} | { mpls experimental} Tabla 6.8. Policy Map. En el router de contorno de la red MPLS se hace una división de tres clases de tráfico: la portadora de voz, el control de VoIP y los datos. Class-map match-all voice Match mpls experimental 5 Class-map match-all control Match mpls experimental 3 Policy-map SIAG Class voice Priority percent 50 Class control Priority percent 10 Class class-default Priority percent 40 Por último, se debe aplicar esta política a una interfaz. Para ello, debe introducirse el siguiente comando dentro de la configuración de la interfaz: Service-policy output o input. 86 6.13. Resumen QoS en las comunicaciones Haciendo un resumen, la calidad de servicio QoS de la red expuesta en este proyecto se divide en los siguientes pasos. 1. Los puertos del teléfono IP dividen el tráfico en 3 clases y marcan los bits de la cabecera IP como: • Portadora de voz (IP Precedente 5, mapeado a DSCP 40 EF, y CoS 5) • Control de voz (IP Precedente 3, mapeado a DSCP 24 CS3, y CoS 3) • Tráfico de datos del PC (IP Precedente 0, mapeado a DSCP 0, y CoS 0) 2. Al switch Catalyst 3550 llegan los tres tipos de tráfico. El switch clasifica este tráfico en tres clases y le asigna una política de prioridades de colas en la LAN: • Voice • Control • Data 3. El router 3745 de contorno de la red de Océ España, mapea como el switch 3550 en tres clases para asignar prioridades de cola. • Voice • Control • Data 4. Por último, en los routers de contorno de la red del proveedor de servicios MPLS, se mapean los valores DSCP a valores EXP MPLS y se asigna el ancho de banda con prioridad de del 50% para la voz, el 10% para el control y el 40% para los datos [6]. 93 Part Descripción Candidad Precio unitario (€) WS-C3550-24PWRSMI 24-10/100 inline power + 2 GBIC ports: SMI 7 1.538,72 CAB-ACE Power Cord Europe 7 0 WS-G5483= 1000BASE-T GBIC 10 173,9 WS-G5486 1000BASE-LX/LH long haul GBIC (singlemode or multimode) 2 438,06 CISCO3745 3700 Series, 4-Slot, Dual FE, Multiservice Access Router 1 5.283,13 PWR-3745-AC= AC Power Supply Spare for the Cisco 3745 1 352,2 PWR-3745-AC/2 Redundant AC System Power Supply for the Cisco 3745 1 352,2 CAB-ACE Power Cord Europe 2 0 S374CP-12305 Cisco 3745 Series IOS IP PLUS 1 396,23 FL-SRST-240 Feat Lic Survivable Remote Site Telephony up to 240 phones 1 2.113,25 NM-HDV-2E1-60 Dual-Port 60 Channel E1 Voice/Fax Network Module 2 5.283,13 NM-HDV High Density Voice/Fax Network Module (Single VIC Slot) 1 0 PVDM-12 12-Channel Packet Voice/Fax DSP Module 2 0 WIC-1B-S/T 1-Port ISDN WAN Interface Card(dial and leased line) 1 222,18 Tabla 7.8. Costes de la electrónica LAN WAN en Madrid. 94 Part Descripción Candidad Precio unitario (€) WS-C3550-24PWRSMI 24-10/100 inline power + 2 GBIC ports: SMI 3 1.538,72 CAB-ACE Power Cord Europe 3 0 CISCO3745 3700 Series, 4-Slot, Dual FE, Multiservice Access Router 3 5.283,13 PWR-3745-AC= AC Power Supply Spare for the Cisco 3745 3 352,2 PWR-3745-AC/2 Redundant AC System Power Supply for the Cisco 3745 3 352,2 CAB-ACE Power Cord Europe 6 0 S374CP-12305 Cisco 3745 Series IOS IP PLUS 3 396,23 NM-HDA-4FXS High density analog voice/fax network module with 4 FXS 3 792,48 EM-HDA-4FXO 4-port voice/fax expansion module - FXO 6 440,26 WIC-1B-S/T 1-Port ISDN WAN Interface Card(dial and leased line) 3 222,18 AIM-VOICE-30 30 Channel Voice/Fax AIM 3 0 FL-SRST-MEDIUM Feat Lic Survivable Remote Site Telephony up to 48 phones 3 0 Tabla 7.9. Costes de la electrónica LAN WAN en el resto de delegaciones. Part Descripción Cantidad Precio unitario (€) CALL MANAGER3.3 Call Manager 3.3 Top Level Part Number 2 0 MCS-7825H-2.2EVV1 HW Only MCS 7825H-2266 With P4 2.266,1GB RAM, 40GB HD 2 2.641,56 CAB-ACE Power Cord Europe 2 0 SW-CCM-3.3-7825= Call Manager 3.3 - MCS-7825H-2266 with 1000 Svr Usr Lic 2 2.639,37 Tabla 7.10. Costes del Call Manager. 95 8. Conclusiones y líneas futuras. La implementación del servicio de telefonía IP en Océ España ha comportado un salto tecnológico a la vez que un ahorro en costes y mejoras de servicios. El ahorro de coste es uno de los motivos principales por los que Océ España decidió implantar este servicio, ya que con una infraestructura centralizada compuesta por una sede central en Barcelona y cuatro sucursales repartidas por Madrid, Valencia, Sevilla y Bilbao, el ahorro en el servicio de telefonía es importante tanto para las llamadas entre sucursales como para las llamadas interprovinciales al exterior. Cualquier empleado situado en la sucursal de Barcelona puede llamar un número indefinido de veces y durante el tiempo necesario a cualquier sucursal, sin que la factura telefónica se vea incrementada por ello. La red MPLS conlleva mecanismos de calidad de servicio que garantizan que las llamadas sean cursadas correctamente sin ninguna degradación de la calidad. Por otro lado, las llamadas interprovinciales son las llamadas que más gastos producen en la cuenta de la empresa. En telefonía IP, cuando un empleado de una sucursal A llama a un teléfono público situado en la misma provincia que otra sucursal B, en vez de cursar la llamada a través de la centralita de A, como se ha hecho tradicionalmente, esta llamada se encamina a través de la red MPLS y se cursa finalmente a través del gateway de voz de la sucursal 2. De este modo, la llamada interprovincial se convierte en una llamada local, con el subsiguiente recorte de la factura telefónica. En el capítulo anterior se ha visto que la inversión se ha de amortizar en menos de tres años. La telefonía IP conlleva mejoras de servicios como la disponibilidad de un directorio o agenda corporativa en el propio teléfono y la facilidad para el departamento de TI de administrar las altas, bajas y modificaciones de los usuarios (prácticamente se trata de un sistema de plug & play). Existen otra serie de mejoras que no han sido detalladas en este proyecto y que pretenden ser explotadas con posterioridad. A continuación, se incluye un breve listado de estos servicios y mejoras aplicables en un futuro próximo: • Servicios de derechos de usuarios dentro de las llamadas: se puede restringir a un empleado la posibilidad de realizar llamadas a determinados números de teléfono. • Cisco Unified Messaging Cisco Unity: solución de mensajería que entrega mensajes como e-mail, voz y fax mediante Micrososft Exchage, que es el sistema de correo utilizado por Océ España. Cisco Unity está integrado en Cisco Call Manager y se comunica con este mediante SCCP. Con este sistema pueden mandarse mensajes a un buzón de correo cuando el teléfono de la persona indicada no se encuentra disponible o comunica. • Cisco Customer Response Solution: combina CIPT y la solución Contact Center, para una mejor administración y operativa en el desarrollo de las funciones del Call Center, con un entorno más cómodo y flujos de trabajo más especificados que incluyen respuestas automáticas. • Extensión Mobility: permite que un usuario se identifique ante un teléfono mediante un código prefijado. La plantilla correspondiente a este usuario se carga automáticamente al teléfono y mejora así la disponibilidad del usuario. 96 • Reporting. El Call Manager puede emitir informes de tráfico y consumo facilitando el control de la red al departamento de TI. • Desarrollo de aplicaciones a medida: Call Manager permite lanzar scripts en las llamadas y mostrar información relevante de los clientes antes de aceptar la llamada. En un futuro próximo se prevé la ampliación del servicio de telefonía de Océ España a Océ Portugal. Dado que la inversión en Call Manager ya ha sido realizada, es posible extender el ámbito de actuación hasta los 1000 terminales (licencia actual) incluyendo los usuarios de Océ Portugal. Este nuevo proyecto comportaría ventajas en los mismos conceptos que el proyecto actual pero de un importe superior, ya que las llamadas internacionales actuales se podrían encaminar a través de la WAN convirtiéndose en llamadas locales. Igualmente podría abrirse un nuevo escenario de centralización de varios departamentos (Call Center, cobros, facturación, etc.) dado que las comunicaciones con los clientes podrán realizarse desde cualquier sucursal. 97 Bibliografía [1] ALEXANDER, J. and PEARCE, C. (2005). Cisco Call Manager Fundamentals, 2 nd Edition. 2 nd ed. San Jose, USA . Cisco Press. ISBN: 978-1-58705-192-0 [2] ALWAYN, V. (2001). Advanced MPLS Design and Implementation. 1 st ed. San Jose, USA. Cisco Press. ISBN: 978-1-58705-020-6. [3] DAVIDSON, J. and PETERS, J. (2006). Voice over IP Fundamentals, 2 nd Edition. 2 nd ed. San Jose, USA . Cisco Press. ISBN: 978-1-58705-257-6. [4] KAZA, R. and ASADULLAH, S. (2005). Cisco IP Telephony: Planning, Design, Implementation, Operation, and Optimization. 1 st ed. San Jose, USA. Cisco Press. ISBN: 9781-58705-157-9. [5] ALVAREZ, S. (2006). QoS for IP/MPLS Networks. 1 st ed. San Jose, USA. Cisco Press. ISBN: 978-1-58705-233-0. [6] PEPELNJAK, I. and GUICHARD, Jim. (2000). MPLS and VPN Arquitectures.1 st ed. San Jose, USA . Cisco Press. ISBN: 978-1-58705-002-2