Este apunte describe qué hay detrás (a nivel técnico) del servicio IP que nos ofrece Movistar Fusión FTTH (Fibra) y como sustituir el router que nos instalan por un equipo basado en Gentoo GNU/Linux, que hará de Router (junto con un Switch Ethernet) para ofrecer los mismos servicios de Datos, Televisión (IPTV) y Voz (VoIP).

Punto de partida

Veamos cual es la instalación que nos queda cuando instalan “la fibra”. El cable “negro” que nos llega a casa es una fibra (monomodo 657-A2) que el técnico “empalma” dentro de una roseta de tipo ICT-2, que a su vez ofrece un conector SC/APC de salida. De dicho conector sale un latiguillo de fibra estándar al ONT y desde ahí salen dos cables, uno de teléfono que normalmente conectan a la entrada de teléfono de tu casa y otro ethernet que se conecta al router. Ver el gráfico siguiente:

El ONT es el equipo que termina la parte “óptica”, sus siglas singnifican Optical Network Termination y se encarga de convertir la señal óptica a señal eléctrica, en concreto ofrece un interfaz Ethernet tradicional (utilizo el puerto ETH1). Salvando mucho, pero que mucho, las distancias, vendría a ser algo parecido al PTR de una línea de teléfono analógica cuando teníamos ADSL.

El siguiente equipo es el Router, que va a recibir, desde el ONT, tres VLAN’s, una para cada servicio: VLAN-6 para “datos”, VLAN-2 para IPTV y VLAN-3 para VoIP. Su función consiste en conmutar entre la VLAN apropiada y la “intranet” dependiendo de qué servicio consuma y/o qué configuración tenga el cliente (decodificador, ordenador, teléfono).

Objetivo Final

Consiste en sustituir el Router de Movistar por un equipo con Linux y un Switch Ethernet y poder ofrecer los tres servicios: Datos, IPTV y VoIP. ¿porqué un Switch Ethernet?, pues porque necesitas que alguien tenga los puertos ethernet y sobre todo porque es mucho más sencillo (y barato) que instalar tarjetas de puertos ethernet en tu Linux… Importantísimo que tu Switch Ethernet 10/100/1000 tenga soporte de VLAN’s (802.1q) y Multicast (IGMP Snooping), y sobre todo que tu equipo Linux tenga una NIC que soporte VLAN’s (es lo más habitual).

Ah!, si tienes que adquirir dicho switch y ya puestos te recomiendo que aproveches y soporte “port mirroring” que te vendrá muy bien para hacer “troubleshooting” capturando y analizando el tráfico con WireShark.

En el gráfico anterior tienes la configuración final, en mi caso uso un Mac Mini “reconvertido” con Gentoo GNU/Linux (y que en breve voy a evolucionar a un equipo NUC de Intel, pero eso es otra historia), y un Switch Ethernet SG 200-08 de Cisco, conecto la salida Ethernet (ETH1) del ONT al puerto del Switch (donde configuraré las vlan’s 2, 3 y 6 tagged; en mi ejemplo he usado el puerto 1), conecto el Linux al puerto-2 (donde configuro las vlan’s 2, 3, 6 y 100 Tagged) y el resto de puertos quedan configurados como de acceso de la vlan 100 (untagged)  donde conectaré los equipos de la Intranet: ordenador, punto de acceso wifi y Deco.

Configuración completa de la red

A continuación voy a entrar de lleno en mostrar los detalles necesarios sobre la configuración del Linux para que puedas comprender cómo hacerlo funcionar. Empiezo por un resumen general de toda la configuración de red del equipo para luego entrar al detalle de los tres servicios.

Configuración de la interfaz de red y las VLAN’s en Linux (recuerdo que es la distro de Gentoo, en tu caso podrá ser otra por lo que los ficheros aquí documentados te tienen que servir de ejemplo y referencia):

La configuración del fichero anterior supone lo siguiente:

• WAN (Exterior)
  • vlan6 (datos) – PPPoE para recibir la IP. Ruta por defecto
  • vlan2 (iptv) – IP estática y RIP para recibir rutas IPTV
  • vlan3 (voip) – IP vía DHCP. Ruta vía RIP. No DNS/NIS/NTP
• LAN (Interior)
  • vlan100 (intranet) – Rango privado 192.168.1/24 y la “.1” al linux.

Salida del comando ifconfig

Notar que he cambiado las IP’s para hacerlas coincidir con el gráfico anterior.

Routing (RIP pasivo)

Me anticipo a algo que vas a necesitar y lo dejo ya documentado. Telefónica utiliza RIP Pasivo para mandarnos varias rutas para su servicio IPTV y una única ruta para su servicio VoIP. Es recomendable activar RIP (pasivo) en la interfaz VLAN2 y la VLAN3. Otra opción es configurarlas a “pelo” (rutas estáticas). En mi caso he preferido usar RIP, así que he instalado Quagga (fork de Zebra)

Gentoo: emerge -v quagga

Muestro a continuación las rutas que tendrás una vez  que tengas TODO funcionando (Ojo que no hemos llegado, pero aquí te pongo el resultado final)

Arranque en Gentoo:

Puedes conectar con ambos daemons y ver qué está pasando. Primero con el daemon general de zebra:

Después con el daemon ripd

Source NAT

Para que los equipos de la Intranet (PCs, ordenador, teléfono WiFi) puedan llegar a Internet hay que hacer Source NAT. Para que los Decos puedan llegar a Imagenio también hay que hacer Source NAT y para que los teléfonos VoIP o aplicaciones VoIP puedan llegar a su servicio también hay que hacerles Source Nat.

El equipo sabrá qué tráfico va a Internet, a IPTV y a VoIP gracias al routing (a la dirección destino), así que con tres líneas de iptables y esta información de dirección destino, el equipo se encargará de conmutar usando el interfaz de salida adecuado y cambiar y poner la dirección IP fuente adecuada

El tráfico del Deco querrá ir siempre a direcciones que empiezan por 172.26*, por lo tanto el equipo linux los querrá sacar por la VLAN2. Lo mismo pasa con el tráfico que quiera ir a la dirección del proxy VoIP (10.31.255.128/27), que saldrá por la VLAN3. Para el resto de tráfico se conmutará por el enlace ppp0.

A continuación muestro las líneas para configurar el Source NAT para los tres interfaces.

Para la vlan 6 (datos internet)

Para la vlan 2 (IPTV)

Para la vlan 3 (VoIP)

I. Servicio de acceso a Internet (vlan6)

Como acabo de mencionar, recibimos Internet por la VLAN-6 y se utiliza PPPoE (PPP over Ethernet) para recibir la dirección IP, así que lo único que hay que hacer es activar PPPoE sobre el interfaz VLAN6 (ver el ejemplo anterior /etc/conf.d/net)

Si tienes problemas te recomiendo que añadas una linea que simplemente ponga “debug” sin comillas, dentro de la opción pppd_ppp0=”…”. Así podrás observar en el syslog lo que ocurre. Una vez lo tengas estable quita dicha línea. Tanto si has contratado una IP fija como una dinámica la configuración es la misma, al arrancar el daemon PPP el equipo recibirá su IP, instalará una ruta por defecto por dicho interfaz y listo.

OJO!: Una de las desventajsa de PPPoE es que reduce la MTU a 1492 y el MSS (Maximum Segment Size) negociado de TCP a 1452, así que tenemos que hacer lo mismo en nuestro Linux. ¿Dónde?, pues la MTU en un sitio y el MSS en otro…:

• MTU: El PPPD se encarga de definir la MTU en el fichero anterior de configuración (/etc/conf.d/net)
• MSS: El MSS se tiene que configurar con “iptables”

Dentro de iptables tenemos dos opciones para especificar el MSS:

• --clamp-mss-to-pmtu Restringe el MSS al valor del Path MTU menos 40 bytes = 1452
• --set-mss Pone el valor a “pelo”, (equivale al comando IOS: ip tcp adjust-mss 1452)

En mi caso uso la primera opción, he añadido las líneas siguientes al “principio” de mi script donde tengo todos los comandos iptables, de modo que afecte a todos los paquetes:

Preparamos el arranque futuro

Arranque en Gentoo:

Recibirás una IP fija o dinámica dependiendo de tu contrato. Dicha IP será del tipo 80.28.PP.PP. Nota que en mi caso empieza así y termina con la IP que tengo asignada (contraté una IP fija), pero en el tuyo puede ser cualquier otra cosa, depende de lo que Movistar haya provisionado en tu caso…
 

II. Servicio de Voz VoIP (vlan 3)

El Servicio VoIP nos llega por la VLAN-3. La configuración es sencilla, el equipo linux debe recibir una dirección IP mediante DHCP, hacer Source NAT por esta interfaz e instalar una única ruta (Ojo!, instalar un único prefijo específico para dicha ruta, no ponerla como ruta por defecto, o default route).

Cliente dhcp

En la configuración cliente DHCP de linux hay que especificar que “no” sobreescriba NIS, NTP ni DNS, y además que “no” se instale una ruta por defecto por dicha VLAN3. Lo vimos en la configuración de la red al principio, pero como recordatorio estas son las líneas específicas en /etc/conf.d/net

Source NAT

Debes hacer source NAT, de modo que el tráfico originado por tu cliente SIP (que reside en la VLAN100 con dirección 192.168.1.xxx)  que salga por la vlan3 lo haga con la dirección IP fuente del linux (recibida por dhcp y del estilo 10.25.ZZZ.ZZZ), como recordatorio estos son los comandos que ejecuto:

Routing: “la ruta”

Por este interfaz solo vamos a necesitar una única ruta y podemos aprenderla por RIP pasivo o bien instalarla manualmente. En mi caso he preferido usar RIP.  Lo vimos al principio, estas son las líneas específicas en /etc/quagga/ripd.conf

Para que puedas comprobar si lo estás configurando bien, estas son las rutas que deberías recibir:

Clientes SIP

Deberías estar ya preparado para probar con un cliente SIP desde un ordenador de la intranet (vlan100) o desde un teléfono SIP. Aquí tienes un artículo donde compara muchos clientes VoIP.

Los datos que necesitas son los siguientes:

He probado con un par de clientes, la versión gratuita de “Zoiper” para MacOSX, funciona pero no me ha dejado muy convencido. En cualquier caso, esta es mi configuración:

Otro cliente para MacOSX mucho más simple es Telephone, está disponible en la App Store, es gratuito y la verdad es que me ha gustado más, por simple, que el anterior.

Otro cliente que he probado es “PhonerLite” para Windows (en mi caso ejecutado en Parallels para MacOSX), y tengo que decir que ha funcionado mucho mejor, (muy limpio y sin errores al ver el tráfico de registro, llamadas, recepción de llamadas). Una pena que solo exista para Windows.

Durante las pruebas de VoIP me he quedado con una sensación de inestabilidad, aparentemente no se registra a veces, alguna llamada no llega a sonar en el Softphone, por lo que tengo seguir investigando. También he detectado mucha diferencia entre un software y otro (en cuanto a estabilidad). El tráfico entre el softphone y el servidor de registro ocurre en UDP y es importante que tengas activo SourceNAT en el linux tal como describí en la sección de red.

III. Servicio de Televisión (vlan2)

El tráfico IPTV es entregado desde el ONT a través de la VLAN-2, por donde encontraremos los servicios OPCH, DVBSTP y Streams Multicast.

• OPCH: Servidores Imagenio que indican al deco la configuracion del portal, pelis, etc..
• DVBSTP: Protocolo de transferencia para el servicio SD&S (Service Discovery & Selection), mediante el cual se manda a los decos información de programación y de canales. Aquí tienes un enlace al estándar.
• Streams Multicast: Son los flujos de tráfico con dirección destino “multicast”, es decir entre otros, los streams MPEG con los datos del canal de televisión al que se haya suscrito el Deco.

En la VLAN2 es importante que utilices la misma dirección IP estática asignada por Movistar al Router original, es decir, debes averiguar qué dirección del tipo 10.214.X.Y/9 tiene. Para encontrar dicha IP tienes un par de opciones: 1) acceder a la configuración del router original o 2) “espiar” con tcpdump o wireshark el tráfico de la van 2 (si tu switch soporta port-mirroring).

Nota: Si quieres intentar la opción (1),configuración del router original, tendrás que cambiarle la contraseña del Router de Movistar. Ojo! que dejará de ser gestionable desde el portal de Movistar así que haz esto bajo tu responsabilidad y sigue este sencillo proceso: Haz un reset del router a factory defaults, arráncalo de nuevo y conéctalo al ONT, se auto-provisionará y se le asigna una contraseña aleatoria, espera a que todo funcione de nuevo. Entra a la configuración del router vía Alejandra (movistar.es->Mi Movistar->Configura tu router). Entre los menús verás una opción “Contraseña”, sigue todos los pasos (pedirá múltiples confirmaciones) para cambiar la contraseña. A partir de ahí ya puedes conectar al router desde tu intranet, usando http://192.168.1.1, usuario 1234 y la contraseña que hayas puesto.

Tipo de tráfico en la vlan 2

A continuación el tipo de tráfico que he visto en la vlan2 con WireShark:

• Desde el Deco hacia Imagenio:
  • Consultas via udp al DNS Server (172.26.23.3)
  • Conexión vía HTTP/TCP a Servicios Imagenio (172.26.22.23), por ejemplo Grabaciones, Configuración, Personalización, …
• Desde Imagenio hacia el Deco [UDP – Flujos Multicast]:
  • 239.0.[0,3,4,5,6,7,8,9].* CANALES.
  • 239.0.2.30:22222 OPCH
  • 239.0.2.129:3937 DVBSTP
  • 239.0.2.131:3937 DVBSTP
  • 239.0.2.132:3937 DVBSTP
  • 239.0.2.155:3937 DVBSTP

DHCP para los Decos

En la VLAN-100 tengo los equipos normales que acceden a internet, ordenador, portátil. Además tenemos el Decodificador (o decodificadores). Para facilitar el trabajo de provisión (asignación de IP’s, etc…) empleo un DHCP server en Linux y entrego a cada equipo de la red su dirección IP, la IP del DNS server, etc. Creo un pool para los equipos normales y asigno IPs estáticas y específicas para cada dirección MAC del Deco (su dirección MAC la tienes en una pegatina en la parte de atrás del mismo). Verás que además le entrego la dirección del OPCH.

Ejemplo de configuración usando el DHCP Server de ISC

IGMP Proxy

Los JOIN’s de los Decos entrarán por la VLAN100 al Linux y será responsabilidad de este útimo re-enviarlos hacia la VLAN2. Esto se puede hacer de dos formas 1) Activando en el Kernel la opción de convertirlo en un Bridge Ethernet o 2) mucho más fácil y recomendado: usar un programa llamado “igmpproxy”.

Este pequeño programa hace dos cosas:

• 1) Escucha los Joins/Leaves IGMP de los Deco’s en el interface downstream (VLAN100, donde están los decos) y los replica en el interfaz upstream (VLAN2 donde están las fuentes). En el mismo instante en que replica (envía a movistar) el JOIN se empezará a recibir por el interfaz upstream (VLAN2) el tráfico multicast (el video).
• 2) Instala y “Activa” rutas en el kernel del Linux para que este (kernel) conmute los paquetes multicast. En el mismo momento en que recibió el JOIN (1) intentará instalar y “Activar” una ruta en el Kernel. Si lo consigue entonces el Kernel empezará a conmutar (forwarding) los paquetes que está recibiendo por el VLAN2 hacia los el(los) Deco(s) en el interfaz VLAN100 (downstream).

Preparar el Kernel para la Conmutación Multicast

Nos concentramos en la capa de conmutación, asumimos que lo anterior está ya funcionando y empiezan a llegarnos paquetes multicast UDP por el interfaz upstream (VLAN2). Tenemos que instalar/activar rutas en el Kernel y “convencerle” de que conmute el tráfico, tiene que hacer routing multicast, por lo tanto es muy importante que tengas configurado lo siguiente en el Kernel:

Después viene la parte que más dolores de cabeza genera, ya tenemos todo, pero “no funciona”, el tráfico llega por la VLAN2, el multicast está activo en el kernel, igmproxy arrancado, pero “NO SE ACTIVAN” las rutas. Sí parece que las instala en el kernel pero “no se activan”.

¿Cual es la solución?, pues consiste en desactivar la comprobación RPF (Reverse Path Forwarding) en “ALL” y en el interfaz upstream (VLAN2), que es por donde viene el tráfico desde las fuentes, debes ejecutar los dos comandos siguientes durante el boot de tu equipo:

¿Por qué debo desactivar RPF?. Porque lo normal es que las fuentes envían su tráfico desde direcciones IP que no tengo en mi tabla de routing y en linux por defecto tenemos activo (“1”) el RPF, así que se “bloquean” dichos paquetes. La forma más sencilla de solucionarlo es 1) insertar rutas a dichas fuentes a través de la vlan2 o 2) desactivar RPF (opción que he elegido en mi caso), de modo que el Kernel permite “activarlas” y a partir de ese momento veremos como empieza a conmutar el tráfico.

Tienes que desactivar (0) en All y en vlan2, dejando el resto activas (1), donde el RPF seguirá actuando. Notarás que la loopback (lo) también está desactivado, es correcto.

Source NAT y Firewall (iptables)

Aunque ya lo expliqué antes, recordatorio: para que los paquetes de los Decos salgan hacia la VLAN2 con tú dirección IP (en la vlan2) es necesario hacer Source NAT.

Opcional, si tu Linux es un router de internet y usas iptables para hacer de firewall, recuerda aceptar los paquetes multicast. Te dejo un recordatorio:

Instalación y configuración de igmpproxy

Primero tenemos que instalar el programa, aquí tienes un ejemplo en Gentoo: emerge -v igmpproxy

A continuación debes modificar el fichero de configuración:
Nota: En la configuración es importante que se añada el prefijo de las fuentes en el upstream (línea donde pongo altnet 172.0.0.0/8). Notar que hago un agregado muy exagerado pero no importa en mi caso porque no tengo más fuentes multicast en mi red.

Arranque en Gentoo:

Resolución de problemas

Comprueba varias cosas si estás teniendo problemas con el servicio de IPTV. Para empezar deberías poder hacer ping al DNS Server interno que tiene Movistar en su propia red para este servicio de Televisión.

OJo!. Algunos me han comentado que a ellos no les funciona este “ping” pero sí les va el resto de funciones. De hecho a mi me ha estado funcionando muchos meses y de repente ha dejado de funcionar, así que mejor usa lo siguiente, esto Sí que debería funcionar y es consultas DNS. Prueba por ejemplo a consultar el registro SOA del dicho DNS Server:

En vez de arrancar el daemon en el background, durante las pruebas o para resolver problemas y ver “qué está pasando” ejecuta igmpproxy manualmente de la siguiente forma:

Además puedes ir comprobando en otros terminales cómo se van insertando las rutas multicast en el kernel, el tráfico que pasa por cada fuente, etc…

Verificar que tienes activo el routing (y desactivo el RPF) en el kernel:

Verificar cómo tienes el RPF

IGMP Snooping

Es importante evitar que la intranet donde están los DECO’s (u otros receptores) se llene de tráfico Multicast en todos sus puertos. Si no hacemos nada, al enviar tráfico multicast hacia la VLAN100 el switch replicará en todos los puertos que pertenezcan a dicha vlan, es decir, una tormenta de tráfico innecesario que no necesitamos, de hecho donde menos lo queremos es en los puntos de acceso Wifi, imagínate recibiendo 10, 20, 30Mbps extra, supondrá un desastre para la calidad de los clientes Wifi.

Para solucionarlo no hay que hacer nada en el linux, solo en el switch ethernet. Es tan simple como activar IGMP Snooping, que normalmente podrás hacer por puerto, grupos de puertos, por vlan, etc. depende del switch.

Al activarlo estamos pidiendo al switch que espíe el tráfico IGMP, mantenga un mapa de qué puertos piden suscribirse a los flujos (multicast) y así saber a quién mandar y a quién no.

Ver la TV

Si has llegado hasta aquí entonces estarás deseando “ver” la TV y para hacerlo tenemos varias opciones. La primera y más evidente es utilizar el “Deco” que nos entrega Movistar con el servicio, pero también podrías intentar usar algún cliente IPTV.

Cliente “Deco” de Movistar

Es el método más claro y sencillo de todos, para configurarlo pulsa repetidamente la tecla menú después de arrancarlo; cuando está parpadeando el último cuadro durante el boot. Entrarás en el menú de configuración del firmware y desde ahí podrás activar (viene así por defecto) que use DHCP. Lo de entrar con la tecla menú realmente no hace falta, solo es para ver que recibe la IP correcta desde el DHCP Server.

Una vez que lo tengas encendido y conectado a tu TV debería funcionar todo, bueno, casi todo (más adelante verás el tema de Acceso a videos bajo demanda).

Cliente IPTV “VLC”

Otro método evidente y sencillo, usar el mejor cliente de video que existe: VLC. De hecho, antes de intentar otras opciones es la que te recomiendo, una vez arrancado en tu ordenador, selecciona “Abrir Red” y utiliza el URL siguiente: rtp://@239.0.0.76:8208, para ver TVE-1. Ya está, no hay mucho más que hacer, has utilizado VLC como cliente IPTV con protocolo multicast.

Lista de canales, puedes salvarlas en un fichero con el nombre Movistar.m3u y usarlo desde VLC:

TVHeadend (como cliente IPTV)

Otra opción mucho mejor, pásate al mundo de los Media Center’s, donde necesitaras clientes del estilo XBMC/KODI en ordenadores o en Raspberry’s. Para poder “servirlos” el mejor que he probado hasta ahora es Tvheadend, así que te recomiendo instalar Tvheadend (GitHub tvheadend), se trata de un DVR (Digital Video Recorder) y un servidor de streaming de TV que soporta todo tipo de fuentes: DVB-C, DVB-T(2), DVB-S(2), ATSC y además “IPTV (UDP o HTTP)“, siendo esta última precisamente la que me interesa.

La pregunta sería ¿para qué quiero un Servidor de Streams de TV si “eso es precisamente” lo que ya tengo funcionando?. La respuesta es que no voy a usarlo para recibir fuentes de satelite ni TDT y convertirlas en streams multicast. Lo voy a usar como intermediario que lee los streams multicast de Movitar TV y los entrega en protocolo HTSP a clientes IPTV de mi red.

Una de sus ventajas es que puedes emplear Media Centers “baratos” como por ejemplo una Raspberry Pi con OpenELEC (XBMC) que trae de serie el cliente HTSP de Tvheadend (échale un ojo a este otro apunte sobre Media Center integrado con Movistar TV), y otra ventaja importante es que con TVHeadend podremos integrar el EPG de movistar TV.

El proceso de instalación es el siguinete, notar que estoy instalando la última versión disponible en GitHub porque me interesa que la versión sea 3.9+ para poder aprovechar toda su potencia:

Una vez que lo he arrancado ya puedo conectar con su interfaz web usando el puerto 9981 (http://dirección_ip_de_tu_linux:9981), podré dar de alta las fuentes IPTV, los canales y “ver” quién está accediendo a ellos. En el ejemplo siguiente he configurado dos canales:

A continuación configuro mi cliente Raspberry Pi con OpenElec para que conecte con TVheadend usando el plugin “TVHeadend HTSP Client”

Una de las ventajas que tenemos es la posibildiad de monitorizar quién está usando el servicio y cuando ancho de banda está consumiendo (un canal HD de movistar suelen ser ~10Mbps).

Existen más opciones de clientes IPTV pero te dejo a ti que sigas investigando, ahora bien, en tu red quizá necesites poder acceder al servicio usando el protocolo HTTP en vez de multicast.

udpxy

Para conseguirlo tenemos este pequeño paquete que es simplemente genial. Se trata de un Daemon que permite hacer relay del tráfico multicast UDP hacia clientes TCP (HTTP). Es decir, él va a tratar por un lado el tráfico multicast y por otro nos dejará ver los canales en HTTP. Traducido: sirve para que desde cualquier clientes PC’s, Mac’s, Linux, etc. con un cliente IPTV que solo soporta HTTP podamos ver los canales.

Primero lo instalo (Gentoo): emerge -v udpxy y lo configuro:

En este caso estamos diciendo que escuche por el puerto tcp:4022 en la vlan100, que se suscriba a los grupos multicast a través de la interfaz vlan2 y con el argumento -c 16 le decimos que soporte hasta 16 clientes (ojo que por defecto sirve un máximo de 3 clientes). Cuando un cliente le pida ver un canal concreto por la vlan100 (en http), él se suscribirá a dicho canal por la vlan2 y en cuanto empiece a recibir el video (vía multicast por vlan2) lo reenviará al cliente pero en HTTP por la vlan100

Arranque en Gentoo: /etc/init.d/udpxy start

A partir de aquí ya podremos conectar con las fuentes usando el protocolo HTTP. A modo de ejemplo con VLC usando la siguiente dirección de Red deberías ver TVE2:

• http://192.168.1.1:4022/udp/239.0.0.2:8208

De nuevo dejo la lista de canales completa pero ahora con el formato HTTP por si quieres usarlo así desde VLC, es decir por si prefieres la opción de UDPXY en vez de IGMP Proxy y el protocolo RTP.