Unidad de Control Multipunto para Videoconferencia basado en Software Libre con integración a la Red Académica VoIP de Argentina

Transcripción

1 Cuarta Conferencia de Directores de Tecnología de Información, TICAL2014 Gestión de las TICs para la Investigación y la Colaboración, Cancún, del 26 al 28 de mayo de 2014 Cuarta Conferencia de Directores de Tecnología de Información y Comunicación en Instituciones de Educación Superior: Gestión de las TICs para la investigación y colaboración Unidad de Control Multipunto para Videoconferencia basado en Software Libre con integración a la Red Académica VoIP de Argentina Mariano Javier Martín a, a Universidad Nacional de Villa María (U.N.V.M.), Entre Ríos 1341, CP5900 Villa María, Argentina marianojm@unvm.edu.ar Resumen. Si bien el desarrollo de las redes VoIP en el ámbito académico latinoamericano cuenta con un crecimiento sostenido durante los últimos 5 años, el grado de integración entre las mismas no se ha visto reflejado de igual manera. Durante el desarrollo de la conferencia TICAL 2011 se generaron nuevos espacios de trabajo que permitieron concretar la iniciativa de integrar las redes de Voz sobre IP (VoIP) entre Brasil y Argentina. Actualmente RedClara mantiene su proyecto destinado a brindar un Punto de Intercambio de Tráfico VoIP (PIT-VoIP) para interconectar las Redes VoIP de sus NRENs miembros. La Red Académica VoIP de Argentina, coordinada por las Universidades Nacionales de Villa María y San Luis llevaron adelante numerosas líneas de acción a fin de incentivar la participación de las diferentes instituciones para que se involucren en el tema VoIP profundizando la colaboración entre las mismas. Estas acciones fueron replicadas a nivel Latinoamérica con resultados positivos en varios países. En la actualidad el desafío debe enfocarse en incrementar la integración de sus plataformas de comunicaciones. El objetivo a perseguir debe ser: simplificar y mejorar el contacto y la colaboración entre los diferentes actores que integran la comunidad académica. En este sentido, la incorporación de una plataforma basada en software libre, destinada a brindar un servicio de videoconferencia multipunto fiable y económico dentro de la infraestructura VoIP existente, resulta muy conveniente. Reforzar aquellos aspectos que producen estancamiento en los proyectos de integración en VoIP aportando al desarrollo de nuevas herramientas y servicios que enriquezcan y mejoren la infraestructura de red es fundamental. Palabras Clave: Universidades, Voz sobre IP, Redes Académicas, VoIP, telefonía IP, Videoconferencia, Teleconferencia, Seguridad, Calidad de Servicio, SIP, Asterisk, Punto de Intercambio de Tráfico VoIP, MCU

2 1 Red Académica VoIP de Argentina 1.1 Sistema Universitario Argentino El sistema universitario público argentino está conformado por: cuarenta y seis (46) Universidades Nacionales y siete (7) Institutos Universitarios Estatales. Según estadísticas del año 2009 se cuenta con un total aproximado de alumnos y la planta de personal supera los entre docentes, autoridades y administrativos. Fig. 1 Distribución geográfica de las Universidades Nacionales de la R.A. La ARIU (Asociación Redes de Interconexión Universitaria) es un esfuerzo conjunto de las universidades nacionales e institutos universitarios integrantes del CIN (Consejo Interuniversitario Nacional) con el propósito de llevar adelante la gestión de redes para facilitar la comunicación informática a nivel nacional e internacional de estas instituciones, promoviendo la investigación informática, tecnológica, educativa y el desarrollo cultural en el área de las tecnologías de información y comunicaciones (TIC).

3 Actualmente la ARIU entrega el servicio de acceso de Internet a sus miembros y sus costos son financiados por las instituciones asociadas y el Ministerio de Educación de la Nación. La topología de la red es de malla completa. En el sitio central (datacenter) se encuentra instalado un router con administración de la ARIU y conexión a la Internet mediante Telecom Argentina y conexión a Redes Avanzadas Internacionales a través de InnovaRed y RedClara. 1.2 Red VoIP El proyecto de Red Académica VoIP surge a comienzos del año 2009 [1] como necesidad concreta de brindar un servicio espécifico sobre la Red de Interconexión Universitaria Argentina (ARIU). Inicialmente la propuesta [1] es generada desde una de las Universidades Nacionales (Villa María) y posteriormente su despliegue, implementación y mantenimiento se coordina en forma conjunta con los equipos técnicos de las Universidades Nacionales de Villa María y San Luis En la actualidad (año 2014) la red está integrada por treinta y cinco (35) instituciones; veintisiete (27) Universidades Nacionales, cuatro (4) Centros Científicos y Tecnológicos pertenecientes al CONICET (Consejo Nacional de Investigaciones Científicas y Técnicas de Argentina), el Consorcio de Sistemas de Información Universitaria (SIU), el Centro de Operación de la Red de Interconexión Universitaria (NOC de ARIU), el Consejo Interuniversitario Nacional (CIN) y recientemente Innova-Red. Todas ellas aportan al sistema más de diez mil (10000) internos o extensiones telefónicas. El grado de integración de dichas instituciones varía y actualmente se trabaja en cada una de ellas para incorporar la totalidad de sus usuarios. 2 Integración de Redes Académica VoIP en Latinoamérica 2.1 Punto de Intercambio de Tráfico de RedClara Red Clara (Cooperación Latino Americana de Redes Avanzadas) en conjunto con RNP (Red Nacional de Educación e Investigación del Brasil) han desarrollado un proyecto destinado a crear un Punto de Intercambio de Tráfico VoIP para sus redes académicas (NRENs) miembros. El objetivo del mismo es integrar las diferentes plataformas de telefonía existentes en las instituciones académicas latinoamericanas empleando para ello la tecnología de voz sobre IP (VoIP) y protocolos de comunicación abiertos y escalables. Esto permite contar con un servicio de comunicación unificado, reducción de costos y mejoras en la calidad de la comunicación; aportes de los cuales está exenta la red actual por sus limitaciones. Actualmente el PIT-VoIP se encuentra desplegado y administrado como parte de la infraestructura de Red Clara. A pesar de la gran importancia que hoy tiene contar con un servicio de encaminamiento de llamadas regional como el PIT-VoIP cuyo ámbito natural de despliegue e implementación es Red Clara, no hay que perder de vista la importancia que posee la colaboración asociativa y horizontal entre instituciones universitarias y reforzar el carácter cooperativo para que la herramienta finalmente sea aceptada por el

4 conjunto, se constituya, se fortalezca y mejore en calidad a medida que transcurra el tiempo. Fig 2. Proyecto de PIT-VoIP de Red Clara y su inserción en Latinoamérica 2.2 Integración de las Redes Académicas VoIP de Argentina y Brasil En el marco de la Primera Conferencia de Directores de Tecnologías de Información y Comunicación de Instituciones de Educación Superior, TICAL 2011 y como resultado de las presentaciones [4] [5] realizadas por Mariano Javier Martín y Fernando Aversa quienes expusieron la experiencia en el despliegue de una Red VoIP entre Universidades Públicas y Antonio Fernandes Nunes, de la red académica de Brasil, quien se refirió a los diferentes servicios que brinda actualmente RNP, surgió la iniciativa de integrar la redes de Voz sobre IP de ambos países. Una vez que los equipos técnicos realizaron los ajustes necesarios, el 4 de Julio de 2011 se alcanzó la integración de los proyectos fone@rnp [6] de Brasil y la Red Académica VoIP de de Argentina a través de un acuerdo que permite establecer llamadas de voz sobre IP entre las comunidades académicas y de investigación de estas dos naciones. Actualmente se está trabajando para ampliar las instituciones conectadas incorporando centros de investigación y otros organismos. Hoy la red está completamente operativa en treinta y dos (35) instituciones de Argentina y más de cien (100) de Brasil [7]. Gracias a este acuerdo se permite una mayor interacción y un trabajo colaborativo más eficiente a través de llamadas de voz sobre IP dentro de la comunidad académica y de investigación de más de ciento treinta y cinco (135) instituciones procedentes de ambos países ya que cuentan con la posibilidad de comunicarse de forma efectiva y a bajo costo. Este es uno de los primeros resultados obtenidos tras la Primera

5 Conferencia TICAL y convierte en un elemento fundamental para una pronta integración regional a través de Red Clara. Posterior a la concreción de la iniciativa, se realizaron múltiples acciones tendientes a fortalecer lazos entre ambos países. Estas actividades consistieron de: reuniones presenciales y por videoconferencia entre miembros de RNP y el resto de la comunidad académica Argentina. A pesar de ello, y teniendo en cuenta el tipo de proyecto planteado se hace fundamental para éxito del mismo un trabajo mancomunado y colaborativo de todos los equipos técnicos de las instituciones participantes. A raíz de la sinergia generada y el éxito obtenido comienza a avizorarse la necesidad de contar con un nuevo ámbito de discusión de otros temas relacionados con las TICs en el marco de las instituciones de educación superior en Argentina. Es así que surge la primer convocatoria para realizar TICAR 2012 denominado inicialmente como Foro de Responsables de TICs de las Universidades Nacionales en Agosto de Proyecto NRENUM.net de TERENA Para que la convergencia entre el Sistema Telefónico Público disponible hoy y la Telefonía por Internet o Voz sobre IP (VoIP) y que el desarrollo de nuevos servicios multimedia tengan menos obstáculos, es fundamental que los usuarios puedan realizar sus llamadas tal como están acostumbrados a hacerlo, marcando números. ENUM [22] emplea un conjunto de protocolos para convertir el sistema de numeración utilizado en la telefonía convencional (E.164) en direcciones de servicios de internet (URIs), de modo que el sistema de numeración E.164 usado en la telefonía convencional tenga una función de correspondencia con las direcciones URI en Internet. ENUM basa su funcionamiento en el sistema de resolución de nombres de dominio (DNS). Mediante registros NAPTR ("Naming Authority Pointer Resource Records" tal como lo define el RFC 2915), se define la correspondencia entre el número telefónico y la URIs correspondiente. ENUM resulta muy importante y útil durante la actual etapa de convergencia de los servicios de comunicaciones convencionales a Internet ya que permite emplear los los teléfonos que solamente tienen 12 teclas, para acceder a servicios de Internet. EL RFC 3761 discute como se emplea el DNS para identificar los diferentes servicios disponibles correspondientes a un número E.164. RIPE NCC provee la operación de la zona DNS "e164.arpa" (conocida como Golden ENUM tree). NRENum.net [19] es un servicio ENUM que ofrece TERENA destinado a la comunidad académica internacional. El beneficio más importante de NRENum.net es permitir a las NRENs que poseen sistemas de VoIP desplegados acceder a otros usuarios a través de Internet, pasando por alto el sistema convencional de telefonía evitando los gastos que su implicaría su uso. NRENum.net es un servicio llevado adelante por TERENA (Trans-European Research and Education Networking Association) y sus NRENs (National Research and Education Networks) participantes. Si bien inicialmente se pensó poner un límite a la prestación del servicio (2012) pero se acordó que continuará operando y recientemente abrió la posibilidad de participación a otros países no solo europeos como por ejemplo: Brasil y Argentina.

6 NRENum.net permite publicar además de la información asociada a un número telefónico y el modo de llamarlo, información sobre números o salas de videoconferencias (GDS), números de telepresencia, direcciones de correo electrónico y otras informaciones sobre ubicación. El desafio es aprovechar estas facilidades para desarrollar aplicaciones inovadoras que ofrezcan nuevos servicios y beneficios a toda la comunidad académica. Fig. 4 Participación Internacional hasta Marzo de 2014 en el proyecto NRENun.net 3 Unidad de Control Multipunto para Videoconferencia 3.1 Antecedentes A partir de la implementación de la Red Académica VoIP en Argentina comenzaron a realizarse teleconferencias periódicas entre el grupo de implementadores para intercambiar experiencias y detalles de despliegue. Esto surgió como consecuencia de una creciente necesidad por coordinar los procesos de incorporación de las instituciones a la nueva Red. En los inicios y dado que la plataforma basada en Asterisk [13] estaba ampliamente difundida se empleó el modulo denominado app_konference [14]. Para complementar su uso se desarrolló una aplicación web destinada a dar soporte a la gestión básica para el control en tiempo real de las diferentes salas de conferencia. Esto permitió la realización de varias sesiones de teleconferencias exitosas. Las versiones recientes de Asterisk proveen el módulo ConfBridge [15] con funcionalidad similar. Estos módulos realizan la mezcla y transcodificación del audio de todos los participantes en la conferencia en tiempo real, y además permiten distribuir video (switching) sin ningún procesamiento entre participantes. A través de un mecanismo automático de detección

7 de niveles de audio (VAD) se identifica al participante activo y su streaming de video, sin ningún procesamiento, se distribuye al resto de los participantes. Pero paulatinamente, con la incorporación de nuevos actores de la comunidad académica a las salas de videoconferencia comenzó a surgir la necesidad de contar con un sistema que tenga la capacidad de mezcla, distribución y transcodificación de audio y video en tiempo real. Todas ellas funcionalidades difíciles de obtener a través del empleo de software libre y equipamiento de bajo requerimiento de potencia de procesamiento. 3.2 MCU basada en Software Libre: Medooze Medooze [10] es un software libre que actúa como unidad de control multipunto (MCU) que a través de clientes SIP [23] (audio y/o video) conecta varios participantes en una conferencia multiprotocolo en tiempo real. Entre sus funcionalidades permite el manejo de fuentes de video con resolución en alta definición (HD 720p), la grabación de la conferencia, gestión de los participantes, streaming web en tiempo real y soporte WebRTC. Es compatible con cualquier servidor SIP proxy/router/registrar`[23], tal como Asterisk o Kamailo, siendo la integración algo realmente simple. Todo lo que se necesita es direccionar los URIs SIP [23] hacia la MCU. Los participantes no necesariamente deben compartir las mismas capacidades de codecs de audio/video ya que la MCU realiza transcodificación. Dispone de una interfaz de usuario Web que provee la funcionalidad de administración, configuración y gestión en el manejo de las conferencias. La MCU también provee servicio de broadcasting Flash, permitiendo la participación pasiva de mayor público en las conferencias a través de un navegador Web con soporte de Flash. Medooze se encuentra disponible en versiones open source y closed source, variando las funcionalidades y especificaciones entre cada una de ellas. 3.3 Arquitectura Distribuida de Medooze Una solución típica basada en Medooze usada como MCU se compone de los siguientes elementos: Asterisk o cualquier otro Servidor SIP Proxy/Registrar y un servidor de aplicaciones SIP tal como: Sailfin o Mobicents que permita desplegar la aplicación mcuweb. La aplicación mcuweb es un SIP Servlet que implementa toda la lógica de negocios correspondiente al servicio, maneja la señalización SIP, los comandos de la MCU a través de una interface XML RPC y provee la administración y gestión a través de una interface Web para la correcta operación del servicio. La otra parte importante de Medooze es el Mediamixer que se encarga de manejar el procesamiento multimedia. Cuando el SIP proxy recibe una llamada de video a través del protocolo SIP mediante un mensaje INVITE desde un softphone ruteado hacia una sala de conferencia, redirecciona la misma hacia el servidor de aplicaciónes SIP. La aplicación mcuweb maneja la señalización SIP, estableciendo la comunicación y uniendo al participante a la conferencia (creando la misma si es

8 necesario). La aplicación mcuweb establece el flujo multimedia RTP entre el videoteléfono y la MCU, interactuando con él vía interface HTTP XML RPC. A continuación se muestra un diagrama en bloques de la arquitectura de Medooze: Fig. 5 Arquitectura de Medooze De acuerdo a la arquitectura planteada, se diferencian claramente 3 grandes bloques: Asterisk Servicio Mediamixer Sailfin SIP Server (aplicación mcuweb) Esto posibilita la separación de funciones en diferentes servidores, reduciendo de esta manera los requerimientos de capacidad de procesamiento necesaria. Teniendo en cuenta lo expuesto, será necesario antes de la operación de Medooze definir la disposición y por lo tanto configuración de los diferentes módulos. Es decir, se deberá definir direcciones de IP, puertos y sockets empleados para comunicar los módulos entre sí. Por ejemplo, en el Mediamixer se deberá definir un IP, un bloque de puertos para el manejo del flujo multimedia RTP, un puerto donde el servicio escuchará y responderá las peticiones XMLRPC desde mcuweb. En Asterisk (o cualquier otra plataforma empleada como SIP Proxy/Registrar) deberá indicarse la dirección IP y el puerto SIP (URI) definidos en Sailfin SIP Server donde se direccionan las llamadas a la MCU. A su vez en la aplicación mcuweb desplegada en Sailfin deberá indicarse el puerto empleado para la señalización SIP y el URL utilizado para comunicarse a través de XMLRPC con el Mediamixer. Para esto último existe una aclaración importante a realizar, ya que no está reflejada en el diagrama en bloques de la figura anterior: existe la posibilidad por parte de la aplicación mcuweb que centraliza la operación de la MCU de manejar varios servidores actuando como Mediamixer. De

9 esta manera es posible la distribución del procesamiento multimedia en varios equipos de prestaciones menores reduciendo aún más los costos. 3.4 Interface de Usuario Web para Medooze Las diferentes funcionalidades que posee la interface de usuario Web de Medooze son las siguientes: Configuración y Administración Gestión y Operación Configuración y Administración En lo que respecta a la configuración inicial, será necesario definir los parámetros de los mediamixers que integran el sistema (mínimo uno). Es decir, se indicará: nombre (para su identificación posterior), URL (IP/puerto), IP para el intercambio del flujo multimedia, etc. Fig 6. Interface Web. Captura de pantalla: Parámetros de Mediamixer Antes de definir las salas de conferencia que serán empleadas, será necesario establecer los perfiles multimedia con los cuales trabajará el mediamixer: resolución, ancho de banda, cuadros por segundo, etc. Fig 7. Interface Web. Captura de pantalla: Perfiles Multimedia Una vez hecho esto, ya es posible crear las salas de conferencia. Los parámetros: Nombre de la Conferencia, DID (patrón de discado directo entrante), perfil multimedia y mediamixer que será empleado para procesar el flujo multimedia. Recordemos que es posible contar con varios servidores de este tipo.

10 Fig 8. Interface Web. Captura de pantalla: Conferencias Gestión y Operación de la MCU Durante el desarrollo de una videoconferencia, es posible realizar tareas orientadas a la gestión y operación de la misma. Existen gran cantidad de parámetros que será posible modificar en forma simultánea (online) al desarrollo de la misma. Formatos preestablecidos de composición de mosaicos de video, Resolución de Pantalla por defecto, empleo de VAD (Detección automática de Voz) para el switching de video entre participantes hacia cuadro principal, son algunos de las características factibles de ser alteradas en cualquier instante. La siguiente figura permite observar dichos elementos: Fig 9. Interface Web. Captura de pantalla: Gestión y Operación de la MCU En la figura 10 se demuestra la flexibilidad con la cual es posible establecer las diferentes disposiciones de mosaicos de video para los participantes. Permitiendo formatos de un participante por vez (con selección automática por VAD) hasta 16 en pantalla con disposición de mosaicos en matriz de 4 x 4. Cabe aclarar que esta disposición máxima de participantes es sólo para aquellos que aparecen en pantalla. No existe límite alguno (más allá de las características de potencia de procesamiento) para la cantidad de personas que pueden integrar una videoconferencia. Hasta el momento se han realizado pruebas de stress que han demostrado soportar hasta 30 participantes a la vez empleando resoluciones estándar. Dos de los formatos más empleados son la disposición 1+7 ó 1+5 (figuras 11 y 12 respectivamente) que

11 permiten hacer foco en el participante que se encuentra activo (por VAD) en el cuadro principal (de mayor tamaño). Fig 10. Interface Web. Definición de la Composición de Mosaicos de Video Fig 11. Disposición de mosaicos en configuración 1+7

12 Fig 12. Disposición de mosaicos en configuración 1+5 A continuación es posible observar la variedad de formatos, relación de aspecto y resolución de pantalla disponibles. Se destaca entre ellos el formato HD720P que es el de mayor resolución permitiendo video en pantalla completa de alta definición apto para ser empleado con equipos de videoconferencia. Fig 13. Interface Web. Captura de pantalla: Resolución de Pantalla

13 Durante el desarrollo de la conferencia es posible realizar cambios en el perfil multimedia de un participante en particular. Los cambios efectuados toman efecto de manera instantánea en el momento de ser realizados. También es posible desconectar un participante, silenciar audio y ocultar video para cada uno ellos. Fig 14. Interface Web. Manejo Online de Participantes 3.5 Capacidad de Procesamiento, Ancho de Banda y Desempeño En la figura 15 se observa el empleo de ancho de banda durante el desarrollo de una videoconferencia realizada con Medooze en la cual participaron siete (7) Universidades. Los participantes emplearon videoteléfonos con resolución VGA. Los codecs de video y audio fueron h264 y g711 respectivamente. La infraestructura de Medooze fue desplegada en ambiente virtualizado empleando una solución basada en VMware ESXi versión El sistema operativo donde fue desplegado Medooze emplea Linux, distribución Ubuntu LTS. El equipamiento empleado para virtualización posee las siguientes características: Motherboard Intel S1200BTL, CPU Intel Xeon E31220 de 4 núcleos a 3,092 Ghz, Memoria RAM total 8 GB, Almacenamiento compuesto por 2 Discos Rígidos de 1 TB de capacidad. Fig 15. Ancho de Banda durante una VC La figura 16 muestra la carga en cada núcleo de procesamiento utilizado durante la videoconferencia de prueba realizada de acuerdo a las condiciones planteadas y las características de equipamiento y software descriptas en el párrafo anterior:

14 Fig 16. Utilización de CPU durante una VC 3.6 Experiencias de uso de Medooze en el ámbito académico (RedVoIP) Actualmente el empleo de esta plataforma en el ámbito académico es frecuente dentro del marco de los responsables de TICs de las Universidades Nacionales. Hasta el momento se han realizado encuentros periódicos (a razón de 1 vez por semana) con la participación promedio de una docena de instituciones. En la figura siguiente puede observarse la captura de una imagen fija de una videoconferencia realizada el 28 de noviembre de 2012 que tuvo la particularidad de contar con la presencia desde Madrid (España) del desarrollador de Medooze: Sergio Murillo. La misma sirvió para debatir acerca de los desafíos que esta plataforma presenta hacia futuro y las posibilidades de colaboración que abre dentro del ámbito académico. Fig 17. Videconferencia realizada con 17 Universidades (28/11/2012)

15 3.7 Despliegue de Medooze en infraestructura en nube Las MCUs requieren alta capacidad de procesamiento para transcodificar y mezclar en tiempo real el flujo multimedia de audio y video. Además es necesario contar con gran disponibilidad de tráfico y buena conectividad para distribuir en tiempo real el streaming a todos los participantes a la vez. Estas características junto con la naturaleza de software libre, hacen de las infraestructuras en nube (IAAS) un ámbito ideal para el despliegue de Medooze. Se utilizaron servicios de Amazon Web Services [16], Rackspace [17] y UpCloud [18]. Todos ellos proveen el uso de maquinas virtuales de variadas características de procesamiento, memoria y discos. El pago de los recursos es por hora de uso efectivo, lo que resulta muy conveniente para el caso de una MCU, ya que se activa solamente cuando existe una conferencia programada. Durante la activación se seleccionan las características de performance de la maquina que dependen del número de participantes previstos. Según la ubicación de los participantes se puede seleccionar una zona geográfica adecuada donde desplegar el servicio. Una vez terminada la conferencia y eventualmente transferida su grabación, se desactiva la maquina virtual. Las maquinas virtuales aptas para Medooze varian entre U$S 0.06 y 0.15 la hora. Se paga además por el trafico saliente (U$S 0.10/0.12 GB) y en algunos casos por operaciones de E/S. La imagen que contiene la instalación de Medooze ocupa menos de 2GB y reside permanentemente en los discos del proveedor a un costo aproximado de U$S 0.10 GB/mes. Si bien no existen grandes diferencias entre proveedores en cuanto al despliegue inicial, Amazon Web Services provee la máxima flexibilidad de escalabilidad de performance y tráfico. Además posee centros de procesamientos de datos en varios continentes y en particular en San Pablo, Brasil lo cual resulta muy conveniente para nuestra región. 3.8 Características y funcionalidades de Medooze Durante 2013 se han incorporado a Medooze numerosas actualizaciones de software destinadas a otorgar nuevas funcionalidades y características. Podemos resumir las mismas de la siguiente manera: Interface Web de usuario para administración de las conferencias Soporte de tecnología WebRTC Empleo opcional de Servidor SIP SAILFIN ó Mobicents Codecs de video VP8, H264, MP4V-ES, H263 y H263+ Codecs de audio: PCMU, PCMA, GSM, SPEEX, NellyMoser y Opus Grabación de Conferencia Flash broadcasting (manejo de stack RTMP propio) Resolución máxima HD720P. Protocolo NAT transverso: symetric media, STUN y soporte ICE lite VAD (Detección automática de Voz) Soporte SRTP, SAVPF y rtcp muxing Soporte FEC, NACK y Bitrate Adaptation Algorithm

16 4 Avances en WebRTC y HTML5 4.1 Generalidades WebRTC [25] es una API definida por el World Wide Web Consortium (W3C) para permitir el desarrollo de aplicaciones multimedia en tiempo real (por ejemplo: llamadas de voz y video, aplicaciones Peer2Peer) en la web que funcionen directamente desde el navegador sin el uso de plugins, descargas o extensiones. Los componentes, que se acceden a través de una API JavaScript, permiten el desarrollo relativamente simple de aplicaciones. WebRTC está generando mucho interés entre los desarrolladores de aplicaciones web. Hay un gran impulso en la dirección de imponer al navegador de internet HTML5 como el destino final de las comunicaciones SIP de audio y video. WebRTC requiere el uso de dos componentes APIs Javascript, MediaStream (get User Media) y RTCPeerConnection. La API MediaStream provee la funcionalidad de capturar audio y video desde los dispositivos del cliente y convertirlos en objetos JavaScript. Creando una conexión con RTCPeerConnection, permite que el navegador se conecte directamente con los navegadores de otros usuarios, que se intercambian y negocian la información de la sesión. El método que se usa depende de cada aplicación. Estos mecanismos de negociación para intercambiar información sobre la sesión fueron deliberadamente no especificados en WebRTC, para no depender de un protocolo específico. Naturalmente, el protocolo SIP [28] es un candidato para cumplir este rol negociador. No obstante que con getusermedia y RTCPeerConecction se pueda establecer una conexión de audio y video, una aplicación completa requiere algunos APIs HTML5 [26] adicionales. Por ejemplo cuando una aplicación intente enviar un streaming a un servidor y no a otro navegador, el protocolo Websocket [29] puede servir para implementarlo. En el caso de los telefonos VoIP, que usualmente no implementan la recepción directa de datos RTCPeerConnection, requiere que los datos sean reenviados a traves de un gateway usando el protocolo WebSocket [29]. 4.2 SIP en JavaScript Existen todavía algunos desafíos técnicos importantes para implementar SIP con WebRTC, como la conexión a través de proxies y el intercambio directo entre navegadores y teléfonos. Actualmente hay varias implementaciones del protocolo SIP en desarrollo en JavaScript como por ejemplo sipml5.org y el proyecto SIP-JS. Estas tecnologías tienen un gran potencial para reforzar el despliegue de tecnologías de comunicaciones VoIP en las redes académicas, ya que reducen notablemente los requerimientos de infraestructura y simplifican la instalación. El desafío actual es encontrar maneras de integración de estas tecnologías con los proyectos regionales.

17 5 Conclusiones Los proyectos de integración en el área de comunicaciones llevados adelante en Latinoamérica desde países como Argentina y Brasil, así como el gran esfuerzo puesto de manifiesto por RedClara para el despliegue de un único punto de intercambio de tráfico en VoIP (PIT-VoIP) actúan por sí solos como elementos motivadores, y generadores de iniciativas de crecimiento y expansión en el campo de las redes académicas VoIP. Promueven la convergencia de las comunicaciones hacia las TICs. Refuerzan proyectos ya encaminados y ayudan a fortalecer nuevos. Sirven también para ayudar a orientar y mejorar la gestión de recursos hacia un red no solo de comunicaciones multimediales en tiempo real eficiente y sostenible. En este sentido el aporte que puede brindar una plataforma de videoconferencia tan flexible como Medooze es fundamental para darle un nuevo impulso a los proyectos mencionados inicialmente con el objeto de alcanzar finalmente la integración de las comunicaciones en materia de VoIP. La colaboración entre instituciones permite extender y diversificar actividades, experimentar nuevos desarrollos y compartir riesgos, potenciando los propios perfiles de cada una.

18 6 Agradecimientos El autor de este trabajo, desea expresar su agradecimiento a los referentes técnicos de cada institución de Argentina en el tema de Voz sobre IP que colaboraron activamente con sus pares en el despliegue de Medooze como servicio de valor agregado a la RedVoIP. Esto contribuyó a reforzar la infraestructura de comunicaciones existente perteneciente a toda la comunidad universitaria argentina. 7 Referencias 1. Martín, Mariano Javier, Servicio de encaminamiento de llamadas de voz sobre IP bajo protocolo SIP entre Universidades Nacionales a través de RIU (2009), 2. Martín, Mariano Javier, Red de Voz sobre IP para el N.O.C. de A.R.I.U. con integración y soporte para videoconferencia (2010) 3. Martín, Mariano Javier, Proyecto VoIP de la Universidad Nacional de Villa María (Argentina) (2008), 4. Presentación TICAL Junio de 2011, 5. Artículo Completo para Conferencia TICAL 2011, 6. Red Clara: Argentina y Brasil integran sus redes de voz sobre IP (Español), tina-y-brasil-integran-sus-redes-de-voz-sobreip&catid=6:noticias&itemid=352&lang=es 7. Proyecto fone@rnp, 8. Foro de Voz sobre IP de ARIU, 9. Proyecto Asterisk AppKonference, Infraestructura para MCU Medooze, Videoconferencia con Sergio Murillo, desarrollador principal de Medooze, Fortalecimiento de las Redes Académicas de Voz sobre IP Latinoamericanas para una Integración sostenible y sustentable. Presentación TICAL 2012, Asterisk, app_konference, ConfBridge, Amazon Web Services, Rackspace, UpCloud, Proyecto NRENum.net, WebRTC, HTML5, ENUM, Protocolo SIP, El protocolo Websocket,