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

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(a)dimension-virtual.com> Para: asterisk-es(a)googlegroups.com El Tuesday 30 October 2007 13:58:14 Iñaki Baz Castillo escribió: 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. 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. 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(a)in.ilimit.es _______________________________________________ Users-es mailing list Users-es(a)lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es