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@dimension-virtual.com Para: asterisk-es@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.
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@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@dimension-virtual.com Para: asterisk-es@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@in.ilimit.es
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
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@dimension-virtual.com Para: asterisk-es@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@in.ilimit.es
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Monday 05 November 2007 19:24:46 Jesus Rodriguez escribió:
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.
¿Te refieres a que dentro de una empresa a la que el proveedor de VoIP le ha puesto su propio router ADSL para VoIP y tal aplicarías RTPProxy en llamadas dentro de la LAN? es que eso supone mucho tráfico y un retardo apreciable, ¿no?
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.
¿Te refieres a que dentro de una empresa a la que el proveedor de VoIP le ha puesto su propio router ADSL para VoIP y tal aplicarías RTPProxy en llamadas dentro de la LAN? es que eso supone mucho tráfico y un retardo apreciable, ¿no?
Depende:
- Si montas un asterisk (o cualquier otro sistema de centralita IP) dentro de la red del cliente, puedes mantener el rtp local para las llamadas internas. Si tienes extensiones remotas puedes hacer proxy del rtp ya que éste siempre saldrá fuera.
- Si en la empresa montas un gateway analógico o rdsi/pri para sacar llamadas por IP, también puedes hacer proxy del rtp ya que seguirá saliendo al exterior.
- Incluso si ofreces algún tipo de servicio ip centrex en modelo ASP, por ejemplo, podrías permitirte hacer proxy del rtp de las llamadas locales si usas G729. Además, el tema del retardo no es problema ya que en una ADSL estás hablando de 60ms o 70ms round-trip lo que no afecta en absoluto a las llamadas.
Depende un poco del escenario en el que te muevas.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Lunes, 5 de Noviembre de 2007, Jesus Rodriguez escribió:
- Si montas un asterisk (o cualquier otro sistema de centralita IP)
dentro de la red del cliente, puedes mantener el rtp local para las llamadas internas. Si tienes extensiones remotas puedes hacer proxy del rtp ya que éste siempre saldrá fuera.
Bueno, pero estamos hablando de centrex que mola más ;)
- Si en la empresa montas un gateway analógico o rdsi/pri para sacar
llamadas por IP, también puedes hacer proxy del rtp ya que seguirá saliendo al exterior.
Hummm, pero yo por ejemplo en mi configuración aprovecho el modo Comedia en caso de que el gateway RDSI_2_SIP lo permita. Ejemplo:
- Un Asterisk (que soporta modo comedia y está configurado para ello con "nat=yes") en una oficina de algún supuesto cliente para recibir las entrantes vía RDSI y sacarlas por SIP.
- Asterisk tiene una IP pública y el resto de tfnos SIP de la oficina están tras NAT con otra IP pública distinta y sin STUN.
- Dicho Asterisk tiene un usuario asterisk@dominio_cliente que se autentica para llamar al OpenSer (centrex).
- El INVITE llega a OpenSer. Al mirar en la tabla subscriber carga también (load_credentials) un campo al que he llamado "caller_allows_comedia". Si tiene valor "y" entonces no se aplica RtpProxy.
- Finalmente OpenSer hará un INVITE a algún usuario de la oficina (que estará tras NAT sin STUN ni nada). El RTP funcionará ya que Asterisk esperará a ver de dónde llega el tráfico al puerto que ha indicado en el SDP del INVITE antes de enviarlo él.
- En conclusión, el audio es directo entre el usuario de la oficina y Asterisk, sin requerir RtpProxy.
- Y lo mejor... ¡¡¡funciona!!! XD
Ahora sólo queda esperar que los RDSI_2_SIP más sencillitos (Epigy, Lancom) soportan comedia... ¿lo hacen?
¿Ves algún fallo en mi planteamiento?
- Incluso si ofreces algún tipo de servicio ip centrex en modelo ASP,
por ejemplo, podrías permitirte hacer proxy del rtp de las llamadas locales si usas G729. Además, el tema del retardo no es problema ya que en una ADSL estás hablando de 60ms o 70ms round-trip lo que no afecta en absoluto a las llamadas.
Ups, "centrex en modelo ASP"... nunca te acostarás sin saber que no sabes algo XD
Depende un poco del escenario en el que te muevas.
¿No vale "todos"? XD
Saludos.
Hola Iñaki,
El Lunes, 5 de Noviembre de 2007, Jesus Rodriguez escribió:
- Si montas un asterisk (o cualquier otro sistema de centralita IP)
dentro de la red del cliente, puedes mantener el rtp local para las llamadas internas. Si tienes extensiones remotas puedes hacer proxy del rtp ya que éste siempre saldrá fuera.
Bueno, pero estamos hablando de centrex que mola más ;)
Vale :)
- Si en la empresa montas un gateway analógico o rdsi/pri para sacar
llamadas por IP, también puedes hacer proxy del rtp ya que seguirá saliendo al exterior.
Hummm, pero yo por ejemplo en mi configuración aprovecho el modo Comedia en caso de que el gateway RDSI_2_SIP lo permita. Ejemplo:
- Un Asterisk (que soporta modo comedia y está configurado para ello
con "nat=yes") en una oficina de algún supuesto cliente para recibir las entrantes vía RDSI y sacarlas por SIP.
- Asterisk tiene una IP pública y el resto de tfnos SIP de la
oficina están tras NAT con otra IP pública distinta y sin STUN.
- Dicho Asterisk tiene un usuario asterisk@dominio_cliente que se
autentica para llamar al OpenSer (centrex).
- El INVITE llega a OpenSer. Al mirar en la tabla subscriber carga
también (load_credentials) un campo al que he llamado "caller_allows_comedia". Si tiene valor "y" entonces no se aplica RtpProxy.
- Finalmente OpenSer hará un INVITE a algún usuario de la oficina
(que estará tras NAT sin STUN ni nada). El RTP funcionará ya que Asterisk esperará a ver de dónde llega el tráfico al puerto que ha indicado en el SDP del INVITE antes de enviarlo él.
- En conclusión, el audio es directo entre el usuario de la oficina y
Asterisk, sin requerir RtpProxy.
- Y lo mejor... ¡¡¡funciona!!! XD
Esto puede tener un problema. Por ejemplo, un gateway de un proveedor VoIP que también tiene comedia activado. En este caso, tanto el asterisk como el gateway pueden quedarse esperando a recibir el RTP del otro.
Ahora sólo queda esperar que los RDSI_2_SIP más sencillitos (Epigy, Lancom) soportan comedia... ¿lo hacen?
Hace mucho que no pruebo cacharros así, no lo se :-/
¿Ves algún fallo en mi planteamiento?
No, ninguno... sólo el tema de que ambos extremos puedan quedarse esperando a recibir RTP del otro.
- Incluso si ofreces algún tipo de servicio ip centrex en modelo ASP,
por ejemplo, podrías permitirte hacer proxy del rtp de las llamadas locales si usas G729. Además, el tema del retardo no es problema ya que en una ADSL estás hablando de 60ms o 70ms round-trip lo que no afecta en absoluto a las llamadas.
Ups, "centrex en modelo ASP"... nunca te acostarás sin saber que no sabes algo XD
Ya te daré alguna pista cuando nos veamos ;)
Depende un poco del escenario en el que te muevas.
¿No vale "todos"? XD
Mmmm.... en esto de SIP, eso de "todos" es bastante relativo :)
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El Tuesday 06 November 2007 18:38:02 Jesus Rodriguez escribió:
Esto puede tener un problema. Por ejemplo, un gateway de un proveedor VoIP que también tiene comedia activado. En este caso, tanto el asterisk como el gateway pueden quedarse esperando a recibir el RTP del otro.
La verdad es que lo pensé, y enfrente dos Asterisk ambos configurados frente al otro con "nat=yes" para que ambos apliquen modo comedia. El audio existía correctamente, no sé si tal vez a pesar de forzar el "nat=yes" Asterisk verifica IP's y hace un test de NAT. Ni idea, el caso es que funcionaba...
Aunque lo tengo que probar mejor.
Gracias.
El Martes, 6 de Noviembre de 2007, Iñaki Baz Castillo escribió:
El Tuesday 06 November 2007 18:38:02 Jesus Rodriguez escribió:
Esto puede tener un problema. Por ejemplo, un gateway de un proveedor VoIP que también tiene comedia activado. En este caso, tanto el asterisk como el gateway pueden quedarse esperando a recibir el RTP del otro.
La verdad es que lo pensé, y enfrente dos Asterisk ambos configurados frente al otro con "nat=yes" para que ambos apliquen modo comedia. El audio existía correctamente, no sé si tal vez a pesar de forzar el "nat=yes" Asterisk verifica IP's y hace un test de NAT. Ni idea, el caso es que funcionaba...
Aunque lo tengo que probar mejor.
Hoy lo he comprobado a las **muy malas**. Si Asterisk llama o es llamado por un peer configurado como "nat=yes" (aplicarle modo comedia) entonces espera a recibir el audio y pasa del SDP (lo normal de comedia, vamos). Pero si en un rato no recibe audio lo envía a la dirección indicada en el SDP.
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jesus Rodriguez -
Saúl Ibarra