VoIP
description
Transcript of VoIP
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)
Señal de voz
Codificación
Empaquetado Red de paquetes (IP, FR, ATM)
Señal de voz
Decodificación
Desempaquetado
Problemas de flujo: • esperas variables • pérdidas de paquetes
Recepción: • Espaciamiento no constante• Flujo incompleto
Usuario: Degradación de
la voz
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
Tipo de codificación
PCM ADPCM ADPCM ADPCMLD-
CELPCS-
ACELP MP-MLQ/
ACELPRPE-LTP
Tasa binaria (Kbits/s)
64 3216/24/ 32/40
16/24/ 32/40
16 8 6,4/5,3 13
Complejidad (MIPS)
0,1 10 12 12 33 22 16/18 2,5
Retardo codificador (ms)
0,125 0,125 0,625 0,125 0,125 15 37,5 20
Calidad (MOS) 4,2 4,0 4,0 4,0 4,0 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 )
Red de paquetes
RTC RTC Pasarela Pasarela
Eco
Llamada
Desadaptación de impedancias en la
conversión 2/ 4 hilos
Desadaptación de impedancias en la conversión 2/ 4 hilos
Respuesta
Eco
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
t
Retardo A-C
Retardo A-B
Red de paquetes
A B C
Retardo variable (colas en los nodos)
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
1 2 3 4 6
t
t
Transmisión
Recepción
1 2 3 4 5 6
1 2 3 4 6
t
t
Transmisión
Recepción
Retardo: Rmax-Rmin
5
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
• Norma RFC 1889: Protocolos RTP y RTCP
RTCP UDP
IP Nivel 2
RTCP UDP
IP Nivel 2
RTP UDP
IP IP Nivel 2 Nivel 2
RTP UDP
IP IP Nivel 2 Nivel 2
Red IP
RTCP
RTP
RTP UDP
IP Nivel 2
RTP UDP
IP Nivel 2
RTP UDP
IP IP Nivel 2 Nivel 2
RTP UDP
IP IP Nivel 2 Nivel 2
Terminal VoIP
Terminal VoIP
Información periódica del estado y calidad de la comunicación puertos UDP inmediatamente superiores
Audio y video.
Puertos UDP pares e independientes en cada extremo
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 RTP0 7 15 31
V P X CC M PT SN
Timestamp
Identificador SSRC
Identificador CSRC
Extensión de cabecera
Carga útil
Tipo de carga (7): formato de
carga útilInstante de muestreo (32)
Versión RTP (2)
P=1 incluye
relleno (1)
X=1 Incluye
extensión de
cabecera (1)
Número de identificadores CSRC
presentes en la cabecera (4)
Marca (1). Depende
de PTIdentificador de
fuente (32)
Identificador de contribuciones en una
mezcla (32)
VideoH.263H.261
3431
Audio
PCM, ley
PCM, ley A
G.722G.723G.728G.729
08941518
Tipo de carga
CódecPTTipo de carga
(7): formato de carga útil
Número de secuencia (16)
Cab
ecera
básic
a(1
2 o
cte
tos)
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 IP20 octetos
UDP8 oct
RTP12 oct
Carga útilN oct
40 octetos
Ancho de banda para sesión VoIP (II)
CódecTasa
nominal (Kbits/s)
Retardo empaqueta
do (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 80 82.4 106
G.729
8
10 10 40 44.8 84.8
20 20 24 26.4 42.4
40 40 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
Terminal VoIP
Terminal VoIP
Red IP
RTC
Servidor
Pasarela
Señalización: H.323 o SIP
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.
Pasarela Pasarela
Guardián
Elementos de H.323 Terminales
COMPONENTES DEL SISTEMA
Teléfonos IP Adaptador PC
Concentradores Pasarelas
Gatekeepers
Unidades multiconferencia
Protocolos de H.323 (I)
ARQUITECTURA DE PROTOCOLOS
• “Paraguas”
H.245
Control
H.225.0 Q.931
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)• Nivel de Transporte (4):
Transporte de audio, video o datos: RTP, RTCP y T.12x
Servicios suplementarios: H.450.x Estándar de seguridad: H.235 Señalización: H.225.0 y H.245
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 terminalRegistro 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 llamadaSoporte de servicios suplementariosSeñ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ónMensajes 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.
ARQ (1)
ACF (2)
Setup (3)
Call Proceeding (4)
ARQ (5)
ACF (6)
Alerting (7)
Connect (8)
H.225
RAS
T1 GK T2
Protocolos de H.323 (X)
TerminalCapabilitySet (9)
TerminalCapabilitySetAck (10)
TerminalCapabilitySet (11)
H.245
T1 GK T2
TerminalCapabilitySetAck (12)
OpenLogicalChannelAck (14) OpenLogicalChannel (15)
OpenLogicalChannel (13)
OpenLogicalChannelAck (16)
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)
RTP media stream (17)
RTP media stream (18)
RTP y RTCP
T1 GK T2
RTCP messages(19)
RTCP messages (20)
17.- T1 envía el stream de audio o video encapsulado en RTP a T218.- T2 envía el stream de audio o video encapsulado en RTP a T119.- T1 envía mensajes RTCP a T220.- T2 envía mensajes RTCP a T1
Protocolos de H.323 (XII)
EndSessionCommand (21)
H.245
T1 GK T2
EndSessionCommand (22)
Relese Complete (23)
H.225
RAS
DRQ (24)
DCF (25)
DRQ (24)
DCF (25)
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
• 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: RespuestasRESPUESTAS: 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
Llamante Llamado
INVITE
180: Ringing
200: OK
ACK
SESIÓN
BYE
200: OK
Red IP
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)
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/vuelta3 mensajes
Disponibilidad comercial Alta En auge
Flexibilidad y extensibilidad
Baja Alta (facilita integración con otros protocolos IP)
Complejidad Alta Baja
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”
Red IP
RTC
Controlador
Pasarela
RTC
Pasarela
Señalización: MEGACO y SIGTRAN