[OpenSER-Users-ES] aplicar o no RtpProxy si llamante y llamado tras misma IP pública

Saúl Ibarra saghul at gmail.com
Tue Oct 30 19:18:05 CET 2007


Bufff vaya bug!! Yo tenía la misma idea que Iñaki y ahora se me ha ido
un poco al garete...

Realmente no tengo ni idea de que hacer a este respecto :(

El 30/10/07, Iñaki Baz Castillo <ibc at in.ilimit.es> escribió:
> Hola, estaba yo super contento con mi decisión de no aplicar RtpProxy si el
> llamante y llamado están tras la misma IP pública.
>
> Realmente es más eficiente que si ambos usasen STUN ya que STUN obligaria a
> que el RTP pasase por el router innecesariamente.
>
> Este tema lo he hablado en algún hilo de la lista de OpenSer versión inglesa y
> a todo el mundo le había parecido residual la posibilidad de encontrar casos
> en los que llamante y llamado apareciesen tras mismo NAT pero no tuviesen
> comunicación directa.
>
> Estaba yo feliz hasta que Raúl Alexis me ha lanzado este bombazo de correo que
> casi me deprime.
>
> Me gustaría escuchar más opiniones al respecto.
>
> Por otra parte, una solución a los problemas que me plantea Raúl Alexis sería
> que los clientes, en esas circunstancias tan malvadas, usasen STUN. Ya, ¿y si
> tienen NAT simétrico? bufff, bueno, pues es como si tienen ALG's malvados,
> nada pueden hacer.
>
>
> ¿Qué opináis?
>
>
>
>
> ----------  Mensaje reenviado  ----------
>
> Asunto: [Asterisk-ES] Re: Recomedación proveedores VoIP IAX2
> Fecha: Martes, 30 de Octubre de 2007
> De: Raúl Alexis Betancor Santana <rabs at dimension-virtual.com>
> Para: asterisk-es at googlegroups.com
>
>
> El Tuesday 30 October 2007 13:58:14 Iñaki Baz Castillo escribió:
> > Creo que las ventajas de asumir que están tras el mismo NAT (permitir
> > tráfico directo en la LAN) supera, con creces, los casos aislados y
> > particulares en los que dos usuarios en los que se detecta NAT salen con
> > misma IP pública y resulta que no son accesibles directamente entre ellos.
>
> IMHO cometes un error tamaño catedral asumiendo eso. Además no son "casos
> aislados y particulares", es el caso típico de un complejo de apartamentos
> con distintas zonas de cobertura WiFi o peor aún, es EL CASO en la 3G en
> España.
>
> > Si una empresa X se monta un pollo de red local con una IP pública y hace
> > separaciones en la LAN con VLAN's, distintos rangos de red bloqueados por
> > firewall o no rutables entre sí, etc... es su problema.
>
> No confundas cosas, yo no he hablado de como tenga la empresa configurado su
> routing interno.
>
> Te voy a poner un ejemplo (valdría cualquier otro) sobre como tu suposición
> del NAT tras la misma IP falla estrepitosamente si lo  intentas resolver de
> la forma que tu planteas:
>
> Usuario A en habitación x del hotel J, IP asignada por el hotel: 172.26.1.A
> Usuario B en habitación y del hotel J, IP asignada por el hotel: 172.26.1.B
> Central SIP oficina: IP pública (o mapeada, que pal caso es lo mismo),
> AAA.BBB.CCC.DDD
> Red LAN oficina: 172.26.0.0/23
>
> Ahora el escenario ...
> Usuario A llega a su habitación, enciende el portatil, se engancha a la red
> VPN de la oficina para trabajar en la intranet (IP asignada intranet:
> 172.26.2.A) y va a su bola currando
>
> Usuario B llega a su habitación, enciente el portatil, se pone a navegar por
> internet y se le ocurre llamar a A, porque lo ve por el precense del
> sotfphone
>
> ¿Resultado con tu planteamiento de "ignorar el NAT existente"? que A recibe la
> señalización pero jamás recibirá el RTP y te dejo como ejercicio averiguar
> porqué.
>
> Y te adelanto que este escenario es más que normal, a la par de muchos otros
> donde no puedes ignorar el tema del NAT a la lijera.
>
> > > La única solución que SIEMPRE funciona cuando hay un NAT de por medio en
> > > SIP es hacer de proxy del RTP, no hay más tutia.
> >
> > Vale, imagina una centralita en internet con un proxy RTP y una
> > oficina/delegación muy remota con usuarios SIP. ¿Obligarías a que una
> > llamada entre ellos origine tráfico hasta el proxy RTP de ida y vuelta?
> > Recuerda que STUN no funciona tras NAT simétrico (por desgracia abundante
> > hoy en día) y que aún funcionando, dos usuarios tras el mismo NAT
> > configurados con STUN se enviarían el tráfico de audio a través de su
> > router (y no directamente).
>
> A ver, a ver .. no confundas ... si es una oficina remota, la solución MAS
> simple es que el router de salida de esa oficina soporte VPN, enchangas un
> tunel a la central y metes la señalización por el tunel, de esa forma la red
> es "plana" y no te preocupas del NAT. En caso de no soportar VPN tienes 2
> opciones:
>
> A) la que tu propones, que ya te digo tiene muchas lagunas y IMHO genera más
> dolores de cabeza de los que resuelve.
>
> B) abrir puertos en el router y fijar en los dispositivos SIP los puertos para
> que no sean dinámicos.
>
>
> --
> Saludos.
>
> Raúl Alexis Betancor Santana
> Dimensión Virtual S.L.
> --------------------------------------------------------------------------------------------------------------
>
>
>
>
> --
> Iñaki Baz Castillo
> ibc at in.ilimit.es
>
> _______________________________________________
> Users-es mailing list
> Users-es at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
>


-- 
Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."
----------------------------------------------------------------
http://www.saghul.net/




More information about the Users-es mailing list