VoIP

Introducción (I) Tradicionalmente: Redes independientes y optimizadas VOZ: conmutación de circuitos. Recursos permanentes  retardo constante. Si no hay circuitos disponibles se rechazan peticiones. DATOS: conmutación de paquetes. Asignación dinámica de recursos  fluctuaciones en el retardo. Integración de múltiples servicios: reducción de costos y eficiencia en recursos RDSI: Datos en redes de voz (Interfaz) Frame Relay: Voz en redes de datos ATM: Transporta datos + voz (QoS)

Introducción (II) IP: Éxito de Internet  Integración de servicios (conferencias multimedia, mensajería unificada –voz, correo electrónico y fax-, teleoperador a través de web, indicadores de presencia...) Problemas a solucionar: pérdida paquetes, retardos grandes y variables, sobrecarga por cabeceras. Garantizar QoS (calidad de voz, disponibilidad de servicio, conectividad entre diferentes redes, seguridad...)  Requisitos de PSTN Definición de arquitectura de control y protocolos de señalización: OBJETIVO DE ESTA SESIÓN

Voz sobre paquetes (I) Usuario: Degradación de la voz Recepción: Espaciamiento no constante Flujo incompleto Problemas de flujo: esperas variables pérdidas de paquetes

Voz sobre paquetes (II) Eficiencia y calidad de servicio: Codecs compresores (reducen ancho de banda) Buffers en recepción (regeneran el espaciado y amortiguan retardo) Mecanismos de QoS en la red (ej: priorización de paquetes de voz) Señalización: Establecimiento y liberación dinámica de llamadas VoIP Información para el usuario del progreso de la llamada Acuerdo en los códecs a emplear Movilidad de usuarios Control de acceso Tarificación Servicios suplementarios (ej. desvío de llamadas) Interfuncionamiento con la red telefónica (PSTN) Tratamiento de señales no vocales (ej. MODEM o fax)

Códecs de voz (I) Tres técnicas de codificación PCM: codificadores de forma de onda Codifica cada muestra del conversor AD Ej: G.711 (RTC) ADPCM: Adaptativo diferencial PCM Codifica la diferencia entre cada muestra y la anterior Menor rango de codificación  tasas de bit menores LPC: predictivo lineal Codificación por bloques (Representación parametrizada de las carácterísticas del conjunto)

Códecs de voz (II) G.711 G.721 G.726 G.727 G.728 G.729 G.723.1 GSM FR   G.711 G.721 G.726 G.727 G.728 G.729 G.723.1 GSM FR Tipo de codificación PCM ADPCM LD-CELP CS-ACELP MP-MLQ/ ACELP RPE-LTP Tasa binaria (Kbits/s) 64 32 16/24/ 32/40 16 8 6,4/5,3 13 Complejidad (MIPS) 0,1 10 12 33 22 16/18 2,5 Retardo codificador (ms) 0,125 0,625 15 37,5 20 Calidad (MOS) 4,2 4,0 3,7-3,9 3,6-3,8 Robustez frente a errores - + -- ++

Supresión de silencios Complemento de códecs compresores para reducir ancho de banda Detección de periodos de silencio (VAD: Voice Activity Detection) En una conversación telefónica: reducción del 60 % del flujo Paquetes de silencio (SID: Silence Insertion Description) Indicador nivel de ruido

Tamaño de los paquetes de voz Paquetes de gran tamaño Incluyen varios bloques de datos Reduce la influencia de las cabeceras en el flujo de datos Aumenta el tiempo de empaquetado Paquetes pequeños Tráfico añadido por sobrecarga de cabeceras Factores que influyen en el tamaño de los paquetes Retardo extremo a extremo Complejidad de algoritmos de compresión

Retardo extremo a extremo Factores que contribuyen al retardo: Retardo del algoritmo de codificación Tiempo de empaquetado Tiempo de propagación Tiempo de transmisión Tiempos de espera en los nodos de conmutación (dependiente del tráfico en la red) Tiempo de descompresión Consecuencias del retardo: Pérdida de interactividad (>150 ms) Eco

Retardo extremo a extremo: ECO (I) ECO ELÉCTRICO: Reflejos indeseados hacia los focos emisores Más molesto cuanto mayor desfase temporal Límite en 50 ms (llamada internacional en PSTN)  Cancelación de eco Producido por desadaptación en las bobinas híbridas Se percibe como consecuencia del retardo de las pasarelas  responsabilidad del operador de tránsito (se cancela en las pasarelas )

Retardo extremo a extremo: ECO (II) ECO ACÚSTICO: Acoplo altavoz/micrófono Despreciable en teléfonos convencionales Importante en: Equipos manos-libres Teléfonos móviles PC con altavoz y micrófono en entorno IP

Fluctuaciones del retardo (I) Regeneración de la voz es un proceso síncrono  necesita bloques de voz con frecuencia periódica Flujos de paquetes espaciados de manera irregular  Buffer amortiguador

Fluctuaciones en el retardo (II) Tamaño del buffer: Gran tamaño: filtra mayores variaciones de retardo Tamaño pequeño: incluye poco retardo extra 1 2 3 4 5 6 t Transmisión Recepción Retardo: Rmax-Rmin

Pérdida de paquetes Errores de transmisión Congestión de la red o aviso de congestión Emisores de voz: retransmisión inútil  VoIP emplea UDP Mecanismos para evitar congestión: ATM: mecanismos de control de tráfico y QoS Frame Relay: no tiene QoS pero controla el tráfico entrante IP: no existen mecanismos. El problema sigue abierto Soluciones en IP: Códigos de corrección de errores (redundancia aumenta la sobrecarga) Sobredimensionar la red Disimular las pérdidas (ruido blanco- en GSM, interpolación de paquetes)

Protocolos de tiempo real sobre IP Audio y video. Puertos UDP pares e independientes en cada extremo Información periódica del estado y calidad de la comunicación puertos UDP inmediatamente superiores Norma RFC 1889: Protocolos RTP y RTCP

RTP RTP (Real Time Protocol) Standard para el transporte de tráfico en tiempo real sobre Internet Origen: red MBONE (Multicast Backbone): red virtual de difusión superpuesta sobre Internet para multiconferencias Se asume la existencia Imperfecciones en la red (pérdidas y retardos) Posible variación de características de la red durante la comunicación

Formato de la trama RTP 7 15 31 V P X CC M PT SN Timestamp 7 15 31 V P X CC M PT SN Timestamp Identificador SSRC Identificador CSRC Extensión de cabecera Carga útil Versión RTP (2) P=1 incluye relleno (1) X=1 Incluye extensión de cabecera (1) Video H.263 H.261 34 31   Audio PCM, ley  PCM, ley A G.722 G.723 G.728 G.729 8 9 4 15 18 Tipo de carga Códec PT Tipo de carga (7): formato de carga útil Tipo de carga (7): formato de carga útil Número de identificadores CSRC presentes en la cabecera (4) Marca (1). Depende de PT Número de secuencia (16) Cabecera básica (12 octetos) Instante de muestreo (32) Identificador de fuente (32) Identificador de contribuciones en una mezcla (32)

Ancho de banda para sesión VoIP (I) Tamaño de carga útil: Tamaño de los bloques de información Número de bloques por paquete Sobrecarga por cabeceras: Cabeceras que añaden los protocolos sucesivos Ej: Caso más sencillo (VoIP) RTP: 12 octetos UDP: 8 octetos IP: 20 octetos Niveles inferiores (ej: PPP 6 octetos) Nivel 2 IP 20 octetos UDP 8 oct RTP 12 oct Carga útil N oct 40 octetos

Ancho de banda para sesión VoIP (II) Códec Tasa nominal (Kbits/s) Retardo empaquetado (ms) Tamaño carga útil (octetos) Tasa de envío (Kbits/s) IP (sin nivel 2) IP/PPP IP/AAL5   G.711 64 5 40 128 137.6 169.6 10 80 96 100.8 127.2 20 160 82.4 106 G.729 8 44.8 84.8 24 26.4 42.4 16 17.2 21.2

Reducción del ancho de banda Mecanismos Supresión de silencios Compresión de cabeceras Se aplican en el enlace: necesario en ambos extremos Estándares RFCs 2508 (CRTP) y 3095 (ROHC) Suprimen información redundante: mejora la eficiencia Sólo se suelen aplicar en enlaces de acceso y no en troncales

RTCP (I) Regula intercambio de mensajes de control en una sesión multimedia  No proporciona mecanismos QoS Información de calidad de servicio: Retardo Jitter Tasa de paquetes recibidos y perdidos... Opcional Permite tomar medidas en tiempo real

RTCP (II) Funciones adicionales útiles en participaciones múltiples: Identificación Correlación de relojes Control de los participantes Mensajes de RTCP (5 tipos definidos en RFC 1889): SR (Sender Report) RR (Receiver Repot) SDES (Source Description) BYE APP (Application-specific) Ancho de banda de RTCP: Entre 1 y 5% del RTP Con múltiples participantes: control para evitar avalanchas

Señalización en VoIP (I) Necesidad: comunicación entre elementos que forman la red (Terminales, servidores de llamada, pasarelas, PSTN...) Funciones: Equivalentes a las de PSTN: Establecimiento de llamada (negociación direcciones IP y puertos UDP) Señales de progreso de llamada (ej: aviso al origen de ring en destino) Control de acceso (identificación de terminales para facturación) Servicios suplementarios y de movilidad Necesarias en redes IP: Selección de la modalidad de acceso a la red (LAN, RDSI, RTC, ADSL...) Negociación del códec de voz De adaptación VoIP-PSTN

Señalización en VoIP (II) No hay unidad de protocolos (en transporte RTP/RTCP) Factores causantes de la diversidad: Variedad de escenarios Diferentes enfoques de los organismos de normalización (IETF e ITU-T) Protocolos que se van a presentar según escenarios: Protocolos de señalización entre terminales VoIP nativos H.323 de la ITU.T SIP (Session Initiation Protocol) del IETF Protocolos de señalización de llamadas telefónicas a través de red IP MEGACO /H.248 del IETF e ITU-T: pasarelas de voz SIGTRAN (grupo de trabajo del IETF): pasarelas de señalización

Señalización entre terminales VoIP H.323 y SIP: No son específicos de VoIP Permiten comunicación con usuarios PSTN a través de pasarelas Entre terminales VoIP nativos: servidor SIP o vía gatekeeper H.323

H.323 (I) Soporte multimedia sobre redes de conmutación de paquetes : IP caso particular (aplicación más difundida) Dos o más participantes. Arquitectura muy completa: Tipos y características de los equipos Servicios que soporta Protocolos en el plano de usuario Protocolos en el plano de control Estándar consolidado  sistemas ampliamente utilizados en mercado: Numerosos equipos Numerosas aplicaciones Actualmente el protocolo SIP empieza a cuestionar el liderazgo de los sistemas H.323.

Elementos de H.323 Terminales Gatekeepers Unidades multiconferencia Concentradores Gatekeepers Adaptador PC Teléfonos IP Unidades multiconferencia Terminales Pasarelas COMPONENTES DEL SISTEMA

Protocolos de H.323 (I) ARQUITECTURA DE PROTOCOLOS “Paraguas” Serie H del ITU-T General H.200–H.219 Transmission multiplexing and synchronization H.220–H.229 Systems aspects H.230–H.239 Communication procedures H.240–H.259 Coding of moving video H.260–H.279 Related systems aspects H.280-H.299 Systems and terminal equipment for audiovisual services H.300–H.399

Protocolos de H.323 (II) Nivel de Aplicación (7): Códecs de voz (G.7xx) Códecs de vídeo (H.26x) Aplicaciones de datos (T.12x)

Protocolos de H.323 (III) Señalización: H.225.0 y H.245 Estándar de seguridad: H.235 Transporte de audio, video o datos: RTP, RTCP y T.12x Servicios suplementarios: H.450.x Nivel de Transporte (4):

Protocolos de H.323 (IV) Nivel de Transporte (4): Señalización RAS (Registration, Admission and Status): Recomendación H.225.0 Terminales – Gatekeeper  El canal RAS se abre antes de establecer la conexión entre terminales. Se transporta con tramas UDP Autenticación del terminal Registro en la zona Solicitud de participación en una sesión

Protocolos de H.323 (V) Nivel de Transporte (4): Señalización Q.931 Recomendación H.225.0 Terminal – Terminal  Se transporta con tramas TCP Procedimientos de control de llamada Soporte de servicios suplementarios Señalización entre terminales directamente o a través del gatekeeper (modo routed)

Protocolos de H.323 (V) Nivel de Transporte (4): Señalización H.245 Gobierna la comunicación multimedia Terminal – Terminal  Se transporta con tramas TCP Intercambio de datos (Audio y video) Negocia las características de los canales lógicos en una sesión Mensajes de control de flujo

Protocolos de H.323 (VI) RESUMEN: Se establecen dos canales de señalización para audio Terminal- Gatekeeper (RAS) Terminal-Terminal (Q.931) Se establece un canal lógico de control para la sesión (audio, video y datos) Terminal-terminal (H.245)

Protocolos de H.323 (VII) EJEMPLO de llamada H.323

Protocolos de H.323 (VIII) EJEMPLO de llamada H.323

Protocolos de H.323 (IX) 1.- T1 le envía un mensaje RAS ARQ sobre el canal RAS al gatekeper para registrarse. 2.- El gatekeeper confirma la admisión de T1 mandando ACF. Dentro de ese mensaje le esta informando que utilice direct call signaling. 3.- T1 le envia a un mensaje H:225 setup a T2 requiriéndole la conexión. 4.- T2 responde con un mensaje H.225 call proceeding a T1. 5.- Ahora T2 debe registrarse ante el gatekeper por lo que le envía un RAS ARQ en el canal RAS. 6.- El gatekeeper le confirma la admisión con un RAS ACF. 7.- T2 alerta a T1 sobre el establecimiento de la conexión mandando un mensaje H.225 alerting. 8.- T2 confirma la conexión enviando un mensaje H.225 connect, lo que implica que la llamada ya esta establecida.

Protocolos de H.323 (X) 9.- El canal de control H.245 se establece entre T1 y T2. T1 envía un mensaje H.245 TerminalCapabilitySet a T2 para negociar el codec (T1 informa su lista de codecs disponibles). 10.- T2 contesta a T1 con un H.245 TerminalCapabilitySetAck. 11.- T2 envia un mensaje H.245 TerminalCapabilitySet a T2 para negociar el codec (T2 informa su lista de codecs disponibles). 12.- T1 contesta a T2 con un H.245 TerminalCapabilitySetAck. 13.- T1 abre un logical chanel que es el canal unidireccional por el cual viajará el audio o video. Para ello usa un mensaje H.245 OpenLogicalChannel. Dentro de ese mensaje incluye el puerto para establecer el canal RTCP. 14.- T2 contesta a T1 con un mensaje H.245 OpenLogicalChannelAck que confirma el establecimiento del canal unidireccional. Dentro de éste mensaje envía a T1 el puerto RTP que T2 reservó para T1 y el puerto RTCP recibido de T1 anteriormente. 15 .- T2 abre un logical chanel que es el canal unidireccional por el cual viajará el audio o video. Para ello usa un mensaje H.245 OpenLogicalChannel. Dentro de ese mensaje incluye el puerto para establecer el canal RTCP. 16.- T1 contesta a T2 con un mensaje H.245 OpenLogicalChannelAck que confirma el establecimiento del canal unidireccional. Dentro de éste mensaje envia a T2 el puerto RTP que T1 reservó para T2 y el puerto RTCP recibido de T2 anteriormente.

Protocolos de H.323 (XI) 17.- T1 envía el stream de audio o video encapsulado en RTP a T2 18.- T2 envía el stream de audio o video encapsulado en RTP a T1 19.- T1 envía mensajes RTCP a T2 20.- T2 envía mensajes RTCP a T1

Protocolos de H.323 (XII) 21.- T2 inicia la liberación de la llamada. Envía un mensaje H.245 EndSessionCommand a T1. 22.- T1 libera la llamada y confirma la liberación mandando un mensaje H.245 EndSessionCommand a T2. 23.- T2 termina de confirmar la liberación enviando un mensaje H.225 release complete a T1. 24.- T1 y T2 se desvinculan del gatekeper enviándole un mensaje RAS DRQ. 25.- El gatekeeper confirma la desvinculación de T1 y T2 mandandoles un mensaje RAS DCF a ambos.

Comunicaciones multimedia SIP Alternativa del IETF al estándar H.323 del ITU-T Características: Arquitectura genérica : Cliente/servidor Intercambio de mensajes de texto 1ª especificación: RFC 2543 (marzo 1999) Aumenta el número de aplicaciones y productos: Teléfonos SIP, clientes de telefonía, mensajería instantánea... PC: servidores SIP, pasarelas VoIP... http://www.pulver.com/products/sip/ SIP bake-offs Interés de la comunidad internacional: SIP es soporte de aplicaciones UMTS (3GPP: 3rd Generation Partnership Program) Principal ventaja: menor complejidad 

Modelo SIP Cliente Servidor Petición Respuesta Modelo cliente-servidor: Cliente: envía una petición Teléfono SIP o pasarela origen Servidor: responde Teléfono SIP o pasarela destino Transacción: petición + [respuesta(s) provisional(es)] + respuesta final Cliente Servidor Petición Respuesta

Sistemas SIP Dos tipos de sistemas: Agentes de usuario: sistemas finales capaces de iniciar o terminar una sesión UAC: Agente de usuario cliente UAS: Agente de usuario servidor Ej: Terminal SIP (PC o teléfono) UAC + UAS Contestador: UAS Servidores: Sistemas intermedios Facilitan el encaminamiento Opcionales

Mensajes SIP: Peticiones PETICIONES de la versión inicial: INVITE: invitación del llamante ACK: fin de establecimiento (respuesta del llamante a la aceptación del llamado) CANCEL: cancela petición en curso BYE: Abandono de un participante en una sesión múltiple OPTIONS: consulta a un agente de usuario sus capacidades REGISTER: registro de la localización actual de un usuario NORMA GENERAL: Excepto ACK todas las peticiones necesitan respuesta

Mensajes SIP: Respuestas RESPUESTAS: códigos numéricos PROVISIONALES: (no terminan la transacción) 1XX (Informativas): petición procesada pero no completa (trying, ringing, forarded, queued...) FINALES: (terminan la transacción) 2XX (Éxito): petición completada con éxito en el extremo remoto, 200 =“OK” 3XX (Redirección): llamante debe redirigir su petición hacia otra ubicación; “moved temporarily”, “moved permanently”, ... 4XX (Fallo de petición): la petición recibida no puede cursarse. Se sugiere modificación y reintento; ”bad request”, “timeout”, “busy here”, “user not found”... 5XX (Error del servidor): al procesar la información. Se sugiere reintentar; “not implemented”, “version not supported”, ... 6XX (Fallo global): petición no puede ser cursada. Sin reintento; “busy everywhere”, “user does not exist anywhere, session not acceptable, ...)

Ejemplo SIP

Ejemplo SIP

Protocolo de Descripción de Sesión (SDP) Estándar de internet del grupo de trabajo MMUSIC del IETF Especificado en la RFC2327 (abril-1998) Norma que describe el formato de los mensajes en una sesión multimedia: nombre de la sesión, motivo, instante de inicio y final, tipo de medios involucrado, códecs a emplear, direcciones IP y puertos UDP para el flujo RTP,… Se negocian las características de una sesión concreta entre extremos heterogéneos: intercambio de mensajes SDP Uso de SDP no es exclusivo del protocolo SIP. Se utiliza en otros ámbitos (ej: protocolo MEGACO/H.248)

Alta (facilita integración con otros protocolos IP) Comparación H.323/SIP H.323 SIP Origen ITU-T IETF Codificación Binaria Textual Transporte de señalización TCP/UDP UDP Tiempo de establecimiento ~ 5 x tpo ida/vuelta ~ 13 mensajes (TCP) 1.5 x tpo ida/vuelta 3 mensajes Disponibilidad comercial Alta En auge Flexibilidad y extensibilidad Baja Alta (facilita integración con otros protocolos IP) Complejidad

Señalización de llamadas telefónicas 2º gran escenario Surge con la liberalización del servicio telefónico (fin de los 90) No existen terminales IP nativos El tránsito tiene que incluir voz + señalización: Pasarelas VoIP con señalización  coste equivalente a central telefónica Controlador remoto de pasarelas: “central telefónica distribuida”