Práctica 2 Videoconferencia y video streaming en multicast (versión )

Transcripción

1 Práctica 2 Videoconferencia y video streaming en multicast (versión ) 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 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 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 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 Ordenador mío Ordenador del vecino Dirección IP 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 Las otras interfaces tendrán normalmente direcciones privadas, o la dirección loopback.

2 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 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 Máscara de red Puerta de acceso Interfaz Métrica Dir_IP 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 hemos anotado anteriormente. Observa que la máscara de esta ruta abarca todo el rango de direcciones clase D (red /4, que abarca desde la hasta la ). También podemos ver que hay definida una (o varias) ruta(s) host (máscara de 32 bits) para la dirección broadcast ( ) 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 Escribe aquí la dirección MAC calculada: P4-2

3 3.2.- Ping a la dirección Ahora vamos a hacer ping a la dirección , que corresponde a todos los hosts multicast de la red (si tecleamos el comando nslookup 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 /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 (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 ). 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 por ejemplo, sería el siguiente: icmp and ((src and multicast) or dst ) Si haces el ping a 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 and multicast) or dst ) 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 , pero Windows no lo permite. En P4-3

4 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 and multicast) or dst ). 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 multicast 1., 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 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 /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 /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

5 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) Ping a la dirección (todos los routers multicast) y a otras direcciones multicast reservadas de la red /24 Ahora probaremos a enviar un ping a la dirección , 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 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 /24 siempre tienen restringido su ámbito a la red local (TTL=1). Otras direcciones multicast reservadas de la red /24 son las siguientes: Dirección Significado Nombre en el DNS Routers OSPF ospf-all.mcast.net Routers IGRP/EIGRP igrp-routers.mcast.net Routers PIM v2 pim-routers.mcast.net Routers con soporte de IGMPv3 (envío de Membership Report) 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

6 Cuantos routers IGMPv3 hay en la LAN del edificio? Ping a otras direcciones multicast reservadas Otras direcciones multicast reservadas son por ejemplo las siguientes: Dirección Significado Nombre en el DNS Servidores Music-Service Music-service.mcast.net Gatekeepers H.323 Gatekeeper.mcast.net Anuncio de sesiones SAP, (Session sap.mcast.net Announcement Protocol) 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 ( Se trata de programas bastante antiguos que hoy en día están declarados obsoletos, pero que presentan algunas características P4-6

7 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 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 , 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 ( ). 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 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

8 la dirección la sesión se llamará AR Además le debes asignar una descripción (el campo Description no puede estar en blanco). 1. En la etapa 1 elegirás el valor por defecto (sesión tipo Test). 2. 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). 3. 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 /16, que tienen restringido el alcance al ámbito local. 4. 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. 5. En la etapa 5 Provide Contact Details deja los valores por defecto (en blanco). 6. 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 /16, de lo contrario nos habría asignado direcciones del rango /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 M- JPEG 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

9 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

10 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 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 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 (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

11 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 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) Dirección global asignada por el IANA b) Bloque para asignaciones ad-hoc c) Direcciones de Stream Protocol d) Bloque SAP/SDP e) Direcciones para SSM (multicast específico de la fuente) f) glop addressing g) 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

12 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

13 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 x.y utiliza para emitir la dirección multicast 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 /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: 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 ( x.y representa la dirección de la emisión): 1. Arrancar el programa VLC media player 2. Seleccionar en la ventana que aparece el menú Medio 3. Elegir de la lista la opción Abrir volcado de red 4. Seleccionar la pestaña Red e introducir como URL: rtp://@ x.y: Pulsar el botón Reproducir El cliente está listo para recibir la emisión multicast en la dirección 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) 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 Ethernet.mpg Carmen.mpg Duración 10 minutos 3 minutos Codec de vídeo MPEG-1 MPEG-2 Resolución 352x288 (CIF) 720x576 Frecuencia de refresco 25 fps 25 fps Caudal de vídeo 1500 Kb/s 4500 Kb/s Codec de audio MPEG-1 Capa II MPEG-1 Capa II Frecuencia de muestreo 44,1KHz 48 KHz Canales 2 (stereo) 2 (stereo) Caudal de audio 224 Kb/s 192 Kb/s Ambos ficheros deben encontrarse en el escritorio. P4-13

14 El procedimiento para poner en marcha la emisión en el servidor VideoLAN es el siguiente: 1. Arrancar el programa VLC media player 2. Seleccionar el menú Medio 3. Elegir de la lista la opción Emitir 4. Seleccionar la pestaña Archivo 5. Pulsar el botón Añadir y seleccionar el fichero correspondiente ( Ethernet.mpg ó Carmen.mpg ) 6. Pulsar el botón Emitir 7. 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. 8. 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 ( 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). 9. 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. 10. Pulsar el botón Siguiente. 11. 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