...
Tambien he visto que "alguien" (Goomer) ha posteado que ha consguido hacer funcionar el modulo RTSP-contrac pero parece que instalandolo directamente en debian, aunque no indica los detalles concretos de como lo ha realizado...
Hola jirm, pensaba que mi publicación estaba lo suficientemente claro, además indiqué los detalles, eso sí, sólo lo que se diferencia de lo que hizo jfm y Noltari. Intento detallarlo mejor.
Obtengo el software del módulo nat_rtsp aplico el parche que indica Noltari
http://pastebin.com/XsyyCxzW, además este parche Noltari dice haberlo adaptado a la versión actual de OpenWrt. Después de esto y una vez comprobado que el módulo no me funcionaba para ver las grabaciones en movistar tv, haciendo debug compruebo que el conntrack añade la ip de destino del diálogo rtsp a lo que debe esperar para casar con la red interna, fíjate en lo que espera (expect_related):
found a setup message
tran='Transport: MP2T/H2221/UDP;unicast;client_port=27352-27352
'
lo port found : 27352
incorrect range: 27352-27352, correcting
udp transport found, ports=(1,27352,27353)
setup expectation for rtcp
expect_related 172.26.83.134:0-0-10.x.x.x:27352-27353
NAT rtsp help_out
El problema con esto es que movistart tv no funciona así, sino que el vídeo lo envía desde otra ip distinta a la que usa para negociar el rtps. Como ejemplo te añado una captura del diálogo rtsp y el inicio del envío del vídeo, donde se puede ver que la negociación se hace contra la ip 172.26.83.134 y el envío de vídeo desde la 172.26.83.138:
Source Destination Protocol Length Info
10.x.x.x 172.26.83.134 RTSP 122 OPTIONS * RTSP/1.0
172.26.83.134 10.x.x.x RTSP 173 Reply: RTSP/1.0 200 OK
10.x.x.x 172.26.83.134 RTSP 233 DESCRIBE rtsp://172.26.83.134:554/rolling_buffer/1613/2014-08-28T19:45:00Z/2014-08-28T21:40:00Z RTSP/1.0
172.26.83.134 10.x.x.x RTSP/SDP 356 Reply: RTSP/1.0 200 OK
10.x.x.x 172.26.83.134 RTSP 298 SETUP rtsp://172.26.83.134:554/rolling_buffer/1613/2014-08-28T19:45:00Z/2014-08-28T21:40:00Z/3026458647976657478 RTSP/1.0
MP2T/H2221/UDP;unicast;client_port=27160-27161
172.26.83.134 10.x.x.x RTSP 281 Reply: RTSP/1.0 200 OK
10.x.x.x 172.26.83.134 RTSP 316 PLAY rtsp://172.26.83.134:554/rolling_buffer/1613/2014-08-28T19:45:00Z/2014-08-28T21:40:00Z/3026458647976657478 RTSP/1.0
172.26.83.134 10.x.x.x RTSP 153 Reply: RTSP/1.0 200 OK
172.26.83.138 10.x.x.x MPEG TS 1358 Program Map Table (PMT)
172.26.83.138 10.x.x.x MPEG TS 1358 Source port: 42278 Destination port: 27160
172.26.83.138 10.x.x.x MPEG TS 1358 Source port: 42278 Destination port: 27160
Una vez visto esto lo que hay que hacer es modificar lo que conntrack debe esperar quitando la ip de destino, y eso lo realizo con este parche:
--- nf_conntrack_rtsp.c.orig 2013-04-03 19:22:19.000000000 +0200
+++ nf_conntrack_rtsp.c 2014-08-27 10:59:41.519771956 +0200
@@ -346,7 +346,7 @@
nf_ct_expect_init(rtp_exp, NF_CT_EXPECT_CLASS_DEFAULT,
nf_ct_l3num(ct),
- &ct->tuplehash[!dir].tuple.src.u3,
+ NULL, //&ct->tuplehash[!dir].tuple.src.u3,
&ct->tuplehash[!dir].tuple.dst.u3,
IPPROTO_UDP, NULL, &be_loport);
@@ -364,7 +364,7 @@
nf_ct_expect_init(rtcp_exp, NF_CT_EXPECT_CLASS_DEFAULT,
nf_ct_l3num(ct),
- &ct->tuplehash[!dir].tuple.src.u3,
+ NULL, //&ct->tuplehash[!dir].tuple.src.u3,
&ct->tuplehash[!dir].tuple.dst.u3,
IPPROTO_UDP, NULL, &be_hiport);
una vez modificado compruebo que funciona correctamente.
...y tampoco de que pruebas a realizado (en cuanto al VOD y varios decos) ....
Las pruebas las puse, añadí el debug del módulo nat_rtsp donde se ve que funciona, es decir, que conntrack selecciona correctamente lo que se debe esperar y que nat lo recoge. Además añadi las entradas de conntrack y de nat donde se puede ver la parte externa e interna de la red.
Intentaré explicarme mejor.
Escenario: dos decos conectados, uno con ip 192.168.1.200 y otro con ip 192.168.1.201, dentro del rango típico del dhcp, selecciono en los decos una grabación distinta y pulso <ver> en los dos, las grabaciones se reproducen sin problema en los dos decos.
Detalles:
Información del primer deco al reproducir una grabación. Información de debug del módulo nat_rtsp donde se puede ver
1. análisis de lo que viene en el paquete SETUP de rtsp detectando los puertos indicados por el cliente:
found a setup message
tran='Transport: MP2T/H2221/UDP;unicast;client_port=27160-27160
'
lo port found : 27160
incorrect range: 27160-27160, correcting
udp transport found, ports=(1,27160,27161)
2. conntrack_rtsp indica lo que se debe esperar
setup expectation for rtcp
expect_related 0.0.0.0:0-0-10.x.x.x:27160-27161
3. nat_rtsp con lo que debe esperar
NAT rtsp help_out
hdr: len=9, CSeq: 3
hdr: len=25, User-Agent: MICA-IP-STB
hdr: len=59, Transport: MP2T/H2221/UDP;unicast;client_port=27160-27160
hdr: Transport
stunaddr=10.x.x.x (auto)
nat expect_related 0.0.0.0:0-0-10.x.x.x:27160-27161
rep: len=59, Transport: MP2T/H2221/UDP;unicast;client_port=27160-27161
hdr: len=14, x-mayNotify:
IP_CT_DIR_REPLY
IP_CT_DIR_REPLY
IP_CT_DIR_REPLY
IP_CT_DIR_REPLY
con esto el módulo nat_rtsp ya sabe que debe esperar paquetes en los puertos 27160 y 27161 y cualquier ip de la parte externa y ligarla a la conexión interna. Esto último se puede ver con estas órdenes:
# conntrack -L | grep 10.x.x.x | grep udp; netstat-nat -n | grep 192.168.1.20
...
udp 17 29 src=172.26.83.138 dst=10.x.x.x sport=42278 dport=27160 [UNREPLIED] src=192.168.1.201 dst=172.26.83.138 sport=27160 dport=42278 mark=0 use=1
...
udp 172.26.83.138:42278 192.168.1.201:27160 UNREPLIED
...
aquí podeis ver que desde el orgien 172.26.83.138:42278 llega al destino 192.168.1.201:27160 que en mi caso es el segundo deco.
Añado además la información general, con los dos decos, sin comentar para no entorpezer la lectura de los logs:
conntrackinfo = 2
IP_CT_DIR_REPLY
IP_CT_DIR_REPLY
conntrackinfo = 2
found a setup message
tran='Transport: MP2T/H2221/UDP;unicast;client_port=27160-27160
'
lo port found : 27160
incorrect range: 27160-27160, correcting
udp transport found, ports=(1,27160,27161)
setup expectation for rtcp
expect_related 0.0.0.0:0-0-10.159.34.38:27160-27161
NAT rtsp help_out
hdr: len=9, CSeq: 3
hdr: len=25, User-Agent: MICA-IP-STB
hdr: len=59, Transport: MP2T/H2221/UDP;unicast;client_port=27160-27160
hdr: Transport
stunaddr=10.159.34.38 (auto)
nat expect_related 0.0.0.0:0-0-10.159.34.38:27160-27161
rep: len=59, Transport: MP2T/H2221/UDP;unicast;client_port=27160-27161
hdr: len=14, x-mayNotify:
IP_CT_DIR_REPLY
teardown handled
conntrackinfo = 2
IP_CT_DIR_REPLY
IP_CT_DIR_REPLY
conntrackinfo = 2
found a setup message
tran='Transport: MP2T/H2221/UDP;unicast;client_port=27711-27711
'
lo port found : 27711
incorrect range: 27711-27711, correcting
udp transport found, ports=(1,27710,27711)
setup expectation for rtcp
expect_related 0.0.0.0:0-0-10.x.x.x:27710-27711
NAT rtsp help_out
hdr: len=9, CSeq: 3
hdr: len=25, User-Agent: MICA-IP-STB
hdr: len=59, Transport: MP2T/H2221/UDP;unicast;client_port=27711-27711
hdr: Transport
stunaddr=10.x.x.x (auto)
nat expect_related 0.0.0.0:0-0-10.x.x.x:27710-27711
multiple ports found, port 27711 ignored
rep: len=59, Transport: MP2T/H2221/UDP;unicast;client_port=27711-27711
hdr: len=14, x-mayNotify:
IP_CT_DIR_REPLY
teardown handled
# conntrack -L | grep 10.x.x.x | grep udp; netstat-nat -n | grep 192.168.1.20
...
udp 17 29 src=172.26.83.138 dst=10.x.x.x sport=42278 dport=27160 [UNREPLIED] src=192.168.1.201 dst=172.26.83.138 sport=27160 dport=42278 mark=0 use=1
udp 17 29 src=172.26.83.136 dst=10.x.x.x sport=41747 dport=27711 [UNREPLIED] src=192.168.1.200 dst=172.26.83.136 sport=27711 dport=41747 mark=0 use=1
...
udp 172.26.83.136:41747 192.168.1.200:27711 UNREPLIED
udp 172.26.83.138:42278 192.168.1.201:27160 UNREPLIED
...
Source Destination Protocol Length Info
10.x.x.x 172.26.83.134 RTSP 122 OPTIONS * RTSP/1.0
172.26.83.134 10.x.x.x RTSP 173 Reply: RTSP/1.0 200 OK
10.x.x.x 172.26.83.134 RTSP 233 DESCRIBE rtsp://172.26.83.134:554/rolling_buffer/1613/2014-08-28T19:45:00Z/2014-08-28T21:40:00Z RTSP/1.0
172.26.83.134 10.x.x.x RTSP/SDP 356 Reply: RTSP/1.0 200 OK
10.x.x.x 172.26.83.134 RTSP 298 SETUP rtsp://172.26.83.134:554/rolling_buffer/1613/2014-08-28T19:45:00Z/2014-08-28T21:40:00Z/3026458647976657478 RTSP/1.0
MP2T/H2221/UDP;unicast;client_port=27160-27161
172.26.83.134 10.x.x.x RTSP 281 Reply: RTSP/1.0 200 OK
10.x.x.x 172.26.83.134 RTSP 316 PLAY rtsp://172.26.83.134:554/rolling_buffer/1613/2014-08-28T19:45:00Z/2014-08-28T21:40:00Z/3026458647976657478 RTSP/1.0
172.26.83.134 10.x.x.x RTSP 153 Reply: RTSP/1.0 200 OK
172.26.83.138 10.x.x.x MPEG TS 1358 Program Map Table (PMT)
172.26.83.138 10.x.x.x MPEG TS 1358 Source port: 42278 Destination port: 27160
172.26.83.138 10.x.x.x MPEG TS 1358 Source port: 42278 Destination port: 27160
Source Destination Protocol Length Info
10.x.x.x 172.26.83.134 RTSP 122 OPTIONS * RTSP/1.0
172.26.83.134 10.x.x.x RTSP 173 Reply: RTSP/1.0 200 OK
10.x.x.x 172.26.83.134 RTSP 233 DESCRIBE rtsp://172.26.83.134:554/rolling_buffer/1611/2014-08-26T20:28:00Z/2014-08-26T22:38:00Z RTSP/1.0
172.26.83.134 10.x.x.x RTSP/SDP 356 Reply: RTSP/1.0 200 OK
10.x.x.x 172.26.83.134 RTSP 298 SETUP rtsp://172.26.83.134:554/rolling_buffer/1611/2014-08-26T20:28:00Z/2014-08-26T22:38:00Z/3026458665156526664 RTSP/1.0
MP2T/H2221/UDP;unicast;client_port=27711-27711
172.26.83.134 10.x.x.x RTSP 281 Reply: RTSP/1.0 200 OK
10.x.x.x 172.26.83.134 RTSP 316 PLAY rtsp://172.26.83.134:554/rolling_buffer/1611/2014-08-26T20:28:00Z/2014-08-26T22:38:00Z/3026458665156526664 RTSP/1.0
172.26.83.134 10.x.x.x RTSP 153 Reply: RTSP/1.0 200 OK
172.26.83.136 10.x.x.x MPEG TS 1358 Program Map Table (PMT)
172.26.83.136 10.x.x.x MPEG TS 1358 Source port: 41747 Destination port: 27711
172.26.83.136 10.x.x.x MPEG TS 1358 Source port: 41747 Destination port: 27711
Espero que esta vez quede lo suficientemente claro.
Esto es totalmente extrapolable a openwrt porque lo único que he modificado es conntrack_rtsp.c con el parche arriba indicado, Noltari y jfm ya compilaron con el parche anterior, sólo deben añadir la modificación que indico.
Por cierto, en esto yo veo un problema de selección de puertos por parte de los decos, en algún momento podrían seleccionar los mismos puertos.