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

Mon Nov 5 19:24:46 CET 2007

Hola,

> 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?

¿Por qué hay tanto miedo a hacer relay del rtp?. A nivel de ancho de  
banda tampoco es tanto teniendo en cuenta los volúmenes actuales de  
paquetes que se mueven... el único problema que podría haber es si tu  
proxy está en Barcelona y tu usuario en Cancún...

Por lo demás, yo optaría por hacer relay del RTP.

Saludos
JesusR.

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

Saludos
JesusR.

------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr at voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------