Audio-vía-IP - ICC Broadcast

I
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
Una guía profesional para entender su funcionamiento
Publicado por: ICC Broadcast | Hardata España.
http://www.iccbroadcast.com
Autores: Hans-Heinrich Hansen, Christian Diehl, Uwe Andersen, Jan Simon,
Werner Ludwig, Jörg Rimkus, Detlef Wiese.
Traducción: Enrique Arce
Edición: Patricia Lespinard
1ª Edición.
Flashman, Centauri y Mayah son marcas registradas
por Mayah Comunications GmbH. ICC Broadcast e ICC Broadcast | Streaming Services son
marcas registradas por itzurun Comunicaciones S.L.
Layer 2 licenciado por Audio MPEG Coding Technologies.
Layer 3/mp3PRO licenciados por Thomson/Franhoufer Institute.
AAC / HE licenciados por Via Coding Technologies.”
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
Abstracto
La transmisión sobre redes IP está incrementándose de manera muy importante en la
industria de la radio a medida que se incrementa la viabilidad y paralelamente decrecen sus
costes. El suministro de líneas dedicadas y de RDSI está decreciendo mundialmente por eso,
tarde o temprano, deberemos hacer frente a la carencia de este servicio por parte de las
compañías telefónicas. A estas alturas algunas de las trasmisiones RDSI ya están siendo
transportadas a través de backbones IP.
El siguiente compendio trata precisamente de estos tópicos, desde lo más básico hasta las
aplicaciones de hoy en día. No se puede considerar un manual completo, sin embargo
destaca muchos aspectos interesantes del audio-vía-IP tanto para principiantes como para
usuarios con experiencia.
Empezaremos con el capítulo de Audio Comprimido IP, el cual nos ofrecerá una ligera
introducción al Audio-vía-IP y nos enseñará algunas referencias.
1
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
Audio Comprimido IP
UDP, RTP, SIP... Protocolos IP ¿Para qué son todos ellos?
El protocolo elegido determina las características de la transmisión de audio en una red. Para
determinar unos estándares de la calidad de la señal se necesita seleccionar un protocolo
apropiado.
RDT/UDP son los formatos de compresión típicos para las redes corporativas y las VPNs con
líneas dedicadas. El protocolo SIP se usa en Internet, y además, es particularmente popular para
aplicaciones VoIP.
SIP (Protocolo de Inicio de Sesión)
El protocolo de Inicio de Sesión (SIP) es un protocolo basado en texto para la negociación de
conexiones ubicadas en el Protocolo Internet (IP). El SIP se usa simplemente para tomar la señal
entre dos partes individuales de negociación. El transporte de los datos de audio corre de forma
separada a la negociación (similar al RDSI). Los datos de audio se enrutan y transportan a través
de una protocolo diferente. Si TCP o UDP están disponibles para la negociación, RTP se usa
mayoritariamente para el transporte de datos de audio.
Conexiones SIP como sustitución del RDSI
Las nuevas conexiones SIP en el Internet pueden ser consideradas como un equivalente al RDSI
si la transmisión es libre de pérdidas y de baja latencia. Esto puede ser compensado con un
ancho de banda garantizado. Por ejemplo usando RSVP y FEC.
VPNs con ancho de banda garantizado como sustitución de conexiones E1 y X.21
La redes privadas virtuales también llamadas VPNs pueden sustituir hoy en día a las conexiones
E1 o X.21 si se garantiza una banda ancha estable.
Usando IP en líneas E1 y redes ATM existentes
El protocolo IP también puede aplicarse en conexiones E1 o ATM. Esto permite el uso simultáneo
de audio/vídeo y señales de datos. La reserva del ancho de banda apropiado se puede configurar
desde los routers.
3
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
Formatos de codificación de Audio ¿En qué aplicaciones usar cada uno de ellos?
La multitud de formatos de codificación de audio disponibles puede llegar a ser confusa. Una
correcta selección debe basarse en criterios tales como la compatibilidad, la calidad y la
latencia. Mientras que MPEG4 HE AACv2 proporciona una calidad excelente con unos índices
binarios muy bajos (por ejemplo 48kbps estéreo), las transmisiones transparentes AES/EBU se
usan en redes con una mayor ancho de banda para lograr una pérdida mínima y con una calidad
de hasta 3 Mbit/s.
Migración de RDSI a IP y viceversa
El proceso de migración de las infraestructuras RDSI existentes a infraestructuras IP lleva un
tiempo y requiere una solución técnica que permita la transcodificación de los formatos y el
transporte entre ambos tipos de redes. Esta solución se presta a través de Gateways RDSI-IP.
FEC (Avance de Corrección de Errores)
El FEC (Avance de Corrección de Errores) permite detectar y/o corregir errores añadiendo datos
al stream, con el fin de evitar que los datos de la retransmisión o de la corrupción y los costes
asociados de una mayor banda ancha incrementen el retraso ya que permite al receptor con la
información recibida recomponer la trama de datos que se recibe.
IP Overhead (Carga útil IP)
Para las transmisiones IP, el stream de datos consiste en una trama útil (datos de audio, tramas
MPEG, etc.) y una cabecera IP. En el caso del protocolo UDP la cabecera tiene 46 Bytes /
paquete y consiste en 8 Bytes de la cabecera UDP, 20 Bytes e la cabecera IP y 18 Bytes del
protocolo Ethernet IEEE802.3. El protocolo RTP tiene 58 Bytes de cabecera por paquete, 12
Bytes de RTP, 8 Bytes de UDP, 20 Bytes de IP y 18 Bytes de IEEE802.3. La trama útil IP relativa
es calculada como un porcentaje de la trama útil original.
Stream de transporte MPEG vía ASI, Stream de Transporte MPEG via IP
El stream de transporte MPEG, denominada MPEG TS es usado principalmente en entornos
DVB e ipTV. Es un formato que contiene uno o más streams de audio y/o audio y vídeo los
cuales generalmente necesitan alcanzar Set-Top-Boxes (STB) como destino final.
¿Hay estándares disponibles?
Para alcanzar implementaciones comunes, la EBU ha establecido el grupo de trabajo N/ACIP.
En Septiembre de 2007 fue presentado su primer cuaderno de recomendaciones..
4
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
RTP (Realtime Transport Protocol)
Es un protocolo de sesión para redes basadas en IP las cuales usan UDP (User Datagram
Protocol) como protocolo de transporte. En contraste con una implementación UDP pura, RTP
garantiza la correcta secuencia de de paquetes en el lado de recepción.
RTCP (RTP Control Protocol)
Trabaja por encima del protocolo RTP. No interfiere con el stream de datos real y provee
algunos datos de intercambio entre los participantes en la sesión de streaming. Recibiendo el
informe acerca de los paquetes enviados, los paquetes perdidos, retardo de bucle, jitter, etc. El
stream se adapta automáticamente a las condiciones particulares de la red en cada momento.
SDP (Sesion Description Protocol)
Las descripciones de las sesiones de streaming multimedia con SDP, incluyen parámetros
importantes de inicialización e información. Son usadas para invitar a participantes, para
anunciar el el inicio de una sesión o para inicializar la conexión de alguna otra manera.
Es usado para anunciar la información provista por SDP a una dirección multicast y dar a los
potenciales clientes una vista por encima de los contenidos disponibles en la (sub) red. Mayah
también soporta los SAP no estándar.
RTSP (Real Time Streaming Protocol)
En un protocolo de aplicación para usar en sistemas de streaming de medios. Le permite a
los clientes conocer acerca de los contenidos disponible para el streaming y los habilita para
elegir el stream apropiado, así como controlar un servidor de streaming de medios con los
comandos típicos, tales como “Play” o “Pause”.
5
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
1.- Audio e introducción al IP
1.1.- Fundamentos Básicos de IP.
1.2.- Líneas de paquetes conmutados frente a conexiones digitales punto a punto.
2.- Codificación de Audio por IP: Latencia vs Bitrate
2.1.- G.711.
2.2.- G.722.
2.3.- MPEG Layer 2.
2.4.- MPEG Layer 3.
2.5.- MPEG 4 HE AAC.
2.6.- apt-X y Enhanced apt-X.
2.7.- Audio lineal y AES/EBU transparente.
2.8.- Multicanal.
3.- IP como plataforma de las modernas redes de Comunicaciones y Broadcast.
3.1.- Requerimientos básicos para el transporte multimedia.
4.- Comunicaciones Conmutadas en la Internet Pública
4.1.- Comparación RDSISIP.
4.2,- ¿Como trabaja SIP?.
4.3.- Seguridad operacional.
4.4.- SIP para enlaces multimedia de alta calidad.
4.5.- SIP -> Futuro.
5.- Consideraciones Prácticas para SIP y audio-vía-IP
5.1.- Requerimientos para comunicaciones basadas en SIP a través de la Internet Pública.
5.2.- Requerimientos para otras conexiones basadas en IP a través de la Internet Pública|
Unicast frente a Multicast.
7
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
6.- Esquemas de aplicaciones IP Típicas e IP/RDSI
6.1.- Transmisión desde una Unidad de Reportero Móvil a múltiples estudios con
IP Multicast vía UMTS/3G.
6.2.- Transmisión desde una Unidad de Reportero Móvil a múltiples estudios con
IP Multicast vía WiFi o WiMax.
6.3.- Transmisión punto a punto por IP (Terrestre/Satélite) con backup por RDSI con
activación automática.
6.4.- Transmisión punto a 8 puntos por IP (Terrestre/Satélite) con backup por RDSI de
activación automática.
6.5.- Transmisión 7+1 punto a punto en modo AES/EBU Transparente vía IP con
Una bitrate de 12 Mbps.
6.6.- Distribución Multicast a través de IP.
6.7.- Aplicación Gateway Multipunto SIP/RDSI con conversión de formatos de audio.
6.8.- Aplicación Gateway RDSI/SIP con conversión de formatos de audio.
8
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
1.- Audio e introducción al IP
1.1.- Fundamentos Básicos de IP
De una forma similar al modelo capa OSI (Open Source Interconection), existe un modelo de
referencia para la familia del protocolo de Internet TCP/IP. El cual describe una estructura y la
interacción entre los diferentes protocolos de red en 4 capas: Capa de red, Capa Internet, Capa
de transporte y capa de aplicación y protocolos relacionados incluidos para determinadas tareas
como Telnet, FTP (Figura 1).
FIG. 1
Modelo de referencia ISO/OSI
Capa 7
Capa de Aplicación
Define los protocolos de aplicación
(Ej. FTP, TELNET, SMTP)
Capa 6
Capa de Presentación
Describe la presentación de los datos
(Ej.ASCII, UNICODE)
Capa 5
Capa de Sesión
Conecta y desconecta enlaces, login y logout
Capa 4
Capa de Transporte
Transporte de datos entre las partes de la comunicación
(Ej. TCP, UDP)
Capa 3
Capa de Red
Interconecta estaciones de red o segmentos (Ej. IP)
Capa 2
Capa de Enlace de Datos
Protocolo de transferencia para datos y transferencia segura
(Ej. HDLC, SLIP, PPP)
Capa 1
Capa Física
Especifica el transporte de bits en el medio de enlace
(Ej. Modulación, asignación de pines en el conector)
ISO/OSI modelo de referencia a TCP/IP modelo de referencia
Capa de Aplicación
Capa de Aplicación
FTP, HTTP
Capa de Presentación
Capa de Sesión
Capa de Transporte
Capa de Transporte
RTP/UDP para
transporte multimedia
Capa de Red
Capa de Red
Protocolo Internet
Capa de Enlace de Datos
Capa Física
Capa de red
IEEE 802.3 en Ethernet o
IEEE 802.11 en Wifi
9
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
Para que se produzca el intercambio de información entre aplicaciones son necesarias un
mínimo de 3 direcciones. Los socios individuales dentro de un segmento de la red (Ethernet
IEEE802.3) son identificados mediante una dirección MAC (Media Access Control) de 6 Bytes.
Esta dirección ha de ser única dentro de un segmento. Las direcciones MAC son asignadas
generalmente por los fabricantes e identifican a estos en los 3 primeros Bytes.
Con el fin de reconocer a los participantes en Internet, son utilizadas direcciones de Internet de 4
Bytes de longitud (IPv4) o de 16 Bytes de longitud (Ipv6). La relación entre la dirección MAC
física y la dirección lógica IP se alcanza a través del protocolo de resolución de direcciones
(ARP). Las direcciones IP del emisor y el receptor son parte de la cabecera del protocolo IP.
La tercera dirección es el puerto supuesto o socket number. Esto identifica cierto uso del
participante. El número de puerto (16 Bit) está localizado dentro de la capa de transporte.
Ciertos números de puerto son asignados a ciertas aplicaciones, Ej FTP siempre usa el puerto
20/TCP para los datos y el puerto 21/TCP para el control de la información. Telnet usa el puerto
23 y SMTP siempre usa el puerto 25. Puedes encontrar una lista de completa de los puertos y
sus asignaciones en www.iana.org/assignments/port-numbers . IANA (Internet Assigned
Numbers Authority) es la responsable de la asignación de números de puerto registrados.
1.2.- Líneas de paquetes conmutados frente a conexiones digitales punto a punto.
En el broadcast, las conexiones digitales punto a punto son usadas generalmente para el
transporte de larga distancia de datos multimedia. Normalmente esas líneas proveen de una
alta disponibilidad, un retardo constante, un insignificante jitter (*) sin secuencia de errores o
pérdidas de paquetes.
(*) Jitter: (Cambio o variación en cuanto a la cantidad de latencia entre paquetes de datos que se
reciben).
El uso de los servicios y redes de Internet para transferencia de archivos, pero también
incrementándose para transmisiones en directo en exteriores, distribución y contribución está
en permanente crecimiento. En 2001 la ORF (Radio Televisión Pública Austriaca) comenzó con
la implementación de su L-NET. En aquel tiempo el foco eran principalmente las redes
corporativas privadas, en cambio hoy la red pública Internet ha alcanzado una mayor
importancia.
10
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
Aunque no planeado originalmente para Internet, el progresivo declive de las líneas RDSI en
broadcast a nivel mundial, significa que más y más audio se está ahora transportando usando
líneas de transmisión de paquetes. Los inventores de Internet definieron el protocolo Internet
en 1981 e incluyeron algunas características para permitir que fuera usado en propósitos de
tiempo real. En un momento en el que la conectividad estándar no lo soportaba. La cabecera IP
contiene una etiqueta (flag), denominada tipo de servicio (type-of-service), la cual es usada para
marcar la prioridad de los datos que contiene. En la Internet pública estas etiquetas son
ignoradas por los routers o reiniciadas. La razón es obvia: Tan pronto como la etiqueta tipo de
servicio es aplicada realmente como por ejemplo para la comunidad de jugadors de Internet, se
podría utilizar inmediatamente esto para los juegos en detrimento de otro tipo de servicios.
Para una transmisión fiable de los datos multimedia a través de una red basada en paquetes, es
necesario satisfacer unos requerimientos particulares: Retardo, Jitter y la disponibilidad de la
red deben estar dentro de unos parámetros conocidos y convenientes para una aplicación
broadcast 24/7. El ancho de banda necesario para la señal de transmisión debe estar disponible
en todo momento. También debe ser conocida cualquier secuencia de errores que ocurra en el
orden de los datagramas recibidos.
Para un servicio estable se han de aplicar las herramientas necesarias. El jitter máximo define el
tamaño del buffer de compensación en el lado del receptor. Las posibles pérdidas de paquetes
deben ser regeneradas usando FEC (Forward Error Correction). Las secuencias de errores han
de ser evitadas usando el apropiado protocolo en la capa de transporte (ej. RTP, Realtime
Transport Protocol).
La influencia de ciertos protocolos y FEC tiene un impacto medible en la latencia del transporte.
Una diferencia importante con las líneas digitales dedicadas convencionales es la sobrecarga
causada por los mismos protocolos.
Cada datagrama Ethernet ocupa 18 Bytes para la cabecera IEEE802.3 y 8 Bytes para su prefijo.
La cabecera IP ocupa 20 Bytes, la cabecera UDP ocupa 8 Bytes adicionales y la cabera opcional
RTP ocupa otros 12 Bytes. En total, se transmiten 66 Bytes de cabecera cuando se transmite un
datagrama RTP. Si en un datagrama RTP se quiere transportar una trama MPEG 2 Layer 3 con
16 kHz de frecuencia de muestreo y un bitrate de 24 kbps que necesita transportar 48 Bytes, se
necesitara un ancho de banda total de 57 kbps.
Si usamos MPEG 4 AAC en lugar de MPEG 2 Layer 3, no sería posible realizar un calculo exacto
del ancho de banda requerido porque la longitud de las tramas de AAC Audio cambian de trama a
trama lo que provoca que no sea posible calcular la relación entre los datos de audio y la
cabecera (sobrecarga). Con el fin de minimizar el impacto de la sobrecarga del protocolo, más
de un frame de audio pueden ser combinadas en un datagrama. Esto incrementa la latencia
porque deben ser recolectados primero un determinado número de tramas.
11
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
Estructuras del Protocolo
Encapsulado de datos
Ethernet
IP
TCP/UPD RTP
Capa de Aplicación
Datos
Capa de transporte
Capa de internet
Capa de red
APLICACION
Cabecera
Cabecera
Datos
Cabecera
Cabecera
Datos
Cabecera
Cabecera
Datos
FIG. 2
Aplicando esto a la señal MPEG 2 Layer 3 mencionada anteriormente, significa que una
carga útil (payload) óptima de 30 frames completos de audio. Cada frame de audio
contiene 576 muestras y a una frecuencia de muestreo de 16 kHz, exactamente 36 ms de
audio. Así que se crea una latencia de 1044 ms (Figura 3).
Otra opción para reducir la sobrecarga del protocolo es tan simple como eliminar las
cabeceras IP, UDP y RTP, que es una técnicas usada por sistemas tales como
Ethersound de Digigram y Cobranet de Cirrus Logic. Los datos de audio son
trasportados como carga útil (payload) con los paquetes ethernet IEEE802.3. En este
caso, las direcciones IP se pierden y solo pueden ser identificados participantes dentro
del mismo segmento de red a través de la dirección MAC. Una transmisión fuera del
segmento, usando un gateway por ejemplo no es posible. Incluso si una dirección MAC
de un participante externo es conocida el router no podrá encontrarla porque la
dirección lógica del segmento de la red externa está perdida.
12
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
FIG. 3
% de sobrecarga IP (Ej. MPEG Layer 3, 48 KHz, Tamaño de paquetes = 180 bytes)
30%
25%
19,7%
20%
Sobre carga IP
23,96%
23,7%
19,17%
15,97%
15,97%
15%
13,69%
11,98%
13,69%
10%
5%
0%
9,58%
7,99%
MPEG L3 UDP
6,85%
Frecuencia de muestreo = 48 KHz
5,99%
Bit rate = 256 kbps
4,79%
Longitud de frame = 256 (bitrate)/48 (Frec. muestreo) * 144 (bytes) = 768 Byte
Sobrecarga IP = (( 768 bytes + 46 bytes) / 768 bytes - 1) x 100% = 6 % aprox.
32
40
48
56
64
80
96
112
128 160
192
224
256 320
Bitrate in Kbit/s
% de sobrecarga
25%
23,96%
Ej Apt-X (16 bit) / Eapt-X, UDP
23,96%
Sobre carga IP
23,96,%
19,17,%
20%
15%
23,96,%
23,00%
Para paquetes de 180 bytes
11,06,%
10,27,%
11,50,%
4,49,%
4,42,%
11,50,%
10,65,%
4,42,%
4,36,%
9,58,%
10%
Para paquetes de 390 bytes
Para paquetes de 1024 bytes
4,49,%
4,36,%
5%
0%
16 BIT
MONO
16 BIT
STEREO
20 BIT
MONO
20 BIT
STEREO
24 BIT
MONO
24 BIT
STEREO
Apt-X/Eapt-x, tamaño de bloque fijo, Resolución = 20 Bit Estéreo.
Carga Útil = (180 (Tamaño de paquete) / 80 (Tamaño de bloque) redondeado al entero superior * 80 = 240 bytes.
Sobre carga IP = ((240 bytes + 46 bytes) / 240byte -1) * 100% = 19,7 %
13
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
2.- Codificación de Audio por IP: Latencia vs Bitrate
Durante los últimos 25 años, se han establecido varios algoritmos de codificación en la industria
del broadcast (ej. J41, J57, MPEG Layer 2, 3) y también algunos algoritmos no estandarizados
tales como el apt-X o el ADPCM4SB. Debido a la multitud de demandas, no es fácil para un
operador elegir el bitrate, el modo de operación y la frecuencia de muestreo apropiadas. Y esa
dificultad se ha incrementado en los últimos años con la aparición de nuevos formatos de
compresión.
Además de los formatos ampliamente conocidos, otros provenientes de la telefonía como el
G.711 y el G.722 son aplicados en Broadcast junto a las más modernas y potentes variaciones
de AAC, tales como MPEG 2 y 4 AAC, HE AAC (aacPlus), HE AACv2, AAC ELD, audio lineal PCM y
transmisiones transparentes AES/EBU. Todos los formatos citados pueden además trabajar en
diferentes modos, mono, estéreo, a diferentes bitrates y frecuencias de muestreo e incluso
algunos pueden trabajar en modo multicanal (5.1/7.1).
El desarrollo de algoritmos de codificación está enfocado a la optimización de parámetros tales
como el bitrate, la calidad -después de múltiples codificaciones/decodificaciones-, la latencia y
la compatibilidad. Todos los algoritmos aquí descritos pueden ser categorizados de esta forma.
HE AACv2 ha sido desarrollado solamente para reducir el bitrate mientras se mantiene una muy
buena calidad de sonido. Por otro lado apt-X simplemente está enfocado a tener un retardo muy
pequeño.
Gracias al crecimiento del ancho de banda disponible hoy, están incrementando
considerablemente métodos de transmisión lineal a 16, 20 y 24 bits así como transmisiones
transparentes AES/EBU de 3,072 Mbit/s. Aquí la calidad y el retardo juegan un papel más
importante que el incremento del coste del ancho de banda.
No existe actualmente una investigación detallada de la cuota de mercado que tienen los
diferentes algoritmos de codificación en el mundo del broadcast. En cambio es ampliamente
asumido que el MPEG Layer 2 y el G.722 dominan, mientras que algoritmos como el audio
lineal, ADPCM, apt-X, Enhanced apt-X, así como el MPEG 4 estándar, HE AAC están
incrementando su cuota en determinadas aplicaciones.
Una discusión detallada sobre la elección del método más apropiado debe incluir
necesariamente consideraciones sobre calidad, flexibilidad, ancho de banda, latencia,
compatibilidad, estandarización, cuota de mercado y expectativas. En realidad, se puede
encontrar una solución óptima para cualquier sistema.
15
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
2.1.- G.711
Uno de los más importantes estándares de la ITU-T (International Telecomunications Union
Telecomunications) es el G.711 el cual digitaliza el audio en mono a una frecuencia de muestreo
de 8 kHz. Este algoritmo cubre el rango de frecuencias comprendido entre los 300 y 3.400 Hz.
En Europa se usan 64 kbps y en norte América 56 kbps para una comunicación clásica de
teléfono con G.711. Si un teléfono convencional necesita ser comunicado vía IP, G.711 es usado
en el sistema de VoIP. La latencia de G.711 no es representativa.
2.2.- G.722
Otro estándar ITU-T es G.722, el cual ofrece una mayor calidad de audio debido a sus 16 kHz de
frecuencia de muestreo. El bitrate de transmisión también es 64 kbps. (Ej. un canal B RDSI). Al
igual que G.711 la latencia de G.722 es muy baja.
Existen 2 posibilidades de sincronizar audiocódecs con G.722
G.722 con Señalización Inband H.221 (G.722/H221)
En el modo G.722/H.221 se ocupa un ancho de banda de 1,6 kbps para la información Inband la
cual es usada para la sincronización.
G.722 con Sincronización Estadística (G.722/SRT)
Con G.722/SRT (SRT Statistical Recovery Timing) los análisis estadísticos de la señal de audio
dan lugar al reconocimiento del comienzo de un Byte.
2.3.- MPEG Layer 2
Datando de 1.990, MPEG Layer 2 es todavía muy popular y ampliamente usado en aplicaciones
Broadcast. Las principales razones de su popularidad son su cascabilidad (codificacionesdecodificaciones simultáneas), su alta calidad de audio a bitrates altos y la disponibilidad en la
gran mayoría de dispositivos de hardware y software de una primera generación. MPEG Layer 2
soporta bitrates desde 8 a 384 kbps, siendo 256 kbps el bitrate ideal para transmisiones en
estéreo.
2.4.- MPEG Layer 3
Más conocido como mp3, este formato es muy usado en Broadcast cuando se necesita
consumir un menor ancho de banda que MPEG 2. MPEG Layer 3 soporta bitrates entre 8 y 320
kbps siendo 128 kbps el bitrate ideal para transmisiones en estéreo.
16
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
2.5.- MPEG 4 HE AAC
HE AAC es un desarrollo de AAC con mucho futuro usando SBR, Spectral Band Replication de
Coding Technologies (www.codingtechnologies.com). AAC es el algoritmo de codificación de
audio MPEG con mayor calidad de audio a 128 kbps estéreo. Debido a que muchas aplicaciones
necesitan cada vez bitrates menores, la compañía sueco-germana Coding Technologies inventó
la tecnología SBR, la cual permite AAC con bitrates de 32 o 48 kbps estéreo.
Aquí más del 90% del bitrate es usado todavía para la codificación convencional AAC, pero una
pequeña parte (< 4 kbps.) es usada para la información SBR. La parte AAC convencional es
muestreada con la mitad de la frecuencia de muestreo, 16, 22,05, 24 kHz con el resultado de una
mayor eficiencia de la codificación.
La unión entre SBR y AAC es una formato de alta calidad. Aunque no sorprende por su
transparencia real, puede ser sintetizado desde frecuencias de muestreo de 7/8 kHz, pudiéndose
alcanzar calidades de audio extremadamente buenas cercanas al CD usando bitrates muy bajos
de codificación. En conexión con HE AAC, permite muy altas calidades cercanas al CD, las cuales
son usadas actualmente por muchas aplicaciones y sistemas. Combinado con la denominada
codificación estéreo paramétrica, el algoritmo es conocido como HE AACv2 que provee una
asombrosa calidad de sonido a 16,20 y 24 kbps.
2.6.- apt-X y Enhanced apt-X
Apt-X es un sistema de codificación de baja latencia que usa ADPCM (Adaptive Differencial Pulse
Code Modulation). Un stream típico de datos ocupa 192 kbps para mono y tiene la ventaja de la
cascabilidad. Teóricamente la latencia mínima es de 3ms a una frecuencia de muestreo de 48
kbps. El algoritmo puede ser usado a otras múltiples frecuencias de muestreo y mejoras
recientes especialmente dirigidas al rango dinámico, han resultado en el Enhanced apt-X, el cual
usa palabras de longitud hasta 24 bit. Apt-X es uno de los formatos de audio más usados para
transmisiones de audio con bajo retardo, y su uso está muy popularizado en los estudios de
grabación.
Sus principales características son:
.- Compresión de datos 4:1:4
.- Codificación/Decodificación Mono/Estéreo.
.- Frecuencias de muestreo flexibles hasta 96 kHz.
.- Canal de datos adjunto de hasta 12 kbps.
17
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
2.7.- Audio lineal y AES/EBU transparente
El aumento de la disponibilidad de anchos de banda altos, el uso del audio lineal y el AES/EBU
transparente se ha convertido en una alternativa real. Audio Lineal es entendido como una señal
PCM con una longitud específica de 16, 20 o 24 bit y una frecuencia de muestreo fija. En el
mundo del broadcast es muy usual usar frecuencias de muestreo de 48 y 96 kHz lo que da como
resultado un ancho de banda de 1,5 y 4,5 Mbps para una señal estéreo.
Una transmisión AES/EBU transparente puede incluir Dolby E o DTS dentro de la señal AES/EBU
sin ninguna conversión de frecuencia de muestreo (sino los datos codificados pueden
corromperse de forma irreversible). El ancho de banda de datos de las señales AES/EBU es de
3,072 Mbps con señales multicanal hay que multiplicar por esta cifra.
2.8.- Multicanal
La codificación multicanal 5.1 y 7.1 es soportada por variedad de formatos. En particular HE
AAC ofrece una codificación muy eficiente con bitrates por debajo de los 128 kbps. Enhanced
apt-X provee hasta 8 canales independientes con bitrates entre 1-2 Mbps mientras que los
formatos de audio lineal se van hasta los 18 Mbps.
FIG. 4.1
Algoritmos de codificación de audio: Calidades y retardos.
G.711
Muy bajo < 4 khz
G.722
Muy bajo < 8 khz
MPEG 1 CAPA 2
>45ms variable, hasta 20 kHz
MPEG 2 CAPA 2
>90ms variable, hasta 20 kHz
MPEG 1 CAPA 3
>80ms variable, hasta 20 kHz
MPEG 1 CAPA 3
>160ms variable, hasta 20 kHz
MPEG 2.5 CAPA 3
>300ms variable, hasta 20 kHz
Mp3 PRO
>300ms variable, hasta 20 kHz
MPEG 2/4 AAC
>110ms variable, hasta 20 kHz
MPEG 2/4 AAC LC
>45ms variable, hasta 20 kHz
MPEG 4 HE AACv2
>110ms variable, hasta 20 kHz
J.41
muy bajo 15 khz
ADPCM4SB/MICDA
muy bajo 15 khz
EAPT.X/APT.X
J.57
Audio Lineal (PCM)
muy bajo variable, > 20 kHz
muy bajo 20 khz
muy bajo variable, > 20 kHz
AES/EBU transparente
5.1/7.1 AAC UND HE AAC V2
Audio Lineal 8 canales
APT.X/EAPT.X 8 canales
>110ms variable, hasta 20 kHz
muy bajo variable, > 20 kHz
muy bajo variable, > 20 kHz
18
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
FIG. 4.2
Algoritmos de codificación de audio: Frecuencias de muestreo en Khz.
8
G.711
16
G.722
MPEG 1 CAPA 2
16
MPEG 2 CAPA 2
22.05
MPEG 1 CAPA 3
MPEG 1 CAPA 3
48
44.1
48
22.05
24
32
44.1
48
24
24
32
44.1
44.1
48
24
32
32
32
44.1
48
32
44.1
32
44.1
44.1
44.1
48
48
48
96
48
48
48
48
96
96
11,025
12
MPEG 2/4 AAC
8
11,025
12
16
MPEG 2/4 AAC LC
8
12
MPEG 4 HE AACv2
8
11,025
11,025
12
16
16
22.05
22.05
22.05
8
11,025
12
16
22.05
24
8
11,025
12
16
22.05
24
Mp3 PRO
32
J.41
ADPCM4SB/MICDA
EAPT.X/APT.X
44.1
16
8
MPEG 2.5 CAPA 3
32
32
24
48
J.57
AUDIO LINEAL
AES/EBU TRANSPARENTE
32
5.1/7.1 AAC UND HE AAC V2
8
8
8
AUDIO LINEAL 8 CANALES
APT.X/EAPT.X 8 CANALES
12
12
12
11,025
11,025
11,025
16
16
16
22.05
22.05
22.05
24
24
24
32
32
32
44.1
44.1
44.1
96
FIG. 4.3
Algoritmos de codificación de Audio: bitrates en kbps.
G.711
48
48
G.722
MPEG 1 CAPA 2
56
56
64
64
32
40
48
56
64..112
128..124
8..24
32
40
48
56
64..112
128..160
MPEG 1 CAPA 3
8..24
32
32
40
40
48
48
56
56
64..112
64..112
128..124 256
128..160
MPEG 2.5 CAPA 3
8..24
32
32
40
40
48
48
56
56
64..112
64..96
8..24
32
40
48
56
64..112
MPEG 2 CAPA 2
MPEG 1 CAPA 3
Mp3 PRO
MPEG 2/4 AAC
MPEG 2/4 AAC LC
MPEG 4 HE AACv2
16..24 32 40
8..24 32 40
48 56
48 56
256
320 384
320
32
128..160 256
64..112 128..160 256
64..112 128..160
264..320
264..320
J.41
384
768
ADPCM4SB/MICDA
EAPT.X/APT.X
32
40
48
56
64..112
128..160
256
320
576
384
J.57
AUDIO LINEAL
1920
64
..1536..
AES/EBU TRANSPARENTE
5.1/7.1 AAC UND HE AAC V2
AUDIO LINEAL 8 CANALES
APT.X/EAPT.X 8 CANALES
80..120
128..248
256
4608
3072
264..320
512
576
18432
4480
19
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
3.- IP como plataforma de las modernas redes de Comunicaciones y Broadcast.
3.1.- Requerimientos básicos para el transporte multimedia
Desde un punto de vista económico, las clásicos servicios de broadcast ofrecen cobertura al
mayor número de destinos a un coste muy bajo. Los servicios de streaming multimedia, son
generalmente más caros debido a que los datos han de ser enviados individualmente a cada uno
de los destinos. En entornos de red cerrados, el multicast es bien conocido por permitir envíos
de datos a un ilimitado número de destinos con una mínima carga de red. Pero el multicast no
es muy usado debido a que no es soportado por todos los routers de red.
Por otro lado, los servicios de streaming dirigidos a audiencias masivas (ej. eventos deportivos,
programas de máxima audiencia) son transmitidos a través de redes que proporcionan los
mismos datos en muchas localizaciones simultáneamente para que desde esas localizaciones
sean enviados a los reproductores más cercanos, a fin de evitar estrangulamientos de red. El
streaming de alta calidad requiere el protocolo RTP/RTCP el cual es la base de las transmisiones
en tiempo real. Para el control del contenido del streaming se aplican los protocolos SIP, SAP,
RTSP y HTTP. Estos protocolos son controlados por diferentes puertos, ofrecen funcionalidad
de control y todos usan el protocolo RTP como protocolo básico de intercambio de información.
[Fig. 5]
RTP/TCP: Arquitectura de protocolo
Aplicación (Receptor)
Aplicación (Emisor)
RTCP
Encoder
Feedback
RTCP
Datos
RTCP
RTCP
Decoder
21
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
4.- Comunicaciones Conmutadas en la Internet Pública
4.1.- Comparación RDSI SIP
Comparando con la RDSI los paquetes de datos en una red IP son siempre provistos con las
direcciones de emisor y receptor por los terminales y se envían sin un establecimiento previo de
la conexión. Para permitir conexiones conmutadas dentro de las redes IP, fue desarrollado el
protocolo SIP (Session Initiation Protocol) por el grupo IETF (Internet Engineering Task Force)
denominada RFC 3261.
Durante el establecimiento de la conexión vía RDSI, la parte iniciadora marca el número de la
parte receptora. Esta petición es presentada a una red que soporta y, si hay suficiente capacidad
o ancho de banda, devuelve una señal de recepción confirmando la reserva del canal o el ancho
de banda. Esta red está compuesta típicamente por varios segmentos de red y solicitudes de
reserva e intercambio que han de ser confirmadas entre cada una de las partes. Esto activa a una
solicitud a moverse desde una red local a una red regional y estas a redes nacionales e
internacionales. Tan pronto como el receptor es contactado y está disponible para aceptar la
llamada, ambos participantes en la comunicación son conectados directamente a través de los
canales reservados.
A fin de manejar esta comunicación eficientemente, la red de comunicaciones es separada
dentro de 2 redes: la red de señalización y la de datos de usuario. Mientras que la red de
señalización envía toda la información necesaria para su propia conexión, la red de datos de
usuario en un canal libre, conmutado con 64 kbps (RDSI).
Debido a la amplia cobertura que se ha logrado actualmente con las redes orientadas a paquetes
(IP) y su alto ancho de banda, muchos servicios están ahora disponibles a través de estas.
Aunque inicialmente fueron concebidas como una plataforma de intercambio puro de datos, tal
como el e-mail, en estos momentos pueden aceptar servicios tales como la televisión o canales
de vídeo, la radio o canales de audio y la telefonía con la voz sobre IP, llamada a ser la sustituta
natural de las actuales redes de telefonía.
En contraste con la RDSI, los paquetes de datos son asignados con las direcciones del emisor y
el receptor y conectados inmediatamente sin mediar ningún proceso de marcado. Para poder
habilitar el marcado en este tipo de redes se ha desarrollado el protocolo SIP (Session Initiation
Protocol). Aunque los detalles de SIP traen reminiscencias del protocolo de canales-D del RDSI,
no lo era para las compañías de telecomunicaciones, pero la IETF que finalizó la documentación
ahora denominada RFC 3261 (Request for Comments). El grupo de trabajo, basó sus
desarrollos en bloques existentes y es por eso que no debe causar ninguna sorpresa que
muchos elementos sean muy similares a HTTP o SMTP.
23
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
4.2,- ¿Como trabaja SIP?
El Protocolo de Inicio de Sesión (SIP) es un protocolo basado en texto, que para la negociación
de sus conexiones se basa en el Protocolo Internet (IP). SIP es usado para dirigir simplemente
la señalización entre partes individuales de negociación. El transporte multimedia corre -como
en la RDSI- de forma separada a la negociación. Los datos multimedia son enviados a menudo a
través de una ruta diferente, transportados mediante un protocolo de transporte diferente. Es
por ellos que si TCP y UDP están disponibles para la negociación, RTP es generalmente el
protocolo más usado para el transporte multimedia.
En el caso más simple (Punto a Punto) los componentes individuales son conectados
directamente entre ellos sin una unidad central. (Figura 6). Dentro de una sesión cada parte es
denominada User-Agent (UA). Un UA puede jugar dos roles:
. User Agent Client (UAC) agente que inicia la sesión.
. User Agent Server (usa) contesta a los requerimientos del UAC.
Un dispositivo SIP puede hacer las dos cosas. Para establecer cada negociación es enviado un
mensaje de invitación [INVITE] desde la parte llamante a la dirección SIP del receptor. La
palabra clave INVITE es uno de los denominados Métodos, por el cual cualquier User Agent debe
dirigir. Otros Métodos son por ejemplo ACK, BYE o REGISTER. Si la parte receptora acepta la
llamada, ella puede contestar directamente con un mensaje OK, el cual es reconocido por la
parte llamante con un mensaje ACK. Estos tres mensajes son suficiente en la mayoría de los
caso para establecer la conexión de datos multimedia. Sin embargo los tres mensajes
mencionados suelen llevar especificaciones, contenidos adicional en el denominado cuerpo
BODY. El cuerpo contiene una descripción de la conexión de datos multimedia que será
establecida. Aquí es donde se especifica que códecs de audio y vídeo serán utilizados, que
parámetros se usarán y que direcciones IP y puertos se usarán en cada una de las partes. Para
describir la conexión de datos multimedia, se usa un protocolo de descripción de sesión
denominado SDP (Session Description Protocol), un protocolo que está ya una parte
establecido de otros mecanismos de la negociación y la transmisión.
Una de las ventajas de SIP es la posibilidad de negociar los ajustes y las propiedades de la
conexión multimedia de una manera automática, por ello estas no tienen porque ser definidas
por el emisor de la llamada. Es incluso posible intercambiar una lista de prioridades en lugar de
especificar un tipo de códec en particular el cual puede ser modificado y remplazado por la parte
remota. Desde un mínimo de tres mensajes son intercambiados durante el establecimiento de
la comunicación la parte receptora siempre tiene la última palabra y puede en último orden
definir cual será el códec que se utilizará.
24
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
FIG. 6
SIP - Esquema de establecimiento de una sesión simple
1: INVITE FRITZ
2: 100/TRYING
Usuario
Agente 1
2: 180/RINGING
3: 200/OK
Usuario
Agente 2
4: ACK
MEDIA CONNECTION RTP
1: BYE
2: 200 /OK
Otra ventaja de SIP se revela a la hora de poder establecer conexiones a través de un servidor SIP,
el cual permite tener actualizadas las direcciones físicas de cada dispositivo de una red aunque
estas puedan variar.
Las direcciones de los clientes SIP son marcadas con un prefijo “sip:” y aparecen sobre todo en
una de las siguientes formas:
“sip:usuario@host”. “sip:usuario@dominio”,
“sip:usuario@dirección IP”. En el caso más simple de una conexión directa entre dos
dispositivos finales estos son el “host”, el ”dominio” y “la dirección IP” del dispositivo final.
Esto significa que la dirección IP del receptor debe ser conocida o el host o el dominio han de
poder ser resueltos mediante mecanismos comunes, tales como DNS (Domain Name Service).
En la práctica, esto resulta raro y la localización del terminal de destino se realiza con la ayuda de
servidores SIP.
Vamos a examinar el siguiente caso como un ejemplo. El terminal 1 desea establecer una
conexión con el terminal móvil 2. Las direcciones IP de las unidades remotas son desconocidas
por cada parte. Podrían posiblemente ser dispositivos móviles conectados a una red UMTS o
ADSL. Sin embargo ambos terminales están logeados en un servidor SIP con un mensaje SIP
especial. Para hacerlo los usuarios se habrán asignado unas identidades con una dirección SIP
previamente asignada de la forma “usuario@proveedor-servicio” protegida por una clave de
acceso.
25
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
El servidor SIP almacena la información de la IP actual de todos los usuarios en cada momento
en el Servidor de Localización. Por ello durante la petición de conexión del Terminal 1 hay una
dirección registrada para el Terminal 2, por ejemplo “dispositivo2@proveedor-servicio”. El
mensaje de invitación INVITE es enviado al servidor SIP, el cual envía una consulta al servidor de
localización para que le envíe la dirección IP del receptor, una vez recibida, envía la llamada al
receptor y retorna la respuesta al Terminal 1 con un leve cambio. El terminal 2 responde los
mensajes SIP del servidor SIP, el cual dirige los mensajes nuevamente al Terminal 1. Los
mensajes “100/Trying” mostrados en la figura 7 son opcionales y simplemente sirven para el
reconocimiento de la petición. Los mensajes “180/ringing” son también opcionales. Estos
simplemente envíanla señal de tono de llamada en el receptor a la parte llamante.
SIP - Flujo de llamada
SERVICIO DE LOCALIZACIÓN
4:[email protected]
3:[email protected]?
1: INVITE
[email protected]
5: INVITE
2: 100/TRYING
SIP Proxy
Usuario
Agente 1
[email protected]
Usuario
Agente 2
6: 100/TRYING
8: 100/RINGING
7: 100/RINGING
10: 200/OK
9: 200/OK
11: ACK [email protected]
FIG. 7
Tal como se muestra en la figura, los dispositivos nunca comunican directamente excepto
cuando se usa la información “ACK”. La comunicación solo corre a través del servidor Proxy.
Desde el punto de vista de un dispositivo la negociación es tomada como si fuera una
negociación directa sin proxy. El ejemplo no muestra la conectividad de los participantes en
diferentes servidores SIP, la cual es muy típica y posible sin generar ningún problema, porque la
peticiones de conexión son pasadas simplemente de un servidor SIP a otro. Entre los 2
dispositivos puede entonces haber solo uno o toda una cadena de Proxys SIP.
26
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
Además no es necesario que todos los servidores proxy sean del mismo proveedor. Gracias a
las soluciones el tipo código abierto como Asterisk o los routers con funcionalidades de
servidor SIP integradas, construir una estructura de red es muy simple. La existencia de un
nuevo protocolo en cambio puede obviamente traernos nuevos problemas potenciales, como en
cualquier protocolo peer-to-peer, los firewalls pueden provocar el corte de comunicaciones a
través de SIP lo que obliga a configurarlos debidamente. Todos los paquetes del exterior
(generalmente de Internet) son definidos como no solicitados y son rechazados por el firewall.
Asumiendo que los dos dispositivos que intervienen en una comunicación SIP están detrás de
un Firewall, ninguno de los 2 puede iniciar una conexión porque todas sus peticiones son
rechazadas.
Con una apropiada configuración del firewall a través del redireccionamiento de puertos, este
problema puede ser evitado. Otro problema es la dirección IP del dispositivo de destino, la cual
es necesario conocer para la conexión de datos de usuario y es parte de la información SDP
(Session Description Protocol). Si se está aplicando NAT (Network Address Translation), como
es común en las redes no públicas la dirección IP no puede ser alcanzada por la otra red. Las
redes no públicas (una red de una oficina) usan típicamente Direcciones IP que son parte de una
área especial de direcciones las cuales solo está permitido usar en redes internas. Ejemplos son
direcciones con la estructura 192.168.X.X o 10.X.X.X. Un paquete de este tipo de direcciones en
la Internet Pública es inmediatamente rechazado.
NAT tiene cuidado con la transición de paquetes IP desde la red privada a la red pública y
sobrescribe las direcciones no públicas del emisor con una dirección pública. Para los paquetes
entrantes hay direcciones publicas del destino que son convertidas a direcciones privadas. Hay
que tener en cuenta que solo las direcciones IP de la cabecera son cambiadas. Los contenidos
de los paquetes (por ejemplo al descripción de los datos de conexión multimedia) sigue sin
tocar. Existen varias posibilidades para traducir direcciones. Estos diferentes métodos pueden
conducir a diferentes direcciones o puertos que pueden ser escritos como identificación del
remitente. Dependiendo del tipo de NAT, los paquetes traducidos (los paquetes que alcanzan la
red pública) puede parecer que viene de diversas direcciones o puertos y esto puede ser
impredecible. Por ello es a veces difícil poner la dirección y el número de puerto apropiados en el
contenido (cuerpo) de un mensaje SIP.
FIG.8
SIP - NAT/Firewalls
El problema de los Firewalls
1
2
4
3
1
2
Una solución para este problema es disponer de un protocolo STUN (Simple Tranversal of UDP
over NATs). STUN deja al cliente descubrir que clase de NAT se utiliza en la red y que número de
puertos ha de ser usado. Para conseguir esto, se lleva a cabo un intercambio de paquetes con el
servidor de STUN (ej. stunserver.org)
27
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
4.3.- Seguridad operacional
Básicamente hay 2 aspectos de seguridad a tener en cuenta en este tipo de conexión:
. La seguridad de la información transmitida.
. La seguridad contra ataques del exterior.
Para una conexión basada en SIP es necesario un intercambio de información a través de 2
canales diferentes. Registro e información de señalización en uno de los canales y datos de
usuario en el otro (ambos via RTP). Ambas conexiones pueden contener datos secretos. Con el
fin de proteger la señalización SIP, el estándar SIP (RFC 3261) define que partes del protocolo
SIP pueden usar palabras clave para mostrar la encriptación necesaria. Tal protección es
aplicada con el procedimiento TLS, muy conocido del HTTPS. En orden de garantizar la
transparencia de la información, solo el cuerpo de cada información normalmente la
información acerca de las codificaciones de audio y vídeo usadas- es protegida. Generalmente
cuando se transmiten datos multimedia, vale proteger el contenido. Un mecanismo de
protección no es parte del estándar SIP, pero se pueden usar otros mecanismos establecidos,
tales como:
. VPN: Los participantes de una VPN pueden intercambiar datos como en una red
LAN. Los participantes individuales no necesitan ser conectados directamente. La
conexión a través de la Internet pública es encriptada.
. ATM o MPLS: Servicios de la capa de transporte, basados en mecanismos de
dirección.
. IPSec: Tunnel basado en el protocolo de Internet.
Uno de los riesgos más críticos de seguridad es un ataque desde el exterior. Tales ataques son
lanzados para perturbar el servicio o bloquearlo totalmente (DoS Denial of Service). Es
concebible que un hacker pretenda re enrutar el flujo de datos RTP a un nuevo destino y con ello
lograr el acceso al contenido. Por otra parte, el atacante puede también reemplazar el stream de
datos RTP por otro con el fin de distribuir una información errónea y no requerida. Tales ataques
no pueden ser evitados por los medios descritos anteriormente, por lo que se necesita
estructuras de red y aplicaciones de seguridad tales como firewalls y gateways de capa de
aplicación (ALG Application Layer Gateways). Estas estructuras han de ser revisadas
periódicamente para que no se vuelvan inservibles.
28
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
4.4.- SIP para enlaces multimedia de alta calidad
Actualmente, SIP es utilizado principalmente dentro de aplicaciones de telefonía VoIP. En las
aplicaciones de VoIP está muy bien posicionado y está previsto que sea el estándar para la Nueva
Generación de Redes (NGN). Podemos contar que el SIP es un requisito de VoIP para las
óptimas operaciones con las apropiadas estructuras de red y recursos. Como se ha descrito
anteriormente, SIP es también una buena base para enlaces multimedia profesionales de
calidad. La muy bien definida separación entre el establecimiento de la comunicación y la
sucesiva transmisión de datos del usuario, permite el uso de cualquier códec de audio y vídeo
tan complejo como permitan los dispositivos implicados. SDP (Session Description Protocol)
el cual es usado para la descripción de los códecs de audio y vídeo es ya parte de los mecanismos
de transmisión y ofrecido por importantes fabricantes de códecs. SIP es simplemente un nuevo
método de señalización.
4.5.- SIP -> Futuro
A fin de usar SIP para comunicaciones entre audiocódecs y videocódecs sin problemas
operacionales, son necesarias algunas definiciones y extensiones.
Con una conexión normal SIP, la descripción de la conexión puede ser enviada solo tres vecesdos veces por parte del emisor y una más por parte del receptor. Este sistema es suficiente para
las clásicas aplicaciones de telefonía desarrolladas para SIP que están limitadas a algoritmos de
codificación con ninguno o pocos parámetros (G.711, G.722, G.723, G.726, G.729a...). Para las
conexiones multimedia de alta calidad, los participantes en la comunicación han de ponerse de
acuerdo no solo en el algoritmo de compresión a utilizar, sino en el número de canales, la
frecuencia de muestreo, el bitrate y el tipo de conexión unidireccional o bidireccional.
El problema aquí podría venir en forma de limitación en los parámetros que pueden ser utilizados
o negociados. Otra posibilidad podría ser extender el número de pasos para el establecimiento
de la comunicación a más de tres. El grupo de trabajo EBU N/ACIP está jugando un importante
papel en la búsqueda de soluciones apropiadas y establecimiento de estándares.
En Mayah tenemos mucho interés puesto en SIP como protocolo de comunicación para enlaces
multimedia de alta calidad, desde que las operadoras de telecomunicaciones comenzaron a
anunciar sus intenciones de cesar sus servicios de RDSI en un futuro cercano.
Las conexiones RDSI están ya muchas veces basadas en paquetes, al menos hasta el primer
conmutador. La latencia causada por esa conversión, así como las pérdidas de datos
adicionales pueden ser evitadas cambiando a una red manejada completamente por IP. Por
supuesto, las conexiones IP también introducen latencia la cual es directamente dependiente de
la calidad de red subyacente.
29
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
El grupo de trabajo N/ACIP de la EBU está ocupado con el asunto del Audio sobre IP y trabaja
junto con los fabricantes, proveedores de red y usuarios para alcanzar soluciones y
recomendaciones de compatibilidad entre audiocódecs vía IP. SIP es el protocolo obligatorio
mencionado dentro de los proyectos de recomendaciones.
Cuando se adapte SIP a los requerimientos de las comunicaciones multimedia de alta calidad, el
grupo de trabajo de la EBU será la plataforma más importante. Todas los problemas entre las
partes involucradas en el duro y largo camino de introducción de la RDSI deben ser evitadas con
SIP.
30
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
5.- Consideraciones Prácticas para SIP y audio-via-IP
5.1.- Requerimientos para comunicaciones basadas en SIP a través de la Internet Pública.
Lo primero a tener en cuenta a la hora de hacer pruebas/integración de SIP es la selección de la
conexión IP apropiada. En España por ejemplo hay varios proveedores de red nacionales y
regionales que proveen enlaces de datos simétricos y asimétricos con capacidades a partir de
320 kbps de velocidad de subida. Cuando se entra en contacto con un proveedor de servicio de
redes IP es necesario tener en cuenta los siguientes puntos de consideración:
. Utilizar la línea de una manera dedicada para evitar interferencias con otros
servicios en el consumo de ancho de banda, contratando la mayor velocidad de
subida posible a partir de 320 kbps.
. Poder contratar 3 direcciones IP Públicas, para poder instalar el Servidor SIP y al
menos los 2 dispositivos de comunicación.
. Preguntar al proveedor acerca de su política de QoS (Quality of Service) algunos operadores
penalizan el tráfico RTP por considerarlo competencia directa de sus obsoletos servicios de
transporte.
Todos los clientes SIP, han de estar registrados en un servidor SIP específico. Este servidor ha
de estar en la misma red o en una red diferente que sea accesible a través de Internet. El servidor
SIP es la llave de las conexiones SIP y puede ser considerado una especie de guía telefónica o
base de datos centralizada donde se encuentran todos los clientes disponibles.
Si estás interesado en probar SIP lo mejor es instalar tu propio servidor SIP. Hay varias opciones
en el mercado tanto en versiones de software como en versiones de hardware dedicado, tales
como el LANCOM 1722 VoIP por ejemplo.
En el momento de empezar a trabajar con SIP, solo necesitas registrarte como usuario SIP. El
resto de ajustes son directamente configurados en el cliente (Centauri II, Sporty, Flashman II).
También es posible usar servidores SIP externos en lugar de uno propio, pero siempre se ha de
tener en cuenta si dispone de las prestaciones necesarias para las comunicaciones de alta
calidad.
ICC Broadcast dispone de servidores SIP ubicados en backbones principales de Internet que
presta para los usuarios de los productos de Mayah en España, en el caso de que no dispongan
de la infraestructura necesaria, siendo una plataforma totalmente transparente para el usuario al
cual se le asigna la numeración del rango que desee.
31
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
5.2.- Requerimientos para otras conexiones basadas en IP a través de la Internet Pública |
Unicast frente a Multicast
Las conexiones IP Punto a Punto son denominadas Unicast. Multicast es usado para establecer
transmisiones Punto a Multipunto. Unicast puede usar tanto TCP como UDP como su protocolo
de transporte. Usando un Centauri II o cualquier otro Audiocódec de Mayah, las conexiones
UDP Unicast pueden ser unidireccionales o bidireccionales. Las conexiones TCP del Centauri II
son siempre bidireccionales. Multicast solo puede utilizar UDP como protocolo de transporte.
Todas las transmisiones Multicast son siempre unidireccionales.
El Multicast es un camino para distribuir datos multimedia a los receptores, mientras estos
reciben el contenido de audio o vídeo al mismo tiempo de una manera similar a la radio y
televisión actuales. Mientras que el Unicast establece un patrón de comunicación para enviar
datos de un host a otro, el Multicast representa el envío de datos desde un host a muchos otros
dentro de la misma red. El principio del Multicast es enviar datos desde un origen a varios
destinos, por el que estos hosts deben tener la posibilidad de solicitar datos particulares
enviando una solicitud específica de multicast al siguiente router.
Los problemas con el multicast se presentan cuando piensas acerca de como los datos
encuentran el camino entre el emisor y el receptor. Mientras que la radio y la televisión
convencional alcanzan sus receptores dispersando los datos todo lo que se puede como si fuera
una regadera, el envío a través de la red tiene algunas restricciones significativas, tales como el
ancho de banda y la carga de trabajo. El principio de la “regadera” puede causar que la red se
colapse tanto como enviando un stream de datos mediante una conexión punto a punto para
cada receptor. Otro problema radica en como consigue el emisor o el router saber que
receptores desean recibir sus datos y cuales no.
La intención de Multicast es usar el menor ancho de banda posible para permitir que la carga de
trabajo de la red sea lo más pequeña posible. Esto significa, no desperdiciar ancho de banda
para enviar datos innecesarios, pero enviar solo a los hosts que hayan solicitado los datos y
enviarlos por la vía más corta respectivamente al camino más eficiente. En general esto significa
que el emisor entrega los datos una vez y estos son duplicados por un router tan cercano al
receptor como sea posible.
La organización del envío y recepción de datos multimedia es manejada por un protocolo
llamado IGMP (Internet Group Management Protocol), por el cual los clientes pueden llamar al
router que ellos quieran para unirse o dejar un grupo multicast. Este grupo multicast es un
número determinado de emisores/receptores, registrados mediante sus routers en una
dirección especial Multicast-IP.
32
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
En el nivel de IP hay un rango especial de direcciones de clase-D reservadas para multicast. Los
cuatro bits significativos de las direcciones de clase-D se fijan a 1 1 1 0. El número de 28-bits
siguiente a esos cuatro bits se llama “Multicast group ID” el cual abarca desde la dirección
224.0.0.0 a la dirección 239.255.255.255.
Cada stream específico de Multicast es definido por un Multicast group ID. Si un host quiere
unirse a un determinado grupo multicast para enviar y recibir datos específicos debe informar de
ello inmediatamente al router vecino enviando la especifica Multicast ID a través de un telegrama
IGMP. Esta ID deberá ser enviada entonces de router a router para ver si hay otros miembros del
grupo multicast.
Recibiendo Multicast
Solicitud para Multicast
Emisor
Emisor
Emisor
Emisor
Emisor
Emisor
Emisor
Emisor
Emisor
Receptor
Emisor
Receptor
Receptor
Emisor
Emisor
Emisor
Receptor
Emisor
Emisor
Emisor
Emisor
Emisor
Receptor
Receptor
FIG. 9
Si el router vecino del host ahora consigue datos del grupo Multicast solicitado, los transmitirá al
host demandante. Por supuesto, el mismo host puede actuar como remitente también. En este
caso el router vecino, transmitirá sus datos al resto de miembros del grupo.
33
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
6.- Esquemas de aplicaciones IP Típicas e IP/RDSI
6.1.- Transmisión desde una Unidad de Reportero Móvil a múltiples
[Fig. 10]
2X HEAD·
PHONES
UMTS/3G/3.5G
MPG=4 HE AACV2,48KBPS
2X
LINE OUT
Internet
SPORTY
ESTÉREO ANALÓGICO
o AES/EBU DIGITAL
CENTAURI II
CENTAURI II
CENTAURI II
2X
LINE IN
2X MIC
6.2.- Transmisión desde una Unidad de Reportero Móvil a múltiples estudios con IP
Multicast vía WiFi o WiMax.
[Fig. 11]
HEAD·
PHONES
Eapt~X
192 KBPS
LINE OUT
Internet
WLAN
HOTSPOT
ESTÉREO ANALÓGICO
o AES/EBU DIGITAL
CENTAURI II
CENTAURI II
CENTAURI II
Flashman II
LINE IN
2X MIC
35
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
6.3.- Transmisión punto a punto por IP (Terrestre/Satélite) con backup por RDSI con
activación automática.
[Fig. 12]
ESTEREO DIGITAL
AES/EBJ
CENTAURI II
IP
MPEG 1/2,LAYER 2
384 KBPS
CENTAURI II
MPEG 4 HE AACv2
64 KBPS
DAB/DRM
AM/FM
STEREO DIGITAL
AES/EBJ
Backup line
RDSI
6.4.- Transmisión punto a 8 puntos por IP (Terrestre/Satélite) con backup por RDSI de
activación automática.
[Fig. 13]
RDSI UP to
24 bit/96 kHz, 448 kbps
ÉSTEREO DIGITAL
AES/EBU
IP
CENTAURI II
ESTEREO DIGITAL
AES/EBJ
CENTAURI II
#1
CENTAURI II
#2
CENTAURI II
#8
MPEG 4 HE AACv2
64 KBPS
Línea de Backup
ISDN
Audio
36
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
6.5.- Transmisión 7+1 punto a punto en modo AES/EBU Transparente vía IP con una bitrate de
12 Mbps.
[Fig. 14]
5.1/7.1 MULTICANAL
4X AES/EBJ
AES TRANSPARENTE
12,288 MBPS
IP
CENTAURI II
CENTAURI II
5.1/7.1 MULTICANAL
4X AES/EBJ
6.6.- Distribución Multicast a través de IP.
[Fig. 15]
MPEG 2 AAC
128KBPS
CENTAURI II
IP
ESTEREO DIGITAL
AES/EBJ
Ganymed 1002
Ganymed 1002
#1
#2
ESTEREO DIGITAL
AES/EBJ
Ganymed 1002
#N
Audio
37
Audio-vía-IP
Principios básicos, prácticas y aplicaciones
6.7.- Aplicación Gateway Multipunto SIP/RDSI con conversión de formatos de audio.
[Fig. 16]
SIP
Internet
Flashman II
SPORTY
SIP
CENTAURI II
SIP
Audio Codec
SIP
Mpeg Layer 2
192 kbps
SIP<=>RDSI
GATEWAY 2250
RDSI
CENTAURI II
1
CENTAURI II
2
CENTAURI II
8
6.8.-Aplicación Gateway RDSI/SIP con conversión de formatos de audio.
[Fig. 17]
AUDIO
Audio Codec
Mpeg Layer 3
128 kbps
RDSI
SIP<=>ISDN
GATEWAY 2250
SIP
E.G. EAPT.X
192 kbps
IP
CENTAURI II
Audio analogo
Digital AES/EBU
38
ICC Broadcast | Hardata España
Pº. Ind. Joxe Mari Korta, A61A - Mod. 12
20750 Zumaia (España) - Teléfono (+34) 902 117 480
www.iccbroadcast.com