Fundamentos de VoIP con Tecnología Cisco

GRUPO ACADEMIA POSTAL

Fundamentos de VoIP con Tecnología Cisco

Centro de Nuevas Tecnologías de Galicia
29 de noviembre de 2012


Presentación
• Ponente: Francisco Javier Nóvoa (Grupo Academia Postal)
– En twitter: @fjnovoa_
– http://cisconetworkingspain.blogspot.com

• Ciclo de Seminarios de Voz sobre IP con Tecnología Cisco
– Fundamentos de VoIP con Tecnología Cisco
(29 de noviembre de 2012)

– Despliegue de VoIP en entornos corporativos con Tecnología Cisco
(Primer trimestre de 2013)

– Seguridad en entornos VoIP
(Segundo trimestre de 2013)


Objetivos
• Explicar en el funcionamiento de la tecnología “Telefonía IP”.
– Se comenzará con una explicación de los fundamentos de esta tecnología, haciendo
hincapié en las características de los codecs más utilizados así como haciendo
referencia a los protocolos de señalización más habituales.

• Se mostrará un pequeño escenario en el que se abordarán los conceptos básicos de
configuración de una implementación de VoIP utilizando tecnología Cisco.
– Se mostrará como configurar extensiones, teléfonos, usuarios y la interconexión con la
red telefónica pública, bien mediante telefonía tradicional o mediante telefonía IP.

• La duración de la conferencia será de tres horas.


Parte I
Telefonía Tradicional vs. Telefonía Empaquetada

Conexiones Analógicas y Conexiones Digitales
Red Telefónica
VoIP


Conexiones Analógicas y Conexiones Digitales


Conexiones Analógicas
• Teléfono Analógico + Líneas de transmisión analógicas:
– Información analógica: Corriente Eléctrica
• Propiedades: Voltaje, frecuencia, Intensidad, carga
– Señalización: Tono, nºs marcados, señal de ocupado, etc.
– Circuito Eléctrico:
• Par de hilos  Circuito
– 1 hilo de tierra o positivo (tip)
– 1 hilo conectado a la batería eléctrica, negativo (ring)
– Transmiten los mensajes de señalización, la voz y alimentan eléctricamente al
teléfono analógico
• El circuito está abierto (no operativo) cuando el teléfono está colgado (on-hook)
• Cuando se descuelga el teléfono (off-hook), se conectan los dos hilos formando el
circuito eléctrico:
– Corriente eléctrica de -48V desde el operador al teléfono
– Distintos tipos de señalización: Loop – Start, Ground – Start


Conexiones digitales
• Problemas con la telefonía analógica:
– Degradación de la señal a grandes distancias  Repetidores/Amplificadores
• Regeneran tanto la señal original como el ruido
– El incremento del nº de pares de conexión: Cada teléfono requiere un par telefónico

• Solución: Conexión Digital
– Se utilizan códigos numéricos en lugar de señales eléctricas para transmitir la
información de voz
– Digitalización: Proceso que convierte la señal de voz analógica en una secuencia de
códigos numéricos, que pueden volver a ser convertidos en voz
• Aplicación de “Codecs” en capa física
• Elimina los problemas de degradación y ruido
• Elimina los problemas generados por la gran cantidad de pares telefónicos
necesarios con la telefonía analógica


Conexiones digitales II
• Multiplexación Temporal (TDM): Permite la transmisión simultánea de múltiples
conversaciones por un cable telefónico de dos pares (4 hilos)
– Se digitalizan las conversaciones
– Se divide el tiempo de uso del medio de transmisión en slots de tiempo, que se asignan
a cada una de las conversaciones que se van a transmitir de forma simultánea
• Los servicios de transmisión de voz digital se fundamentan en canales de 64 kbps
denominados ”Digital Signal 0” (DS0)
– Servicio E1  30 canales DS0
• Desafío: Señalización de llamada
– Transmisión analógica: La señalización se lleva a cabo (de modo “in-line”) a través de
señales eléctricas transmitidas por el propio par
– Transmisión digital  No puede haber señalización analógica
• Múltiples canales DS0 sobre un solo medio de transmisión
• Señalización a través de circuitos digitales:
– Common Channel Signaling (CCS)


Conexiones digitales III
• Common Channel Signaling (CCS): La información se transmite utilizando un canal
separado, dedicado a transmitir la información de señalización de todos los canales que se
transmiten por dicho medio (modo “out-of-band”).
• Dedica un canal DS0 del enlace E1 para enviar la información de señalización
– E1: 30 Canales DS= para voz + 1 Canal DS0 para señalización (+1 de “framing”)
• El canal de señalización es el 17
• Con este método es necesario un protocolo de señalización que sea capaz de transmitir la
información de señalización de cada canal: El más habitual Q.931
• Es el mecanismo de señalización más habitual:
– Más flexible
– Más ancho de banda para los canales DS0 de voz (habitualmente denominados
Canales B o Canales “Bearer”)
– Mayor seguridad
– Facilita la integración de centralitas de cliente digitales y permite que estas utilicen
mensajes propietarios


Red Telefónica


Red Telefónica
• Red mundial que permite fácilmente establecer una conexión, hablar y desconectarse
• Componentes:
– Teléfono Analógico: Convierte señales de audio en señales eléctricas
– Bucle local: Conecta al cliente con el ISP
– Central de Conmutación del Proveedor: Proporciona los servicios a los clientes:
señalización de llamada, manejo de dígitos, enrutamiento de llamada, configuración y
desconexión.
– Enlace troncal: Proporciona conexión entre las centrales de conmutación, que puede
ser públicas o privadas (centralitas)
– Central de Conmutación Privada (Centralita o PBX): Permite desplegar una
infraestructura de telefonía privada
• Llamadas internas gratuitas
• Mejor gestión de las conexiones con la PSTN
• Funcionalidades avanzadas
– Teléfonos Digitales: Suelen conectarse a Centralitas


Red Telefónica II
• Componentes:


Centralitas de Conmutación Privadas (PBX)
• Sistemas que permiten gestionar cientos o miles de teléfonos
– Reducción de líneas contratadas  Ahorro económico
– Otras operaciones de valor añadido: llamadas internas, desvío de llamadas, etc.
– Se conectan a la central de conmutación pública a través de enlaces troncales

• Componentes: Tarjetas
– Tarjetas de línea: Comunican los teléfonos con la centralita
– Tarjetas troncales: Comunica la centralita con la RTC o con otra centralita
– Control: Proporciona inteligencia a la centralita. Lleva a cabo las tareas de
configuración de llamada, enrutamiento y gestión

• Altísima fiabilidad


Conexiones a y entre elementos de la Red Telefónica
• Líneas analógicas
• Líneas digitales:
– Enlaces Primarios: T1 y E1

• RTC = Interconexión de todos los proveedores de servicios de telefonía, a nivel global
– Protocolo de señalización común: SS7
• Es un método de señalización “out-of-band” (estilo CCS): Configuración de
llamadas, Enrutamiento, Facturación, Mensajes informativos
• Cuando un usuario hace una llamada, primero la central de conmutación recibe la
llamada, hace una búsqueda SS7 para localizar el nº de destino. Una vez
encontrado el destino, SS7 es responsable del enrutamiento de la llamada a través
de la red de voz hacia el destino y proporcionar la señalización de información (por
ejemplo, el ring back) hacia el dispositivo origen.
• El cliente no tiene interacción directa con el protocolo SS7


Plan de Numeración en la Red Telefónica
• Las redes de voz usan planes de numeración para organizar y localizar teléfonos por todo
el mundo
• Las organizaciones pueden gestionar su propio espacio de numeración (algo que sería
análogo a las direcciones IP privadas)
• Sin embargo, cuando se conecta un dispositivo a la RTC se debe usar una dirección
estándar E.164.
– E.164 es un plan de numeración internacional creado por la ITU
– Cada plan de numeración E.164 contiene los siguientes componentes (Máx 15 dígitos):
• Código de país
• Código de destino nacional
• Número de suscriptor
– Ejemplo: Numeración en España:
• Código de país: 034
• Código de destino nacional: 981
• Número de cliente: 148471


Voz sobre IP


VoIP
• Voz Analógica vs. Voz Digital (RDSI) = Telefonía tradicional
• VoIP: Consiste en transmitir la voz digitalizada en paquetes IP
• Elementos clave en VoIP:
– QoS
– Codificación-Decodificación
– Seguridad


VoIP II
• Ventajas
– En una localización: Red de Datos + Red Voz  Red Convergente
– Reducción de costes en las comunicaciones: Realización de llamadas a través de
redes de datos  Menos líneas de teléfono y menores costes de llamada
– Integridad y consistencia de la red de telefonía: Debido a que las redes de la
organización están conectadas, se pueden llevar a cabo llamadas internas entre
oficinas remotas sin utilizar la RTC
– Facilidad de Mantenimiento: Coste de un cambio de teléfono o de configuración de
teléfono cuesta en telefonía tradicional entre 40 y 200 €. Este coste es prácticamente 0
en ToIP
– Softphones
– Integración con el correo electrónico, buzones de voz y fax
– Mejora de la productividad
– Comunicaciones con funcionalidades avanzadas: Integración de voz, vídeo y datos
– Estándares abiertos y compatibles


Conversión de las Señales de Voz en Paquetes IP
• Teorema de Nyquist  Digitalización de señales analógicas (Por ejemplo: Voz)
– Para que una señal analógica pueda ser reconstruida, después de haber sido
digitalizada, debe muestrearse, como mínimo, al doble de la mayor de las frecuencias
de la señal analógica original.
– Frecuencias que puede captar el oído humano: 20 – 20.000 Hz
– Frecuencias de voz en conversación: 200 – 9.000 Hz
– Frecuencias transmitidas por teléfono: 300 -3.400 Hz
– Frecuencias de aplicación del teorema de Nyquist a la
digitalización de voz por teléfono: 300 - 4.000 Hz
• Para la digitalización de señales de voz, se utiliza un
muestreo de 8.000 muestras por segundo, donde cada
muestra es un valor numérico.
• Originalmente, el tamaño de cada muestra era de 8 bits, lo
que permite representar información entre -127 y 127
– Códec G.711


Conversión de las Señales de Voz en Paquetes IP
• El proceso de asociar el valor de cada muestra tomada a un valor discreto, entre -127 y 127
en este caso, se denomina “cuantificación”
– Para mejorar la precisión de este proceso, los valores de amplitud más habituales se
asocian con valores de cuantificación que ocupan un espacio más pequeño; mientras
que los menos habituales se asocian con valores de cuantificación más amplios.
• Si se toman 8.000 muestras por segundo de 8 bits  64.000 bps para digitalizar una
llamada analógica
– Ancho de banda de los canales B en RDSI
– Códec G.711


Compresión: Códecs avanzados
• Se puede penalizar la calidad de la voz
• Para medir la calidad de la voz, se utiliza una medida subjetiva denominada MOS (Mean
Opinion Score):
• Escala entre 0 y 5 basadas en la media de las opiniones subjetivas de los usuarios

Codec Ancho de Banda MOS

G.711 64 kbps 4.1

ILBC 15.2 kbps 4.1

G.729 8 kbps 3.92

G.726 32 kbps 3.85

G.729A 8 kbps 3.7

G.728 16 kbps 3.61


Digital Signal Processors
• El proceso de conversión de una conversación tradicional en una conversación VoIP
consume gran cantidad de recursos hardware, fundamentalmente CPU.
• Esta tarea es llevada a cabo por dispositivos denominados “pasarela”.
– En muchas ocasiones, estos dispositivos son “routers”
• Para evitar saturar los recursos de los routers, cuando se utilizan pasarelas de voz (entre
redes de telefonía tradicional y redes VoIP) es necesario añadir a los routers componentes
hardware adicionales que se encarguen de esta tarea: Digital Signal Processing (DSP)
• Un DSP es un chip que lleva a cabo las tareas de muestreo, codificación y compresión de
las señales de audio analógico que va a ser convertido en conversaciones VoIP
– No son necesarias si se trabaja en un entorno únicamente VoIP. Solamente se
precisan en las pasarelas.
– Permiten la utilización de interfaces VIC
• FXS, FXO


Principales protocolos de VoIP
• Voz sobre IP en el modelo OSI:


• Voz sobre IP en el modelo OSI
– Característica constante: El tráfico de voz se transmite utilizando RTP/UDP.
– Características variables: La señalización
• H.323 y SIP definen métodos de señalización de extremo a extremo (end-to-end)
• MGCP define un método para separar la función de señalización de la función de
llamada.
– MGCP utiliza un “CallAgent” para realizar la señalización de control
– El dispositivo central, el “CallAgent”, participa solamente en la configuración
de la llamada
– El tráfico de voz, va de dispositivo final a dispositivo final


RTP
• Real Time Transport Protocol es un protocolo que
opera en capa de sesión (por encima de la capa de
transporte) del modelo OSI, sobre UDP
– RTP se ejecuta sobre UDP:
• UDP  Multiplexación de conexiones (nº de puerto) y comprobación de cabeceras
• RTP proporciona: Nº de secuencia y marcas de tiempo  Reordenar los
datagramas recibidos (nº de secuencia) y utilizar un pequeño buffer para eliminar
el efecto del jitter, proporcionando una reproducción suave del audio
• El campo “payload” de la cabecera RTP indica cuál es la naturaleza del contenido
que transporta: audio o vídeo
– Cuando un dispositivo intenta establecer una sesión de audio, RTP elige un puerto
aleatorio entre 16.384 y 32.767 para cada flujo RTP
• Los flujos RTP son “símplex”, es decir, solamente transmiten información
unidireccionalmente  Comunicación bidireccional  2 flujos RTP, uno en cada
sentido
• Los números de puerto se mantienen durante toda la sesión


RTCP
• Al mismo tiempo que se establecen las conexiones RTP, se establecen también las
conexiones RTCP  Información estadística de los paquetes que participan en la llamada:
Nº de paquetes, retardo, pérdida de paquetes y jitter
– Proporciona información útil, pero el protocolo no es crítico
– Utiliza un puerto impar (normalmente el siguiente) del mismo rango que RTP
– Intercambia información cada 5 segundos
– Ayuda a determinar causas de error


• SIP:
– Es un protocolo IETF que especifica los comandos y respuestas para establecer y
finalizar llamadas
– Proporciona servicios de seguridad, proxy y transporte
– Junto con SAP y SDP, proporciona información acerca de las sesiones multicast
existentes
– Es un protocolo de señalización de extremo a extremo.
– Se basa en HTTP y en la utilización del esquema de nombre URL
– Es el protocolo de señalización más utilizado en la actualidad

• Skinny Client Control Protocol:
– Es un protocolo de señalización patentado por Cisco
– Se utiliza para que los teléfonos IP se registren en el Call Manager y para la
señalización de llamadas a través dicho Call Manager


• H.323:
– Es un protocolo estándar ITU definido para realizar conferencias interactivas.
– Se diseñó originalmente para la distribución de multimedia en entornos no orientados a
la conexión.
– En la actualidad, es un conjunto de estándares que define todos los aspectos de la
sincronización de voz, vídeo y transmisión de datos
– Define la señalización de llamada de extremo a extremo

• MGCP:
– Es un estándar de control de pasarelas PSTN o de dispositivos ligeros (RFC 2705)
– Define un protocolo para controlar a las pasarelas de VoIP conectadas da dispositivos
de control de llamadas externos (call agents)
– Proporciona capacidad de señalización para dispositivos frontera (pasarelas) menos
costosa.
– Evita que los dispositivos deban implementar el conjunto entero de protocolos H.323.


Redes de telefonía basada en paquetes: Componentes


• Teléfonos: Teléfonos IP, teléfonos software instalados en PCs, teléfonos convencionales
• Gatekeepers: Proporcionan administración y control centralizados del ancho de banda para
todos los dispositivos de una determinada zona (“management zone”).
– Es un dispositivo opcional
– Proporciona el servicio de “Call Admision Control” (evitar la sobresuscripción)
– Traduce números o nombres a direcciones IP para el enrutamiento de llamada (H.323)
• Gateways: Interconectan las redes de VoIP con dispositivos de telefonía tradicional.
– Suelen ser routers con interfaces de voz, a la que se conecta una línea de voz.
– Tienen también interfaces de datos que se conectan a la red de VoIP.
– Recibe una señal de teléfono por la interfaz de voz, la digitaliza, comprime y
empaqueta en IP y la envía hacia su destino en la red IP.
– Realiza la operación contraria cuando recibe paquetes de VoIP dirigidos a un
dispositivo de telefonía tradicional. Ambas operaciones las hace de forma simultánea
(full-dúplex).
• Multipoint Control Units: Es un dispositivo necesario para gestionar conferencias (+ de 2
partes). Los participantes envían los datos al MCU y éste los reenvía a todos los destinos.


• Servidores de aplicaciones: Proporcionan servicios a los teléfonos IP basados en XML
(Cisco Call Manager Attendant Console).
• Call Agents: Proporcionan control de llamadas, CAC, control de ancho de banda y servicios
de traducción de direcciones a los teléfonos IP o a las pasarelas “Media Gateway Control
Protocol”
– Producto “Call Agent” de Cisco  Call Manager
• Realiza el seguimiento de todos los dispositivos de la red VoIP
• Suele utilizar el protocolo “Skinny Client Control Protocol (SCCP)” para la
señalización a los dispositivos finales
• Para pasar la señalización de llamada a las pasarelas se puede utilizar:
– H.323
– MGCP
– Session Initiation Protocol (SIP)
• Call Manager actúa en cierto modo como una centralita IP
• Dispositivos finales de vídeo: Añaden funcionalidades de vídeo a la voz: Incorporan
elementos para la captura y emisión de vídeo y audio.


Parte II
Componentes de Cisco Unified Communications

Cisco Unified Communications Manager Express
Cisco Unity Express
Cisco Unified Communications Manager
Cisco Unity


Introducción
• Estrategia “Cisco Unified”  Integración de Vídeo, Voz y Datos
• Los productos Cisco VoIP  Cisco Unified Communications
• Productos “core” principales:
– Cisco Unified Communications Manager Express
– Cisco Unified Communications Manager
– Cisco Unity Connection
– Cisco Unified Presence
• A estas soluciones “core”, se les pueden añadir muchas aplicaciones adicionales para
incrementar la funcionalidad. Por ejemplo:
– Cisco Unified Contact Center  Capacidades de Call Center
• Enrutamiento de llamadas basado en comportamiento
• Gestión de colas de llamadas
• Monitorización en tiempo real de las conversaciones…
– Cisco Unified Meeting Place:
• Capacidades de multiconferencia optimizadas
• Colaboración mediante documentación
• Plataformas de entrenamiento


• CUCME permite que un router Cisco ISR o ISR2 permite desplegar servicios de telefonía IP
– Circuitos de voz analógica: Puertos Analógicos (FXS, FXO) y Digitales (BRI o PRI)
– Soporte de equipos VoIP finales, como por ejemplo, Teléfonos IP (hasta 450)
– Conferencia, vídeo-llamada, distribución de llamadas automáticas

• Versión actual: CME 8.X
– Diseñada para ISR2
– Se ejecuta con la versión de IOS adecuada sobre ISR (Cisco 1800, 2800 y 3800)


CUCME: Funcionalidades Clave
• Procesamiento de llamadas y control de dispositivos
– Señalización
– Enrutamiento de llamadas
– Funcionalidades asociadas: desvío, transferencia, …
• Configuración basada en línea de comando o en interfaz gráfica:
– Comandos IOS  CLI
– CCP  Interfaz Gráfica
• Servicio de Directorio Local
– Base de datos de usuarios local  Autenticación
• Soporte de “Computer Telephony Integration”:
– Permite llevar a cabo llamadas desde determinadas aplicaciones, utilizando “Cisco
Unified CallConnector”
• Conexión troncal con otros sistemas de Telefonía IP:
• Integración directa con “Cisco Unity Express”:
– CUE se ejecuta en un módulo instalado en el router  Buzones de voz


CUCME: Interacción con los teléfonos IP de Cisco
• En primer lugar, los teléfonos deben registrarse en el CUCME / CUCM (Este proceso se
abordará más adelante)
• En este apartado se desarrollará la interacción del teléfono IP de Cisco con el CME una vez
que este se ha registrado en el CME
– Escenario 1 de Packet Tracer
• El CME controla virtualmente cada acción
que se lleva a cabo en los teléfonos
– Levantar el auricular  Se envía una
señal (Skinny o SIP) desde el
teléfono al CME
– El usuario teclea los dígitos del
destino  Se envían al CME
mediante el protocolo de señalización
(Skinny o SIP)
– Después de introducir todos los dígitos, el CME envía mediante el protocolo de
señalización las indicaciones al teléfono destino para que suene
– Cuando el destinatario descuelga, el CME indica a los teléfonos que inicien conexiones
RTP entre ellos para enviar los streams de audio de un teléfono a otro


CUCME: Interacción con los teléfonos IP de Cisco II
• El CME no procesa los streams de audio, es decir, no está en medio de la comunicación:
– Elimina el punto único de fallo: Podría reiniciarse el CME y las llamadas activas no se
perderían
– No supone un cuello de botella para las llamadas
• El tráfico de voz se envía directamente entre los teléfonos
• La comunicación entre los teléfonos y el CME es únicamente de tráfico de
señalización


CUCME: Interacción con los teléfonos IP de Cisco III
• En un escenario más complejo que el anterior que se incluye la interconexión con la Red
Telefónica Conmutada. El proceso de llamada desde un teléfono IP de Cisco sería:
– El usuario del teléfono IP Cisco descuelga para hacer la llamada
• Se envían mensajes de señalización desde el teléfono al CME (SCCP o SIP)
– El usuario teclea el nº de teléfono destino, que se corresponde con el nº de teléfono de
la línea analógica asociada al teléfono analógico
• Se envían mensajes de señalización desde el teléfono al CME (SCCP o SIP)
– El router CME “enruta” la llamada haciendo uso de su “plan de llamadas” (dial-plan)
• La llamada es reenviada a través de una línea analógica a la que está conectado
el router CME
• El router CME asume en este momento el rol de “pasarela de voz” (Voice
Gateway), y lleva a cabo la señalización de la llamada de forma tradicional a través
de la línea analógica
– Del mismo modo que lo haría un teléfono analógico o una centralita
– El router debe disponer de una interfaz de voz tradicional digital (T1/E1 o BRI)
o de una interfaz analógica, en este caso, FXO
– El router convierte la llamada VoIP en una llamada de voz tradicional
» Debe disponer de DSPs


CUCME: Interacción con los teléfonos IP de Cisco IV
• Siguiendo un enfoque más moderno, la otra situación que se puede dar es que una red
VoIP de una organización se conecte a la Red Telefónica Pública utilizando los servicios de
un Proveedor de Servicios de Telefonía IP en lugar de utilizar un Proveedor de Servicios de
Telefonía Tradicional.
– En este caso, el router CME reenvía la llamada sobre un enlace troncal SIP en lugar de
hacerlo a través de un circuito analógico o digital tradicional

• Para entender el proceso de enrutamiento de llamadas, es necesario entender que el router
CME tiene dos “patas” en la llamada (2 call legs):
– Una en la Red de Telefonía Pública (Tradicional o VoIP)
– Otra en la red VoIP
– Ahora el router CME sí que está en medio, puesto que lleva a cabo la traducción de la
llamada VoIP a Telefonía Tradicional


Cisco Unity Express


Cisco Unity Express
• CME permite procesar llamadas, pero carece de funcionalidades de “Buzones de Voz”
(igual que un CM o CUCM completo)
• Cisco Unity Express es un sistema de buzones de voz que se puede instalar en un router
CME de varias formas
• CUE se puede configurar tanto a través de línea de comandos, desde el router CME, como
a través de una interfaz Web
– El sistema operativo NO es IOS por lo que es necesario familiarizarse con los
comandos del mismo antes de comenzar a configurarlo.
– La práctica habitual es activar el acceso Web seguro y luego configurarlo a través de la
interfaz gráfica


Implementaciones CME / CUE
• Funcionalidades de CUE:
– Buzón de voz
– Respuesta automática (Auto-Attendant): Permite seleccionar un destinatario por
extensión o por nombre
– Sistema de Respuesta de Voz Interactiva (Interactive Voice Response, IVR): Incluye
funcionalidades básicas que permiten al que llama moverse por un menú y utilizar
funciones más avanzadas que las de Respuesta Automática
– Procesamiento de Faxes en el estándar T.37 nativo: Permite recibir y procesar faxes
como ficheros TIFF adjuntos a mensajes de correo electrónico
• Permite distribuir los faxes a través de los buzones de voz de los usuarios
– “Survivable Remote Site Voicemail” (SRSV): Permite que CUE actúe como backup de
un servidor de buzones de voz principal (por ejemplo un Cisco Unity)
– Basado en estándares: La señalización entre CME y CUE se lleva a cabo mediante el
protocolo SIP


• La versión actual es CUCM 8.X
• Se ejecuta como un “appliance” Linux sobre plataformas hardware certificadas
• Actúa como procesador de llamadas:
– Control de dispositivos
– Enrutamiento de llamadas
– Aplicación de permisos
– Conectividad con aplicaciones externas
– Otras funcionalidades
• Se puede gestionar a través de una interfaz gráfica


CUCM: Funcionalidades Clave
• Soporte completo para audio y vídeo en telefonía
• Basado en “Appliance”: Sistema operativo cerrado e inaccesible  Seguro
• Permite la creación de “clusters” de servidores
• Pasarela de voz “inter-cluster” y Pasarela de voz con otras redes:
– Permite crear enlaces troncales entre diferentes clusters de CUCM
– También puede crear enlaces troncales con otras redes de telefonía como la RTC o un
centralita tradicional
• Built-in Disaster Recovery System (DRS): Servicio de backup de la base de datos de CUCM
a otro dispositivo de red utilizando Secure FTP
• Soporta virtualización sobre VMWare


CUCM: Funcionalidades Clave II
• Soporte o Integración con Servicios de Directorio: Las redes de VoIP utilizan cuentas de
usuario para gran cantidad de propósitos (control de teléfonos, permisos, etc.)
– Puede crear su propio Servicio de Directorio
– Puede integrarse con Directorio Activo de Microsoft

• CUCM Business Edition:
– Un solo CUCM (hasta 500 teléfonos)
– Unified Mobility
– Unity Connection


CUCM: Clúster
• La interacción con los teléfonos IP de CUCM es igual que la que hay en CUCME
• Cuando se utiliza un solo servidor  El comportamiento es prácticamente idéntico
• Funcionamiento en clúster:
– Múltiples servidores individuales que tienen su propia y única configuración y funcionan
de forma coordinada para desplegar
servicios de VoIP
– Las relaciones dentro de un clúster
de CUCM pueden ser de dos tipos:
• Relación entre las Bases de
Datos de los CUCM
• Relación de los datos en
tiempo real del CUCM


Cisco Unity


Cisco Unity
• Es, en primer lugar, la solución de buzones de voz de Cisco. Pero, además proporciona
funciones como la gestión de:
– Mensajes de correo electrónico
– Faxes
– Mensajería instantánea

• Objetivo Principal de Unity  Hacer entregable cualquier mensaje enviado desde un
dispositivo de voz o aplicación. Es decir, se pretende que un mensaje, sin tener en cuenta
el método por el que es recibido, sea entrado por diferentes tipos de medios (teléfono, e-
mail, fax, …)
– Ejemplos:
• Alguien llama y deja un mensaje en el buzón de voz, que es recibido en el cliente
de correo electrónico del usuario
• Permite escuchar los mensajes de correo electrónico desde un dispositivo de voz o
que sean enviados por fax


Cisco Unity: Funcionalidades Clave
• Disponibilidad de despliegue en una plataforma basada en “appliance”:
– Hardware, sistema operativo optimizados y “securizados”
– Hasta 20.000 buzones por servidor
• Buzones de voz accesibles desde cualquier lugar: teléfono, e-mail, web, mensajería
instantánea
• Integración con Directorios LDAP (como el Directorio Activo de Microsoft)
• Posibilidad de Integración con Microsoft Exchange Server:
– Tratamiento de llamadas diferenciado en base al calendario de Exchange
– Tratamiento de los e-mails mediante “text-to-speech”
– Gestión del calendario de Exchange a través del teléfono
• Voice Profile for Internet Mail (VPIM): Estándar que permite la integración servidores de
buzones de voz diferentes
• Alta disponibilidad en modo activo / activo:
– Hasta 20.000 buzones de voz
– Cada servidor soporta hasta 250 consultas de buzones de voz simultáneas
– Se pueden crear clústers, de forma similar a como se hace con los CUCM


Cisco Unity: Interacción Cisco Unity Connection y CUCM
• La implementación habitual de CUCM y Cisco Unity Connection se va a llevar a cabo en
servidores separados. Excepciones
– En CUCM Bussiness Edition
– CUCM Express y Cisco Unity Express

• La integración de estos dos componentes requiere configurar a ambos para que se
comuniquen entre sí utilizando SCCP o SIP.

• El proceso de interacción puede llegar a ser muy complejo. A continuación, se expone un
ejemplo del mismo


Cisco Unity: Interacción Cisco Unity Connection y CUCM II
1. Llega una llamada entrante al router que hace las funciones de pasarela de voz. Dicho
router tiene configurado en su plan de llamadas que las llamadas dirigidas al nº destino se
envíen al CUCM.
2. CUCM recibe la llamada y la redirige a teléfono IP de destino, mediante señalización SCCP
o SIP. Si nadie responde o si se desvía la
llamada al buzón de voz, CUCM reenvía la
llamada a una extensión preconfigurada que
llega a Cisco Unity Connection
3. CUCM transfiere la llamada (usando SCCP o
SIP) al servidor Cisco Unity, que utiliza la
extensión de la llamada para localizar el buzón
voz adecuado.
4. Una vez finalizada la llamada, Cisco Unity hace
una llamada a la extensión del “Message
Waiting Indicator” (WMI) del CUCM. El CUCM
ilumina el indicador de mensaje de voz en el
teléfono IP, alertándole de que tiene un mensaje
de voz pendiente


Parte III
Funcionamiento de los Teléfonos IP con Tecnología Cisco

Conexión y Alimentación de los Teléfonos IP de Cisco
Configuración de VLANs
Proceso de Arranque de los Teléfonos IP de Cisco


Funcionamiento de los Teléfonos IP con Tecnología Cisco


• Tecnologías de soporte fundamentales para
Telefonía IP:
– Power over Ethernet
– VLANs (Voice VLAN)
– DHCP

• Esquema de Interconexión de los Teléfonos IP de
Cisco


Conexión y Alimentación de los Teléfonos IP de Cisco II
• Un teléfono IP de Cisco puede ser alimentado eléctricamente por tres métodos:
– PoE desde un switch Cisco Catalyst :
• Preestándar Cisco
• IEEE 802.3af
– PoE desde el Patch Panel o desde “Power Injector :
• Preestándar Cisco
• IEEE 802.3af
– Mediante un transformador y conexión eléctrica a un enchufe convencional:
• Algunos modelos de teléfonos Cisco no traen alimentador eléctrico  Analizar los
costes de comprar alimentadores eléctricos para todos los teléfonos o actualizar el
hardware
• Si a algún teléfono se le incorpora una “mochila” (módulos de vídeo-conferencia,
módulos de botones adicionales, …), el consumo total puede exceder la potencia
proporcionada por PoE, con lo que habrá que alimentar eléctricamente el
dispositivo


PoE desde un switch Cisco Catalyst
• Permite el uso de los pares no utilizados para la transmisión de datos en el cableado de par
trenzado
– Cableado basado en par trenzado categoría 5 o superior
• Los dispositivos Cisco pueden ser alimentados tanto por:
– Cisco Inline Power
– PoE: IEEE 802.3af  15,4 W
• Ventajas:
– Centralización de la distribución de la alimentación eléctrica
• Facilita el uso de SAIs
– Reducción de la instalación eléctrica necesaria
• Nuevos estándares
– PoE Plus: IEEE 802.3at  25,5 W


PoE desde un Patch Panel o desde “Power Injectors”
• Si los switches de acceso no soportan PoE, al desplegar ToIP se pueden usar paneles de
distribución que introduzcan alimentación eléctrica en los cables Ethernet o bien inyectores
individuales
• Tanto los paneles de distribución como los inyectores, requieren además una conexión a la
red eléctrica


• Una vez que un teléfono IP se ha encendido, debe determinar a qué VLAN está asociado
debido a:
– Cuestiones de seguridad:
• Utilizacion de herramientas como Wireshark o VOMIT  Capturan conversaciones
de VoIP  *.wav
– Cuestiones de QoS / CoS
• Voice VLAN:
– El modo de incorporar los teléfonos IP a la red corporativa (ambos se conectan al
mismo puerto en el switch)  Problemas a la hora de separar al PC y al teléfono en
VLAN distintas
– Solución: Los teléfonos IP implementan el protocolo de etiquetado de VLAN IEEE
802.1Q
• Los teléfonos IP incorporan un “microswitch” de 3 puertos que permite enviar y
recibir tráfico etiquetado con 802.1Q
• Simulación Escenario 1


Configuración de VLANs II
• Por lo tanto, podría pensarse que el teléfono IP y el switch establecen un enlace troncal
convencional. Esto NO es así.
– Un enlace troncal convencional, por defecto, pasa la información de todas las VLANs
mientras que en este tipo de conexión solamente se pasan dos tipos de tráfico:
• El tráfico de Voz proveniente del teléfono IP, que irá etiquetado con el nº de la
VLAN de voz
• El tráfico proveniente del equipo conectado al teléfono, que se transmite sin
etiquetar desde el teléfono al switch. Cuando estos paquetes llegan la switch se
asignan a la VLAN de acceso a la que se ha asignado dicho puerto
• Se recomienda (por motivos de seguridad) configurar los puertos a los que hay conectados
teléfonos IP como puertos de acceso (switchport mode access) para asociar todo el tráfico
de datos recibido a una sola VLAN
• Cuando en dicho puerto se configura una Voice VLAN el puerto se convierte en un enlace
“mini-trunk” o “quasi-access” que permite tráfico solamente de 2 VLANs específicas:
– VLAN de datos (especificada mediante switchport access vlan X)
– VLAN de voz (especificada mediante switchport voice vlan Y)
• Escenario 1


Consideraciones sobre Spanning-Tree
• Cuando se conectan teléfonos IP a un switch debe prestarse especial atención en activar el
comportamiento “spanning-tree portfast” en los puertos del switch
– De lo contrario, el puerto no envía tráfico de datos durante 50 s.
– El teléfono necesita obtener rápidamente el ID de su VLAN de Voz y posteriormente su
configuración IP mediante DHCP
– Los puertos con VLAN de voz activa no son consideradas por Cisco IOS como puertos
troncales, desde el punto de vista de Spanning-Tree


Consideraciones sobre CDP
• En un escenario ideal (Switches Cisco con teléfonos IP Cisco), los teléfonos aprenden cuál
es su VLAN de voz mediante CDP
– Una vez que el teléfono recibe la información sobre su VLAN de voz, envía su tráfico
etiquetado con dicha VLAN

• Existen, sin embargo, escenarios no ideales en los que se podrán encontrar soluciones
multifabricante en la capa de acceso, como (sobre el proceso de arranque en estos
escenarios hablaremos más adelante):
– Switches no Cisco con teléfonos Cisco:
• Con o sin LLDP
• Con o sin soporte de doble arranque
– Teléfonos no Cisco


1. El teléfono IP Cisco se conecta a un puerto FastEthernet de un switch. Si el teléfono y el
switch soportan PoE, el teléfono IP recibe la alimentación desde el switch
2. El switch proporciona al teléfono el nº de VLAN de voz mediante CDP en un escenario
completamente Cisco
3. El teléfono envía una petición DHCP solicitando la configuración IP para el mismo a través
de peticiones etiquetadas por la VLAN de voz
4. El servidor DHCP responde con una oferta de configuración. Cuando el teléfono acepta la
oferta, recibe todas las opciones DHCP, además de la propia IP:
1. Pasarela por defecto
2. Servidor DNS
3. Nombre de dominio
4. Opción 150  Servidor TFTP desde el que descargar la configuración del teléfono
5. El teléfono solicita su fichero de configuración al servidor TFTP y se descarga la
configuración. En dicha configuración hay una lista de CUCM o CUCME.
6. El teléfono intenta contactar con el primer CUCM. Si falla, lo intenta con el segundo y si no
con el tercero. Cuando el contacto es correcto, el teléfono intenta registrarse en el CUCM.
Si no puede contactar con ninguno o no es capaz de registrarse  El teléfono se reinicia


Configuración del Servidor DHCP
• En organizaciones pequeñas, se puede utilizar el propio router como servidor DHCP
• En organizaciones grandes, los servicios de DHCP se centralizan en plataformas de
servidor
• Sin tener en cuenta la opción elegida, es necesario indicar la dirección IP del servidor TFTP
a los teléfonos
– Opción 150
– Escenario 1
• Cuando se configura un teléfono en un CME o en un CUCM, se crea un fichero XML y se
almacena en el servidor TFTP
– Los ficheros de configuración tienen un nombre que responde al siguiente formato
SEP<MAC_del_teléfono_IP>.cnf.xml
– Contienen la configuración base del teléfono:
• Configuraciones de lenguaje, URLs, etc.
• Lista de los CUCM o CME para que se registre el teléfono
– En caso de utilizar la opción de “autoregistro”, se utiliza un fichero por defecto
denominado XMLDefault.cnf.xml


Sincronización de reloj con NTP
• Razones por las que es importante que los dispositivos estén sincronizados en una red
VoIP:
– Mostrar la hora y fecha correcta a los usuarios
– Asignar la fecha y hora correcta a los mensajes de buzón de voz
– Asociar la hora precisa mediante los “Call Details Record” (CDR), que se utilizan para
hacer el seguimiento de las llamadas en la red
– Forma parte de integral de la configuración de seguridad de la red
– Recoger la información precisa en los mensajes de log de todos los dispositivos de red
• Configuración de la hora en dispositivos Cisco:
– Manualmente
– Mediante NTP:
• Opción preferente


Registro de teléfonos IP
• Una vez que el teléfono ha obtenido su fichero de configuración, intenta registrarse
utilizando el protocolo SCCP o SIP
– El uso de un protocolo u otro depende del firmware del teléfono
– Skinny Client Control Protocol (SCCP):
• Protocolo Cisco
• Mayor base instalada de teléfonos
• Va a ir eliminándose poco a poco
– Session Initiation Protocol (SIP):
• Protocolo estándar
• Se recomienda su uso en nuevas instalaciones


Registro de teléfonos IP II
• Independientemente del protocolo utilizado, el proceso de registro consiste en:
1. El teléfono IP contacta con el servidor y se identifica con su MAC
2. El CM busca en su base de datos la configuración de dicho teléfono. Si lo encuentra,
envía (usando SIP o SCCP) los siguientes datos en el fichero XML de configuración
operativa al teléfono. Este fichero contiene:
• Números de línea y directorio asignados
• Los tonos de llamada
• Disposición de los botones de llamada
• …
• Es muy importante no confundir este fichero de configuración, denominado configuración
operativa con el fichero de configuración base, que se ha obtenido previamente desde el
servidor TFTP y que contiene información como:
– Idioma,
– Versión de firmware *,
– Agente Procesador de llamadas (CM, CME, CUCM, CUCME),
– Nºs de puerto


Parte IV
CUCME - CME

Gestión de Teléfonos y Usuarios
Planes de Llamada


Administración de CUCME - CME



Gestión de Teléfonos utilizando Cisco IOS


• Hasta ahora:
– Conceptos base de VoIP
– Productos fundamentales de la
arquitectura CUCM
– Tecnologías subyacentes

• En este punto se abordará:
– Provisión y mantenimiento de teléfonos
IP
• Actualización del firmware
• Configuración de:
– Ephone
– EphoNe-DN


• Ejemplo de Configuración de un puerto de un switch que da servicio a un teléfono IP
Switch#configure terminal
Switch(config)#interface fa0/1
Switch(config-if)#switchport mode access
Switch(config-if)#switchport voice vlan 100
Switch(config-if)#switchport access vlan 200
Switch(config-if)#spanning-tree portfast

• Ejemplo de Configuración de un pool DHCP (en un router Cisco) para dar servicio a
teléfonos IP
ROUTER(config)#ip dhcp pool VOICE_SCOPE
ROUTER(dhcp-config)#network 172.16.1.0 255.255.255.0
ROUTER(dhcp-config)#default-router 172.16.1.1
ROUTER(dhcp-config)#option 150 172.16.1.1
ROUTER(dhcp-config)#dns-server 4.2.2.2


Actualización del firmware de los Teléfonos IP
• Durante el proceso de arranque de los teléfonos IP se ha visto que descargan su
configuración base desde un servidor TFTP:
– Localizan el servidor mediante la opción 150 obtenida mediante DHCP
– El servidor TFTP puede ser:
• Router Cisco: Opción habitual en el caso de utilizar un CME “aislado”
• CUCM “aislado”
• CUCM “Publisher” de un cluster
• Servidor TFTP dedicado
– Los teléfonos descargan la configuración base y el firmware del servidor TFTP
– ¿Cuándo se descarga un teléfono un nuevo firmware?
• Cuando se le indica la versión de firmware que debe utilizar en el fichero de
configuración base
• Si se le indica al teléfono que debe descargarse una versión concreta de firmware
y el teléfono no es capaz de localizarla, el teléfono no arranca
– Es un problema que suele darse cuando se aplican “plantillas de
configuración”


Configuración del CME (IOS)
• Consideraciones previas
– Si el router que contiene el CME va a actuar como servidor TFTP, es necesario
configurarlo como tal:
• El servicio TFTP está activado por defecto en los routers Cisco
• Es necesario indicar que ficheros se van a publicar mediante TFTP
– Firmware de los teléfonos
– Ficheros de configuración base:
» SEP<MAC-ADDRESS>.cnf.xml
» XMLDefault.cnf.xml
• También puede derivarse el servicio a un equipo externo:
– cnf-file location tftp://<ip address of TFTP server>


CME_Voice# dir flash:/phone/7940-7960
Directory of flash:/phone/7940-7960/
98 -rw- 129824 May 12 2008 21:33:56 -07:00 P00308000500.bin
99 -rw- 458 May 12 2008 21:33:56 -07:00 P00308000500.loads
100 -rw- 705536 May 12 2008 21:34:00 -07:00 P00308000500.sb2
101 -rw- 130228 May 12 2008 21:34:00 -07:00 P00308000500.sbn
129996800 bytes total (28583936 bytes free)
CME_Voice# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
CME_Voice(config)# tftp-server flash:/phone/7940-7960/P00308000500.bin alias
P00308000500.bin
CME_Voice(config)# tftp-server flash:/phone/7940-7960/P00308000500.loads alias
P00308000500.loads
CME_Voice(config)# tftp-server flash:/phone/7940-7960/P00308000500.sb2 alias
P00308000500.sb2
CME_Voice(config)# tftp-server flash:/phone/7940-7960/P00308000500.sbn alias
P00308000500.sbn


• La configuración básica de un CUCM o CME para activar el servicio de voz incluye los
siguientes parámetros:
– IP origen  IP en la que se van a registrar los teléfonos
– El número máximo de teléfonos a los que se va a dar soporte
• No debe ser superior al nº de licencias adquiridas
– El valor máximo de números de directorio (líneas) a los que se va a dar soporte
• Ejemplo de configuración:
CME_Voice(config)# telephony-service
CME_Voice(config-telephony)# ip source-address 172.16.1.1
CME_Voice(config-telephony)# max-ephones ?
<1-30> Maximum phones to support
CME_Voice(config-telephony)# max-ephones 24
CME_Voice(config-telephony)# max-dn ?
<1-150> Maximum directory numbers supported
<cr>
CME_Voice(config-telephony)# max-dn 48


Configuración del CME (IOS): Ephone-DN
• Un “Ephone-dn” es un número de directorio asignado a uno o más botones de uno o más
teléfonos Cisco
– Single-line: El ephone-dn puede hacer o recibir simultáneamente una sola llamada
• Útil para servicios como “intercom”
– Dual-line: El ephone-dn puede manejar dos llamadas simultáneamente
• Llamada en espera
• Transferencias con consulta …
• Útil para la mayor parte de las configuraciones de usuario final
– Las nuevas versiones de IOS implementan un nuevo tipo de ephone-dn que soporta
hasta 8 líneas simultáneas
CME_Voice(config)# ephone-dn 1
CME_Voice(config-ephone-dn)# number 1000
CME_Voice(config-ephone-dn)# exit
CME_Voice(config)# ephone-dn 2 ?
CME_Voice(config)# ephone-dn 2 dual-line


Configuración del CME (IOS): Ephone
• Ephone es el elemento que se utiliza para representar la configuración de un teléfono IP o
de un softphone en el CME
– El parámetro max-ephone definido con anterioridad limita el nº de ephones a
configurar

• Sintaxis:
CME_Voice(config)# ephone 1
CME_Voice(config-ephone)#

• En el modo de configuración de ephone se define:
– Vinculación con el teléfono físico: Dirección MAC del teléfono
• Sintaxis: mac-address <H.H.H-Mac address>
• Ejemplo: CME_Voice(config-ephone)# mac-address 0014.1c48.e71a


Configuración del CME (IOS): Ephone II
– Asociar al ephone las ephone-dn
• Sintaxis: button <physical button> <separator> <ephone-dn>
• Ejemplo: CME_Voice(config-ephone)# button 1:2
– Asigna el ephone-dn 2 al botón 1 del ephone
– El símbolo : indica que el teléfono tenga un sonido de llamada “normal” o “por
defecto”
• En este caso cuando se llame a la extensión 1001 sonará la llamada en el teléfono
representado por el ephone 1 y parpadeará la luz de llamada del teléfono.

– Reinicio suave (“warm boot”) de los teléfonos  Recarga la configuración del servidor
TFTP:
• Sintaxis / ejemplo: CME_Voice(config-ephone)# restart


Configuración del CME (IOS): Ephone III
• Comandos de diagnóstico: 2 Teléfonos Configurados, 1 registrado (sin ephone-dn
asociados)
– CME_Voice# show ephone

CME_Voice# show ephone

ephone-1 Mac:0014.1C48.E6D1 TCP socket:[2] activeLine:0 REGISTERED in SCCP ver 11
and Server in ver 8
mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 caps:8
IP:172.30.60.31 52777 Telecaster 7960 keepalive 0 max_line 6

ephone-2 Mac:000C.2957.ACF5 TCP socket:[-1] activeLine:0 UNREGISTERED

IP:0.0.0.0 0 Unknown 0 keepalive 0 max_line 0


Configuración del CME (IOS): Ephone IV
• Comandos de diagnóstico: 1 Teléfonos Configurado, 1 registrado (2 ephone-dn asociados)
– CME_Voice# show ephone

CME_Voice# show ephone
ephone-1 Mac:0014.6A16.C2DA TCP socket:[5] activeLine:0 REGISTERED in SCCP ver 8
and Server in ver 8
IP:172.30.60.32 14719 7912 keepalive 2701 max_line 2 dual-line
button 1: dn 2 number 1001 CH1 IDLE CH2 IDLE
button 2: dn 1 number 1000 CH1 IDLE


Configuración del CME (IOS): Ejemplo
CME_Voice(config-ephone)# mac-address 00a0.932a.b34c
CME_Voice(config-ephone)# button 1:10 2:15
CME_Voice(config-ephone)# exit
CME_Voice(config-ephone)# mac-address 00a0.aa25.431b
CME_Voice(config-ephone)# button 1:11 2:15
CME_Voice(config-ephone)# mac-address 00a0.a819.90a1
CME_Voice(config-ephone)# button 1:12 2:13 3:15


Configuración de Planes de Llamada en CME

Configuración de las Características de los Puertos (físicos) de Voz
Configuración de Dial-Peers


Configuración de las Características
de
los Puertos de Voz

Configuración de los Puertos de Voz Analógicos:
FXS
FXO
Configuración de Puertos Digitales


Puertos FXS
• Los puertos FXS permiten que los dispositivos finales de voz analógica (teléfonos, faxes,
…) se conecten al router
• Para saber de qué puertos FXS dispone el CME, se puede utilizar el comando:
CME_Voice# show voice port summary
IN OUT
PORT CH SIG-TYPE ADMIN OPER STATUS STATUS EC
============== == ============ ===== ==== ======== ======== ==
0/0/0 — fxs-ls up dorm on-hook idle y
0/0/1 — fxs-ls up dorm on-hook idle y
0/2/0 — fxo-ls up dorm idle on-hook y
• En los puertos FXS existen tres características que se pueden configurar:
– Señalización
– Tonos de progreso de llamada
– Información del “Caller ID”


Puertos FXS: Señalización
• Se pueden usar dos tipos de señalización  Método utilizado por el dispositivo conectado
para indicar que se ha descolgado el teléfono: ground-start y loop-start
• Características:
Ground Start Loop Start
Señaliza una nueva conexión Señaliza completando el
conectando a tierra los 2 hilos circuito
del cable temporalmente
Debe configurarse La opción por defecto
Para conectarse a centralitas Teléfonos y faxes

• Configuración:
CME_Voice(config)# voice-port 0/0/0
CME_Voice(config-voiceport)# signal ?
groundStart Ground Start
loopStart Loop Start
CME_Voice(config-voiceport)# signal loopStart


Puertos FXS: Tonos de progreso de llamada y Caller ID
• Los tonos que indican el progreso de una llamada suenan de forma ligeramente distinta en
función de la ubicación geográfica
– Por defecto, la configuración de CME hace que el tono de llamada suene como lo haría
en USA
– Este parámetro, aunque no es importante, puede ajustarse:
• CME_Voice(config)# voice-port 0/0/0
• CME_Voice(config-voiceport)# cptone ES

• Se puede personalizar la información a mostrar a otros dispositivos que reciban una
llamada desde el dispositivo conectado al puerto FXS. En este caso recibirán tanto el
nombre del dispositivo como el nº de teléfono del mismo:
CME_Voice(config)# voice-port 0/0/0
CME_Voice(config-voiceport)# station-id name 3rd Floor Fax
CME_Voice(config-voiceport)# station-id number 5551000


Puertos FXO
• Permiten que el CME actúe como “dispositivo final” tanto de la red telefónica pública como
de una centralita privada
• Comandos de configuración:
– Igual que en el caso de los FXS:
• signal
• station-id
– Comandos propios:
• dial-type: Permite elegir si la llamada se va a efectuar mediante tonos DTMF o
mediantes pulsos
• ring-number:
– Determina el nº de veces que debe sonar el teléfono antes de que el CME
conteste la llamada
– Por defecto, 1


Puertos Digitales
• Puertos T1/E1 en formato de tarjetas de “Voice and WAN Interface Cards”
– Servicios de datos WAN
– Servicios de voz
• Estos puertos requieren de configuración previa al funcionamiento en la red
– En Europa las interfaces primarios RDSI son de tipo E1:
– Ejemplo:
CME_Router#show controllers e1
E1 1/0 is up.
Applique type is Channelized E1 - balanced
No alarms detected.
Version info of Slot 1: HW: 2, Firmware: 4, PLD Rev: 2
Manufacture Cookie is not programmed.
Framing is CRC4, Line Code is HDB3, Clock Source is Line
Primary.
Data in current interval (251 seconds elapsed): …


Puertos Digitales
• Configuración de enlaces Primarios E1
CME_Voice(config)# isdn switch-type primary-net5
CME_Voice(config)# controller e1 1/0
CME_Voice(config-controller)# pri-group timeslots 1-31
CME_Voice(config-controller)#^Z

• Deben existir suficientes recursos DSP para soportar la conexión primaria. Solamente se
crearán los canales para los que haya suficientes recursos DSP

CME_Voice# show voice port summary
IN OUT
PORT CH SIG-TYPE ADMIN OPER STATUS STATUS EC
========= == ============ ===== ==== ======== ======== ==
1/0:16 01 isdn-voice up dorm none none y
…


Configuración de Dial Peers


Configuración de Dial Peers
• Por defecto, un CME solamente es capaz de enrutar llamadas entre las extensiones que
están configuradas en el CME, asociadas con teléfonos registrados
• Los “Dial peers” son los artefactos que se utiliza para enrutar las llamadas fuera del CME:
– Dispositivos finales analógicos: Puertos FXS, FXO
• Permiten asociar nº a dispositivos analógicos finales
– Conexiones digitales E1
– Otros CME
• Tipos de Dial-Peer:
– POTS Dial Peer: Definen la información de alcanzabilidad para cualquier conexión de
voz tradicional (FXS, FXO, E&M, puertos de voz digital)
– VoIP Dial Peer: Define la información de alcanzabilidad para conexiones VoIP
(cualquier dispositivo alcanzable a través de una IP)


Voice Call Legs
• La configuración de Dial Peers se basa en el concepto de “Voice Call Legs”.
• Un “Voice Call Leg” representa una conexión hacia o desde una pasarela de voz desde un
dispositivo POTS o desde un dispositivo VoIP

• En el ejemplo, el teléfono con la extensión 1101 hace una llamada al teléfono con la
extensión 2510. Para que la llamada se establezca con éxito debe atravesar 4 “call legs”:
– Call Leg1: La llamada entrante POTS desde el teléfono 1101 en CME_A
– Call Leg2: La llamada saliente VoIP desde CME_A al router B
– Call Leg3: La llamada entrante VoIP en el router B desde el CME_A
– Call Leg4: La llamada POTS saliente desde el router B a la extensión 2510
• Existirán otras 4 “call legs” para gestionar el flujo de voz de la llamada desde 2510 a 1101


Configuración de POTS Dial Peers

• En este escenario se comienza la configuración en CME_A:
– Comando clave: router(config)# dial-peer voice <tag> pots
• Aunque el <tag> no tiene importancia a la hora de enrutar llamadas, se
recomienda utilizar un valor relacionado con el nº de extensión
– Ejemplo:
CME_A(config)# dial-peer voice 1101 pots
CME_A(config-dial-peer)# destination-pattern 1101
CME_A(config-dial-peer)# port 0/0/0
CME_A(config-dial-peer)# exit
CME_A(config)# dial-peer voice 1102 pots
CME_A(config-dial-peer)# destination-pattern 1102
CME_A(config-dial-peer)# port 0/0/1


Configuración de POTS Dial Peers: Verificación
• Dial Peers configurados:
CME_A# show dial-peer voice summary
dial-peer hunt 0
AD PRE PASS OUT
TAG TYPE MIN OPER PREFIX DEST-PATTERN FER THRU SESS-TARGET STAT PORT
20005 pots up up 1500$ 0 50/0/20
20006 pots up up 1501$ 0 50/0/21
20007 pots up up 1502$ 0 50/0/22
20008 pots up up 1503$ 0 50/0/23
20009 pots up up 1504$ 0 50/0/24
20010 pots up up 1505$ 0 50/0/25
20011 pots up up 1506$ 0 50/0/26
20012 pots up up 1507$ 0 50/0/27
20013 pots up up 1508$ 0 50/0/28
20014 pots up up 1509$ 0 50/0/29
1101 pots up up 1101 0 up 0/0/0
1102 pots up up 1102 0 up 0/0/1


Configuración de VoIP Dial Peers

• En este escenario, debe configurarse también el enrutamiento de las llamadas VoIP:
CME_A(config)# dial-peer voice 2000 voip
CME_A(config-dial-peer)# destination-pattern 2...
CME_A(config-dial-peer)# session target ipv4:10.1.1.2
CME_A(config-dial-peer)# codec g711ulaw

ROUTER_B(config)# dial-peer voice 1100 voip
ROUTER_B(config-dial-peer)# destination-pattern 110.
ROUTER_B(config-dial-peer)# session target ipv4:10.1.1.1
ROUTER_B(config-dial-peer)# codec g711ulaw


Configuración de VoIP Dial Peers
• Características de la Configuración:
– destination-pattern <cadena_de_dígitos>
– session target <expresion>  Indica el dispositivo destino
• Opciones:
– ipv4:<ip address>
– dns:<nombre>
• Los destinatarios serán otros Call Managers (o CME), servidores proxy SIP o
gatekeepers H.323
– codec <codec>
• Si el valor del codec no coincide entre los dos routers, la llamada fallará
• El codec por defecto para los dial peer voip es G.729

Fundamentos de VoIP con Tecnología Cisco

Más contenido relacionado

La actualidad más candente

Similar a Fundamentos de VoIP con Tecnología Cisco

Más de Francisco Javier Novoa de Manuel

Fundamentos de VoIP con Tecnología Cisco