79 KB

Práctica 2
Videoconferencia y video streaming en multicast
(versión 2012-2013)
Autores: Santiago Felici
Rogelio Montañana
1.- Introducción y objetivos
En esta práctica se realizan pruebas con diversas herramientas de videoconferencia y vídeo
streaming en multicast. También se llevan a cabo diversos experimentos de transmisión
multicast con el objeto de que el alumno se familiarice con su funcionamiento.
Para el desarrollo de la práctica se utilizan ordenadores con sistema operativo MS Windows XP
que deben tener instalados los siguientes paquetes de software:



El programa Wireshark que se utiliza como analizador de tráfico. Es un software de
libre distribución que puede obtenerse de www.wireshark.org .
Tres herramientas del paquete MBone llamadas SDR, RAT y VIC. Se trata de un
software de videoconferencia con capacidad multicast, de libre distribución que puede
obtenerse de http://www-mice.cs.ucl.ac.uk/multimedia/software/
El programa VideoLAN, que sirve para enviar y recibir emisiones de vídeo en IP. Es un
software de libre distribución que puede funcionar en unicast y en multicast y que se
puede obtener de www.videolan.org
Los ordenadores deben estar dotados de cámara de vídeo, micrófono y auriculares.
2.- Preparación
En primer lugar los alumnos deben organizarse para trabajar por parejas de ordenadores, a ser
posible habiendo un alumno por ordenador.
La práctica se desarrolla con el sistema operativo Windows XP. El profesor indicará el usuario y
contraseña que deben utilizar los alumnos.
A continuación, los alumnos conectarán la cámara de vídeo, el micrófono y los auriculares.
Ahora los alumnos deben averiguar los siguientes datos de su ordenador y el de su vecino:
Dato
Dirección IP
Ordenador mío
Ordenador del vecino
Máscara
Router por defecto ó
‘puerta de enlace’
Para obtener los datos de tu ordenador procede de la siguiente forma: haz clic con el botón
izquierdo del ratón en el icono ‘Inicio’ en la parte inferior izquierda de la pantalla y en el menú
desplegable selecciona ‘Ejecutar…’. En el campo ‘Abrir’ teclea ‘cmd’ y en la ventana que
aparece teclea el comando ‘ipconfig’. De la respuesta a dicho comando obtendrás todos
los datos requeridos. Es posible que el ordenador tenga varias interfaces de red (reales o
virtuales); en ese caso la que nos interesa es la que conecta el ordenador a la red de la
universidad que será una dirección que empezará por 147.156. Las otras interfaces tendrán
normalmente direcciones privadas, o la dirección loopback.
Práctica 2: Videoconferencia y vídeo streaming en multicast
Pregúntale a tu vecino su dirección IP. La máscara y router por defecto de su ordenador son
iguales que las tuyas.
Por último desactiva el cortafuegos de Windows, para ello, pulsa en Inicio, selecciona Panel de
control, y pulsa en Firewall de Windows, donde aparecerá la opción de desactivar el
cortafuegos.
3.- Pruebas básicas de multicast
En esta parte de la práctica vamos a realizar diversas pruebas y experimentos de transmisión
multicast con el objetivo de familiarizarnos con su funcionamiento y mostrar algunas
características interesantes. Para ello utilizaremos el comando ping y el analizador wireshark.
3.1.- Comprobación de la ruta para direcciones clase D
Antes de lanzar los ping vamos a comprobar que nuestro ordenador tiene soporte muticast.
Para ello comprobaremos que existe una ruta definida para las direcciones clase D mediante el
comando ’route print’ que ejecutaremos en una ventana de comandos que abriremos
seleccionando con el ratón el icono ‘Inicio’ en la parte inferior izquierda de la pantalla, en el
menú desplegable seleccionaremos ‘Ejecutar…’ y en el campo ‘Abrir’ teclearemos ‘cmd’.
Veremos que en la lista de rutas mostrada aparece una o varias rutas como la siguiente:
Destino de red
224.0.0.0
Máscara de red
240.0.0.0
Puerta de acceso
Dir_IP
Interfaz Métrica
Dir_IP
20
Donde ‘Dir_IP’ es la dirección de la interfaz Ethernet del host. Esto significa que cuando nuestro
host quiera enviar algún paquete a una dirección multicast lo hará directamente a través de
dicha interfaz. Si nuestro ordenador tiene varias interfaces (reales o virtuales) normalmente
aparecerá la ruta multicast replicada para todas ellas; la que nosotros usaremos será la que
nos conecte a lal red de la universidad, cuya dirección que emplieza por 147.156 hemos
anotado anteriormente.
Observa que la máscara de esta ruta abarca todo el rango de direcciones clase D (red
224.0.0.0/4, que abarca desde la 224.0.0.0 hasta la 239.255.255.255).
También podemos ver que hay definida una (o varias) ruta(s) host (máscara de 32 bits) para la
dirección broadcast (255.255.255.255) lo cual indica que los paquetes enviados a dicha
dirección serán enviados también por la interfaz Ethernet. Esto indica que los paquetes
broadcast recibirán el mismo tratamiento que los paquetes multicast, es decir serán enviados
directamente en la red local.
Para lanzar los pings que vienen a continuación podemos utilizar la misma ventana de
comandos que hemos utilizado para el ’route print’.
Calcula, usando los conocimientos vistos en teoría, la dirección MAC que se
corresponde con una emisión multicast a la dirección IP 224.0.0.1.
Escribe aquí la dirección MAC calculada:
P4-2
Práctica 2: Videoconferencia y vídeo streaming en multicast
3.2.- Ping a la dirección 224.0.0.1
Ahora vamos a hacer ping a la dirección 224.0.0.1, que corresponde a todos los hosts multicast
de la red (si tecleamos el comando ‘nslookup 224.0.0.1’ veremos que el DNS resuelve esa
dirección en el nombre ‘all-systems.mcast.net’). Por tanto este ping debería recibir tantas
respuestas como hosts con soporte multicast hay en nuestra red local, ya que como sabemos
los paquetes dirigidos a direcciones 224.0.0.0/24 no son propagados por los routers. En este
caso la LAN abarca todo el edificio donde nos encontramos. Vamos a enviar un solo paquete
de ping a dicha dirección mediante el comando ‘ping -n 1 224.0.0.1’ (la opción ‘–n 1’
indica que se envíe un solo paquete). Con este ping deberíamos recibir tantas respuestas como
hosts con soporte multicast estén encendidos en estos momentos en nuestra LAN, pero el ping
acusa una sola respuesta. Evidentemente hay más de un host con soporte multicast en nuestra
red puesto que ya solo en el laboratorio donde nos encontramos hay varios. Para averiguar lo
que ocurre vamos a repetir el mismo ping, pero esta vez poniendo en marcha previamente una
captura en el Wireshark con el filtro ‘host dirección_IP and icmp’ donde
‘dirección_IP’ es la dirección IP de nuestro ordenador (por ejemplo ‘host 147.156.80.116’).
Este filtro captura todo el tráfico ICMP con origen o destino nuestro ordenador, de forma que
podremos ver nuestro ping y las respuestas obtenidas. Así podremos ver que, en efecto, el ping
recibe múltiples respuestas, aunque el programa ping de Windows solo reporta la primera e
ignora el resto, probablemente para evitar ‘confundir’ al usuario. Por el número de respuestas a
nuestro ping reflejadas en el Wireshark podremos saber, ahora sí, cuantos hosts con soporte
multicast se encuentran encendidos y conectados en este momento en el edificio.
Hay algo que falla en el filtro que acabamos de configurar. Tal como lo hemos definido captura
el ICMP ECHO que envía nuestro host y los ICMP ECHO-REPLY que nos devuelven los
demás hosts de la LAN. Pero como nuestros compañeros del laboratorio están haciendo lo
mismo y al mismo tiempo estamos recibiendo de ellos una serie de ICMP ECHO que estamos
respondiendo, y esos paquetes, que no corresponden a nuestro ping, también los estamos
capturando. Un filtro que evitaría capturar esos paquetes, para la dirección 147.156.80.166 por
ejemplo, sería el siguiente:
icmp and ((src 147.156.80.116 and multicast) or dst 147.156.80.116)
Si haces el ping a 224.0.0.1 con este filtro sí podrás estar seguro de capturar solo tu ping y sus
respuestas.
En el detalle mostrado por el Wireshark selecciona ahora el primer paquete de la captura, que
es el ICMP ECHO-REQUEST enviado por tu ordenador, y responde a las siguientes preguntas:
¿Qué dirección MAC de destino tiene el ICMP ECHO REQUEST del ping multicast?
¿Se corresponde con la MAC calculada anteriormente?
¿Cuántos equipos hay en nuestra red con soporte multicast encendidos en este
momento?
icmp and ((src 147.156.80.116 and multicast) or dst 147.156.80.116)
3.3.- Ping a la dirección broadcast de nuestra red
Vamos a hacer ahora un ping a la dirección broadcast de la red en la que nos encontramos.
Sería más fácil hacer ping a la dirección 255.255.255.255, pero Windows no lo permite. En
P4-3
Práctica 2: Videoconferencia y vídeo streaming en multicast
cualquier caso el ping que vamos a hacer es completamente equivalente. Debes ahora calcular
la dirección IP broadcast de tu red a partir de la IP y máscara de tu ordenador. Una vez
obtenida deberás lanzarle un ‘ping –n 1’ (solo enviaremos un paquete) poniendo
previamente en marcha la captura del Wireshark con el filtro de antes (icmp and ((src
147.156.80.116 and multicast) or dst 147.156.80.116). Observarás el mismo comportamiento
que antes, es decir el programa ping reporta una única respuesta, pero el Wireshark nos
permite saber cuantas hay realmente. Ahora el número de respuestas recibidas corresponde al
número de hosts con soporte del protocolo IP que están encendidos en este momento en el
edificio. El número de respuestas puede ser ligeramente superior al de antes, ya que ahora
deberían contestar todos los hosts de antes más aquellos que tienen IP sin soporte multicast1.,
que pueden ser por ejemplo:




Impresoras con conexión LAN. Estos dispositivos se comportan como hosts en la red
pero debido a su naturaleza no requieren soporte multicast.
Equipos de red gestionables de nivel 2 (conmutadores LAN). Tampoco requieren
soporte multicast.
Otros dispositivos conectados a la red que no necesitan muticast, por ejemplo equipos
de medida o de control de laboratorio con sistemas embebidos
Sistemas operativos con multicast desactivado o sin soporte multicast, por ejemplo,
Windows 95.
Responde ahora a las siguientes preguntas:
¿Qué dirección IP has empleado en el ping broadcast?
¿Qué dirección MAC de destino emplea ahora el ICMP ECHO REQUEST?
Suponiendo que la prueba hecha es fiable ¿Cuántos equipos hay en nuestra red sin
soporte multicast?
Podría ser que recibamos alguna respuesta de direcciones de otra red IP. Esto se debe a que,
aunque el ping lo hemos enviado a la dirección broadcast de nuestra red IP, si existen en la
LAN ordenadores de otra red IP también nos responderán. Lo mismo podría ocurrir con el ping
a la dirección 224.0.0.1.
3.4.- Ping broadcast a una red remota
Ahora vamos a hacer un ping a la dirección broadcast de una red IP remota. Vamos a utilizar
para ello la 147.156.8.0/23, que corresponde al Servicio de Informática. Como siempre primero
pondremos en marcha el Wireshark con el filtro ‘host dirección_IP and icmp’ (a partir
de ahora este filtro es suficiente para capturar solo nuestro tr´qafico). Luego haremos ‘ping –
n 1 direccion_IP’ donde ‘direccion_IP’ será en este caso la dirección broadcast de la
red 147.156.8.0/23. En esta red siempre hay al menos una docena de ordenadores
encendidos, por lo que lo normal sería recibir múltiples respuestas. Responde ahora a las
siguientes preguntas:
1
Para que el cómputo fuera riguroso habría que haber hecho los dos pings al mismo tiempo, ya
que entre uno y otro puede haberse encendido o apagado algún equipo del edificio. Además
puede haber ordenadores con filtro configurado en el cortafuegos a los pings de uno u otro tipo
(o ambos).
P4-4
Práctica 2: Videoconferencia y vídeo streaming en multicast
¿Qué dirección IP has utilizado en el ping broadcast?
¿Cuantas respuestas se reciben?
¿Qué dirección de origen tienen?
¿Sabrías explicar el resultado obtenido?
(pista: las rutas pueden ser asimétricas)
3.5.- Ping a la dirección 224.0.0.2 (todos los routers multicast) y a otras direcciones
multicast reservadas de la red 224.0.0.0/24
Ahora probaremos a enviar un ping a la dirección 224.0.0.2, que corresponde a todos los
routers multicast (all-routers.mcast.net en el DNS), Utilizaremos el Wireshark con el filtro
(‘host dirección_IP and icmp’) para saber el número de respuestas realmente
recibidas.
Haz ping ahora a la dirección 224.0.0.2 y con la ayuda del Wireshark responde a la siguiente
pregunta:
¿Cuantos routers con soporte multicast hay en la LAN del edificio?
Recuerda que las direcciones 224.0.0.0/24 siempre tienen restringido su ámbito a la red local
(TTL=1). Otras direcciones multicast reservadas de la red 224.0.0.0/24 son las siguientes:
Dirección
224.0.0.5
224.0.0.10
224.0.0.13
224.0.0.22
Significado
Routers OSPF
Routers IGRP/EIGRP
Routers PIM v2
Routers con soporte de IGMPv3 (envío de
Membership Report)
Nombre en el DNS
ospf-all.mcast.net
igrp-routers.mcast.net
pim-routers.mcast.net
igmp.mcast.net
Ahora, haciendo ‘ping –n 1’ a cada una de estas direcciones y con la ayuda del Wireshark
responde a las siguientes preguntas:
¿Cuantos routers OSPF hay en la LAN del edificio?
¿Cuantos routers IGRP/EIGRP hay en la LAN del edificio?
¿Cuantos routers PIM v2 hay en la LAN del edificio?
P4-5
Práctica 2: Videoconferencia y vídeo streaming en multicast
¿Cuantos routers IGMPv3 hay en la LAN del edificio?
3.6.- Ping a otras direcciones multicast reservadas
Otras direcciones multicast reservadas son por ejemplo las siguientes:
Dirección
224.0.1.16
224.0.1.41
224.2.127.254
Significado
Servidores Music-Service
Gatekeepers H.323
Anuncio de sesiones SAP,
Announcement Protocol)
(Session
Nombre en el DNS
Music-service.mcast.net
Gatekeeper.mcast.net
sap.mcast.net
Estas no estan reservadas al ámbito de la red local, sino que se propagan en principio por toda
la internet
Resulta interesante para esta prueba activar la función de resolución de nombres de Wireshark.
Para ello hay que marcar en ‘Capture’ ‘Options’ la casilla ‘Enable network name resolution’. Una
vez tengas activada esta opción pon el filtro de captura habitual (‘host dirección_IP and
icmp’) y lanza un ‘ping –n 1’ a cada una de ellas. Utiliza las respuestas obtenidas para
responder a las siguientes preguntas:
¿Cuantos servidores Music-Service hay accesibles ahora mismo en Internet?
¿Y cuántos Gatekeepers H.323?
¿Cuántos hosts están en este momento participando del protocolo SAP?
Por alguna razón que desconozco el ping a estas direcciones no funciona si se hace con una
frecuencia superior a dos pings por minuto desde una misma dirección IP. Por tanto si
necesitas repetir alguno de estos pings debes esperar al menos 30 segundos antes de volver a
intentarlo, ya que de lo contrario no responde nadie.
Seguramente cada uno de estos grupos (especialmente el SAP) tiene en Internet muchos más
participantes de lo que a la vista de las pruebas anteriores parece deducirse. Lo que ocurre es
que la mayoría de los equipos no responde a los pings o se encuentran detrás de cortafuegos
que no dejan pasar los pings.
4.- Pruebas con las herramientas MBone (SDR, VIC, RAT)
Las herramientas MBone son un conjunto de programas que permiten realizar
videoconferencias multicast a través de Internet. De la multitud de programas disponibles
nosotros utilizaremos el SDR, el VIC y el RAT. El SDR es el directorio de sesiones, y es el
único que invocamos directamente; el VIC y el RAT son las herramientas de vídeo y audio,
respectivamente, y se invocan de forma automática cuando arrancamos el vídeo o el audio en
una conferencia. Este software es de libre distribución y puede obtenerse del paquete Mash
(http://www-mice.cs.ucl.ac.uk/multimedia/software/). Se trata de programas bastante antiguos
que hoy en día están declarados obsoletos, pero que presentan algunas características
P4-6
Práctica 2: Videoconferencia y vídeo streaming en multicast
interesantes para lo que hacemos en esta práctica. Su funcionamiento con las versiones de
Windows más recientes presenta algunos problemas de compatibilidad, por lo que a veces los
programas pueden abortar.
4.1.- Recibir la lista de emisiones de Internet con SDR
SDR (Session Directory) permite crear y anunciar sesiones multicast, así como unirnos a
otras ya existentes. Es la aplicación principal ya que actúa como gestor de las demás
herramientas y es la única que se invoca directamente.
Primeramente arranca el Wireshark con un filtro para capturar únicamente los paquetes
destinados a la dirección 224.2.127.254, que es la dirección utilizada por el protocolo SAP
(Session Announcement Protocol). De momento no se captura ningún paquete.
A continuación arranca el SDR. Para ello debes hacer doble clic en el icono correspondiente
del escritorio, o si no lo encuentras clicar ‘Inicio’ -> ‘Todos los programas’, de la lista
seleccionar ‘Mbone Tools’ y una vez allí ‘sdr’. A continuación aparece una ventana con una
lista en la que en unos instantes van apareciendo las sesiones anunciadas en Internet.
Verás entonces que el Wireshark empieza a recibir gran cantidad de paquetes, en un flujo
constante. Parando la captura podrás analizar alguno de ellos y observarás que contiene
información detallada sobre las diferentes sesiones que aparecen anunciadas en la ventana del
SDR. Los anuncios se reiteran periódicamente con el fin de que, si aparece un nuevo
participante en la red, reciba en unos pocos minutos la información de todas las sesiones
anunciadas. En nuestra captura el primer mensaje capturado no debería ser un anuncio SDR
sino un IGMP Membership Report, por medio del cual nuestro host se ha unido al grupo
multicast del SDR (224.2.127.254). Ahora analiza ese paquete IGMP y responde a la siguiente
pregunta:
¿Qué versión de IGMP está utilizando Windows XP?
Para apuntarnos a una sesión la debemos seleccionar mediante doble clic. Sin embargo no
intentaremos seguir ninguna, ya que todas o la mayoría de las sesiones utilizan códecs no
soportados por el VIC ni el RAT.
Nuestro mayor interés en relación con las herramientas MBone no es ver las emisiones que
llegan del exterior, sino realizar emisiones multicast propias.
4.2.- Realizar emisiones propias con SDR
Vamos a utilizar ahora las posibilidades de emisión multicast de las herramientas MBone para
establecer una multi-conferencia entre todos los alumnos del laboratorio, sin necesidad de
ningún servidor que se encargue de replicar el flujo de audio-video al resto, esto lo hará de
manera natural la transmisión multicast. Para ello uno de los participantes creará una sesión a
la cual se unirán todos los demás. Pero antes, y con el fin de practicar todos lo más posible,
vamos a hacer algo que no sería muy normal en una situación real, que es crear una emisión
multicast diferente en cada ordenador, de forma que habrá tantas emisiones simultáneas como
ordenadores estén realizando la práctica. Una vez terminada esa prueba todos nos uniremos a
una de las emisiones creadas para poder participar en la misma videoconferencia.
Para crear una sesión debemos seleccionar en la ventana de sesiones del SDR ‘New’ y a
continuación ‘Create advertised session’. Entramos entonces en un diálogo con varias
etapas:
0. En la etapa 0 asignarás a la sesión un nombre, que será ‘AR.x.y’ donde ‘x.y’ son los
dos últimos bytes de la dirección IP de tu ordenador. Por ejemplo si el ordenador tiene
P4-7
Práctica 2: Videoconferencia y vídeo streaming en multicast
1.
2.
3.
4.
5.
6.
la dirección 147.156.80.116 la sesión se llamará ‘AR.80.116’. Además le debes asignar
una descripción (el campo ‘Description’ no puede estar en blanco).
En la etapa 1 elegirás el valor por defecto (sesión tipo Test).
En la etapa 2 también elegirás los valores por defecto (sesión de dos horas de duración
a empezar de forma inmediata).
En la etapa 3, ‘Select the Distribution Scope’, elegirás también la opción por defecto,
‘IPv4 Local Scope’. De este modo la sesión recibirá direcciones del rango
239.255.0.0/16, que tienen restringido el alcance al ámbito local.
En la etapa 4 debes elegir los medios que quieres utilizar (audio, video, pizarra, etc.). El
audio está elegido por defecto, debes elegir además video. Puedes además elegir aquí
los codecs por defecto que quieres utilizar en la sesión (luego esto puede cambiarse).
En audio deja el que aparece por defecto (PCM) y en vídeo selecciona M-JPEG, ya
que presenta menos problemas de compatibilidad que el H.261 que aparece por
defecto.
En la etapa 5 ‘Provide Contact Details’ deja los valores por defecto (en blanco).
En la etapa 6 ‘Select security parameters for this session’ deja también los valores
por defecto.
A continuación aparece una pantalla resumen (‘Review session details’) que muestra las
direcciones multicast y los números de puerto que el SDR ha asignado a los flujos de vídeo, y
de audio. Las direcciones de ambos flujos son diferentes, dando así la posibilidad de que un
participante reciba solo uno de los flujos, si lo desea (por ejemplo solo audio si tiene ancho de
banda pequeño). Estas direcciones las elige el SDR de forma que sean únicas en el ámbito de
difusión de la emisión, evitando así conflicto con otras sesiones anunciadas o activas. Como en
la etapa 3 hemos elegido la opción ‘IPv4 Local Scope’ el SDR nos ha asignado direcciones del
rango 239.255.0.0/16, de lo contrario nos habría asignado direcciones del rango 224.2.0.0/16,
reservado para el SDR.
¿Qué direcciones y puerto se van a utilizar para las emisiones de video y audio?
Una vez introducidos todos los datos pulsa el botón ‘Aceptar’. Pasados unos instantes todos
los ordenadores del laboratorio que estén ejecutando el SDR verán aparecer tu sesión en la
lista del SDR; tú también verás aparecer las suyas. A partir de este momento puedes hacer clic
en cualquier sesión y te aparecerá una ventana mostrando su descripción y la lista de medios
disponibles (audio y video) con la dirección multicast y puerto utilizados por cada uno.
Como lo interesante es participar todos en la misma sesión, no cada uno en una diferente,
vamos a unirnos todos a la primera sesión ‘AR.x.y’ de la lista; puesto que todos vemos la lista
en el mismo orden todos elegiremos la misma sesión. Una vez seleccionada pulsa el botón
‘Join’, con lo cual te unes a todos los medios disponibles (audio y vídeo en este caso) y te
aparecerán dos nuevas ventanas, que corresponden al VIC (video) y al RAT (audio).
En la ventana del VIC irán apareciendo pequeñas ventanas que irán mostrando a los
participantes a medida que activan la transmisión de vídeo. Para activar el tuyo pulsa en la
ventana VIC el botón ‘Menu’ y en la ventana que aparece clica la casilla ‘Transmit’; en ese
momento empieza a emitirse tu video al resto de participantes de la sesión.
La ventana de Menu te ofrece una amplia lista de controles de tu emisión, que puedes
modificar con la transmisión en marcha. Por ejemplo el mando ‘Rate Control’ te permite regular
el caudal generado en un rango muy amplio, desde 1 Kb/s hasta unos 3 Mb/s. También puedes
ajustar el número de fotogramas por segundo, de 1 a 30 fps, según la agilidad que darle a tu
emisión. En la parte ‘Encoder’ puedes indicar el formato de compresión de vídeo; como al crear
la sesión se eligió M-JPEG el encoder elegido es ‘jpeg’, pero puedes elegir otro. Aunque MJPEG no es un códec muy eficiente lo hemos elegido porque es compatible con la mayoría de
drivers y hardware; otros códecs que suelen funcionar bastante bien son cellb, nv y nvdct;
P4-8
Práctica 2: Videoconferencia y vídeo streaming en multicast
lamentablemente los códecs H.26x, que son más eficientes, fallan a menudo en el VIC.
También podemos cambiar la resolución del vídeo eligiendo entre tres tamaños posibles, small,
normal y large, que corresponden a los tamaños SQCIF, QCIF y CIF, respectivamente. Por
último, el control ‘Quality’ te permite marcar tu preferencia entre calidad y agilidad del vídeo; en
el extremo derecho de la escala se consigue la máxima calidad y mínima agilidad, siendo lo
contrario en el extremo izquierdo.
Durante la emisión cada mini-ventana del VIC muestra la dirección IP del emisor, el caudal que
está generando en Kb/s, la tasa de pérdidas en % (obtenida a partir de los informes de RTCP)
y el número de fotogramas por segundo. Clicando en la imagen de cualquiera de esas miniventanas puedes verla ampliada; la ventana ampliada puede configurarse para que conmute
automáticamente por voz, lo cual es especialmente interesante en conferencias multipunto
como la nuestra. Desde el momento en que nos unimos a una sesión de vídeo nuestra CPU
está recibiendo los flujos de vídeo de todos los participantes, independientemente de que los
ampliemos o no, puesto que todos se envían al mismo grupo multicast y por tanto la interfaz de
red no puede seleccionar uno y filtrar el resto. Para que la recepción selectiva fuera posible
cada flujo de vídeo debería utilizar una dirección multicast diferente, lo cual requeriría que cada
uno estuviera en una sesión SDR diferente. En cambio el audio de la conferencia, que se emite
en una dirección muticast diferente, sí puede ser sintonizado de forma independiente del vídeo,
pero tampoco es posible recibir un audio aislado del resto; esto permitiría por ejemplo que un
participante con una conexión de baja velocidad, no capaz de soportar el video, siguiera la
conferencia sintonizando solo la parte de audio.
Vamos a ver ahora las posibilidades que nos brinda el audio. En la ventana de RAT aparecen
unos indicadores de nivel simulando una escala de LEDs y unos potenciómetros que nos
permite regular el volumen del micrófono y del altavoz. La lista que aparece a la izquierda
muestra los nombres de los usuarios que han hablado recientemente, estando el usuario actual
o más reciente en la parte superior de la lista. En la parte inferior de la ventana tenemos el
botón de ‘Options’ que nos permite configurar diversas características, siendo las más
importantes la selección del códec de audio (Primary Encoding) y la posibilidad e activar o no la
supresión de silencios. Para conseguir máxima compatibilidad con todo tipo de drivers y de
hardware hemos optado por utilizar la versión 3 de RAT, cuyas opciones y posibilidades son
mucho menores que las de la versión 4.
Ahora debes identificar las direcciones IP de origen de la emisión multicast que está teniendo
lugar en el laboratorio. Con el Wireshark define un filtro que capture únicamente el tráfico de
dicha emisión y responde a las siguientes preguntas:
¿Cuáles son las direcciones IP de origen de la emisión Multicast?
¿Cuáles es la dirección MAC de destino? ¿Coincide con la que sería previsible?
Ahora define un filtro en el Wireshark para capturar únicamente los mensajes IGMP. Con el
filtro activado abandona la emisión y vuelve a unirte a ella para provocar el envío de mensajes
IGMP y analizarlos en detalle. Ahora responde a las siguientes preguntas:
¿Qué código se utiliza en el campo protocolo de la cabecera IP para indicar IGMP?
¿Cómo sabemos si es trata de IGMP v1, v2 ó v3? ¿Qué versión estamos utilizando?
P4-9
Práctica 2: Videoconferencia y vídeo streaming en multicast
¿Va escrita en algún sitio de los mensajes IGMP la dirección multicast sobre la que se
aplica el comando?
¿Cuándo se produce el Membership Report al grupo multicast de la emisión de vídeo?
a) Cuando se arranca el SDR
b) Cuando nos unimos a una sesión
c) Cuando ampliamos una ventana de vídeo
Como ya hemos visto SDR realiza el anuncio de sesiones mediante el protocolo SAP (Session
Announcement Protocol) que utiliza la dirección 224.2.127.254. Establece un filtro en el
Wireshark para capturar solo ese tipo de paquetes y responde ahora a las siguientes
preguntas:
¿Con que frecuencia se envían los mensajes de SAP?
¿Qué hosts envian los mensajes SDR? ¿Todos? ¿Solo los que emiten audio o vídeo?
Si, estando en una sesión, paramos la emisión de audio y vídeo en nuestro ordenador,
pero mantenemos la recepción ¿dejamos completamente de transmitir en ese grupo
multicast?
¿Qué filtro pondrías en el Wireshark para comprobarlo?
5.- Pruebas de recepción multicast con VideoLAN
Como ya vimos en la práctica anterior VideoLAN permite realizar distribución de vídeo
streaming por Internet, incorporando en el mismo ejecutable tanto las funciones de servidor
como de cliente. En esta práctica vamos a hacer uso de sus posibilidades de emisión en
multicast.
5.1.- Recibir la lista de emisiones multicast de Internet con VideoLAN
Antes de arrancar el VideoLAN pon en marcha el Wireshark con un filtro para capturar los
paquetes dirigidos a la dirección 224.2.127.254 (SAP) para observar lo que ocurre cuando
arrancamos VideoLAN.
A continuación arranca VideoLAN haciendo doble clic en el icono de nombre ‘VLC media
player’, o bien seleccionando ‘Inicio’ -> ‘Todos los programas’ y eligiendo ‘VideoLAN’ y una
vez allí ‘VLC media player’. En la ventana que aparece elige en el menú desplegable ‘Ver’ y
en este la opción ‘Lista de Reproducción’. De la lista de opciones desplegables que aparecen
en la parte superior izquierda abre la de ‘Red local’ y selecciona la que pone ‘Emisiones de
red (SAP)’
Inmediatamente verás que el Wireshark empieza a capturar paquetes SAP, y aparece una lista
de canales, que va creciendo. Para la captura del Wireshark y fíjate en el primer paquete de la
P4-10
Práctica 2: Videoconferencia y vídeo streaming en multicast
captura, que corresponde al IGMP ‘Membership Report’ que ha emitido nuestro host para
unirse al grupo SAP; todos los paquetes que aparecen a continuación son los anuncios de las
sesiones, gracias a los cuales el VideoLAN ha podido crear la lista de canales que nos muestra
en pantalla.
La mayoría de las entradas de la lista corresponden a canales de televisión, casi todos
utilizando códecs MPEG. Hay también algunos canales de radio que utilizan MP3. La lista es
similar al directorio de sesiones que veíamos con el SDR; la principal diferencia es que el
VideoLAN está diseñado para emisiones de vídeo streaming unidireccionales con un solo
emisor, sin posibilidad de interacción por parte de los receptores, y que aquí algunas emisiones
están agrupadas. Además ahora sí que podremos recibir algunas de ellas, como veremos
enseguida.
5.2.- Recibir una emisión multicast de Internet con VideoLAN
Ahora prueba a ‘sintonizar’ uno de los canales haciendo doble click encima de su nombre.
Aunque la lista de canales que aparece es muy larga la inmensa mayoría de las emisiones no
están activas, solo anunciadas. Algunos canales que suelen estar activos continuamente son
los siguientes:






RedIRIS-TV
TA 3
Monoskop
NRC Channel 2
UNIVSL2 – University of Silesia, Katowice, Poland
RWTH Information
Sintoniza uno cualquiera de estos canales, pero antes de hacer doble clic en el cambia el filtro
del Wireshark para que capture solo los mensajes IGMP; de este modo podrás ver el
‘Membership Report’ que se produce al sintonizar el canal y averiguar la dirección IP multicast
del canal que estas ‘sintonizando’2. Si no consigues averiguarla puedes abandonar la emisión y
volverla a sintonizarla hasta que conseguir identificarla. Cuando la tengas responde a la
siguiente pregunta:
¿Que tipo de dirección multicast, de entre las siguientes, se está utilizando?
a)
b)
c)
d)
e)
f)
g)
Dirección global asignada por el IANA
Bloque para asignaciones ad-hoc
Direcciones de Stream Protocol
Bloque SAP/SDP
Direcciones para SSM (multicast específico de la fuente)
‘glop addressing’
Multicast con ámbito limitado por la dirección
Vamos ahora a observar el efecto que la recepción del vídeo tiene en el tráfico de la red y en la
CPU de nuestro equipo. Para ello pon en marcha el ‘Administrador de Tareas’ de Windows XP
y manten en el Wireshark el filtro para que capture únicamente los mensajes IGMP.
Utilizando los mandos de control de VideoLAN puedes pausar o reanudar la reproducción en
curso. Al pausarla se para la visualización, pero no la recepción multicast, como puedes
comprobar por la actividad que muestra la pestaña ‘Funciones de red’ del Administrador de
tareas y por la ausencia de mensajes IGMP en la red (lo cual demuestra que no ha habido
cambios en los grupos multicast recibidos). En cambio, si cierras la ventana de reproducción
2
A diferencia de SDR el VideoLAN mantiene oculta al usuario la dirección multicast de las
emisiones
P4-11
Práctica 2: Videoconferencia y vídeo streaming en multicast
del video sí que se para la recepción multicast, pues hay variación en la actividad de la ventana
‘Funciones de red’, y se generan nuevos mensajes IGMP.
Ahora, repitiendo las pruebas anteriores las veces que sea necesario, intenta responder a las
siguientes preguntas:
¿Cuánto tarda la red en dejar de enviar el flujo multicast cuando cierras la ventana de
reproducción del vídeo?
¿Cuánto tarda en enviarlo nuevamente cuando vuelves a sintonizar el canal?
¿Qué mensaje IGMP envía tu ordenador cuando cierras la ventana de vídeo?
¿Qué mensaje IGMP envía tu ordenador cuando sintonizas el canal?
Ahora vamos a averiguar de qué dirección IP proviene la emisión que estas recibiendo. Para
ello, con la emisión en marcha, para nuevamente el Wireshark y pon un filtro para que capture
solo los paquetes de la emisión que estas recibiendo; a partir de ellos podrás averiguar
fácilmente la dirección IP de origen de la emisión, y responder a la siguiente pregunta:
¿De que país proviene la emisión que estas sintonizando?
(pista: utiliza la resolución inversa del DNS)
Ahora analiza el contenido de los paquetes de la emisión recibidos, que normalmente serán en
su mayoría paquetes de vídeo, con algún paquete de audio de vez en cuando. A continuación
intenta responder a las siguientes preguntas:
¿Que códec de audio y vídeo está utilizando la emisión? (esta información también la
puedes obtener a partir de VideoLAN->Herramientas->Información multimedia->Códec)
Analizando una secuencia de 20 paquetes del mismo flujo ¿Se aprecia pérdida o cambio
de orden de los paquetes en recepción?
6.- Pruebas de emisión multicast con VideoLAN
Vamos ahora a utilizar VideoLAN para establecer un servidor de vídeo streaming multicast.
P4-12
Práctica 2: Videoconferencia y vídeo streaming en multicast
6.1.- Preparación del cliente
Para estas pruebas un ordenador de la pareja actuará como servidor y el otro como cliente.
Si el servidor tiene la dirección IP 147.156.x.y utiliza para emitir la dirección multicast
239.255.x.y. De esta forma nos aseguramos de que cada servidor emita en una dirección
diferente, sin riesgo de duplicidad de direcciones. Por otro lado al utilizar direcciones
239.255.0.0/16 nos aseguramos de que nuestras pruebas no salen de la LAN (pues este rango
de direcciones está siempre confinado a la LAN).
Anota aquí la dirección multicast que vas a utilizar para tu emisión:
239.255.___.___
En primer lugar vas a poner ‘a la escucha’ al cliente de la emisión multicast. Tienes que
especificar en el cliente la dirección multicast que quieres recibir, con lo que el cliente queda
‘sintonizado’ en ese canal. A partir de ahí puedes lanzar las pruebas que quieras en dicha
dirección sin necesidad de tocar el cliente para nada. Por supuesto el cliente podría si quisiera
ir cambiando de dirección multicast y ‘sintonizando’ diferentes canales.
El procedimiento para arrancar el cliente VideoLAN es el siguiente (239.255.x.y representa la
dirección de la emisión):
1.
2.
3.
4.
5.
Arrancar el programa ‘VLC media player’
Seleccionar en la ventana que aparece el menú ‘Medio’
Elegir de la lista la opción ‘Abrir volcado de red …’
Seleccionar la pestaña ‘Red’ e introducir como URL: rtp://@239.255.x.y:5004
Pulsar el botón ‘Reproducir’
El cliente está listo para recibir la emisión multicast en la dirección 239.255.x.y, cualquiera que
sea la dirección de origen, siempre y cuando el puerto de destino sea el 5004 (puerto por
defecto de las emisiones RTP).
6.2.- Preparación del servidor y emisión del vídeo streaming
Para las pruebas que siguen utilizaremos los mismos dos ficheros de la práctica anterior, cuyas
características son:
Fichero
Duración
Codec de vídeo
Resolución
Frecuencia de refresco
Caudal de vídeo
Codec de audio
Frecuencia de muestreo
Canales
Caudal de audio
Ethernet.mpg
10 minutos
MPEG-1
352x288 (CIF)
25 fps
1500 Kb/s
MPEG-1 Capa II
44,1KHz
2 (stereo)
224 Kb/s
Carmen.mpg
3 minutos
MPEG-2
720x576
25 fps
4500 Kb/s
MPEG-1 Capa II
48 KHz
2 (stereo)
192 Kb/s
Ambos ficheros deben encontrarse en el escritorio.
P4-13
Práctica 2: Videoconferencia y vídeo streaming en multicast
El procedimiento para poner en marcha la emisión en el servidor VideoLAN es el siguiente:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Arrancar el programa ‘VLC media player’
Seleccionar el menú ‘Medio’
Elegir de la lista la opción ‘Emitir…’
Seleccionar la pestaña ‘Archivo’
Pulsar el botón ‘Añadir’ y seleccionar el fichero correspondiente (‘Ethernet.mpg’ ó
‘Carmen.mpg’)
Pulsar el botón ‘Emitir’
Aparece la ventana ‘Fuente’ que como su nombre indica nos muestra la fuente de
nuestra emisión, que acabamos de seleccionar; pulsar el botón ‘Siguiente’.
Aparece la ventana ‘Configuración de destino’ donde en ‘Destinos’ debemos
seleccionar en el desplegable ‘Nuevo destino’ la opción ‘RTP / MPEG Transport
Stream’’ y darle al botón ‘Añadir’. Aparece una nueva pestaña ‘RTP/TS’ con un campo
‘Dirección’ en el que introduciremos la dirección IP multicast (239.255.x.y) a la que
queremos enviar el flujo de video. También aparece en dicha pestaña el campo ‘Puerto’
cuyo valor por defecto (5004) no debemos modificar, pues es el que hemos indicado en
el cliente (5004 es el puerto por defecto utilizado para las emisiones RTP).
En esa misma ventana un poco más abajo aparecen las ‘Opciones de
transcodificación’, estando marcada por defecto la opción ‘Habilitar transcodificar’
que debemos desmarcar, ya que de momento no vamos a transcodificar el video sino
que lo vamos a emitir en su formato original.
Pulsar el botón ‘Siguiente’.
Aparece la ventana ‘Configuración de preferencias’ en la cual podemos especificar el
valor del campo ‘Tiempo de vida (TTL)’, que por defecto es 1. Con TTL=1 la emisión no
podrá atravesar ningún router, por lo que el cliente deberá estar en la misma LAN que
el servidor; dado que este es nuestro caso no vamos a modificar el TTL y pulsamos el
botón ‘Emitir’, momento en el que empieza la emisión multicast.
Como puede comprobarse fácilmente, durante la emisión los botones de control de vídeo del
cliente no funcionan, salvo el de parada/arranque. El servidor tampoco puede utilizar dichos
botones, pero dispone de un mando deslizante con el que puede controlar la posición del vídeo
que se está emitiendo.
En la práctica anterior ya probamos las posibilidades de transcodificación de VideoLAN en
unicast. Dichas posibilidades son idénticas en multicast. Asimismo es posible emitir en
multicast vídeo en directo generado a partir de una cámara conectada al ordenador.
7.- Finalización
Al terminar la práctica debes devolver la cámara y los auriculares al profesor, y apagar el
equipo.
P4-14