Bien .. ahora que tengo el t_replicate funcionando ok, gracias chicos por las indicaciones ... viene el problema de un INVITE que entra por el openser2 y que vá con destino a un usuario TRAS UN NAT, que se registró en el openser1.
Antes de usar t_replicate(), yo tenía montada una pequeña "ñapa", consistente en que no replicaba los REGISTER, sino que cuando al hacer un lookup() no encontraba un usuario, añadía una cabecera SBC-Internal-Jump y hacía un rewritehost hacia el otro openser, en este ejecutaba el guión con normalidad y la llamada funcionaba (porculeando un poco con mediaproxy .. pero bueno).
Ahora que tengo el t_replicate() andando bien .. ¿cual es la solución adecuada para que el INVITE llegue al UAC que está detrás de un NAT y que se registró mediante el openser1? ¿usar el módulo path?
Saludos. -- Raúl Alexis Betancor Santana Dimensión Virtual S.L.
El 16/01/08, Raúl Alexis Betancor Santana rabs@dimension-virtual.com escribió:
Bien .. ahora que tengo el t_replicate funcionando ok, gracias chicos por las indicaciones ... viene el problema de un INVITE que entra por el openser2 y que vá con destino a un usuario TRAS UN NAT, que se registró en el openser1.
Antes de usar t_replicate(), yo tenía montada una pequeña "ñapa", consistente en que no replicaba los REGISTER, sino que cuando al hacer un lookup() no encontraba un usuario, añadía una cabecera SBC-Internal-Jump y hacía un rewritehost hacia el otro openser, en este ejecutaba el guión con normalidad y la llamada funcionaba (porculeando un poco con mediaproxy .. pero bueno).
Ahora que tengo el t_replicate() andando bien .. ¿cual es la solución adecuada para que el INVITE llegue al UAC que está detrás de un NAT y que se registró mediante el openser1? ¿usar el módulo path?
Yo diría que para esas cosas es precisamente el módulo Path.
El Wednesday 16 January 2008 08:30:59 Iñaki Baz Castillo escribió:
Yo diría que para esas cosas es precisamente el módulo Path.
Sí, estoy trasteando con él, creo que la solución viene por usar add_path_received(), pero tengo que mirarlo y probarlo con más detalle.
Saludos
On Wednesday 16 January 2008 09:42:34 Raúl Alexis Betancor Santana wrote:
El Wednesday 16 January 2008 08:30:59 Iñaki Baz Castillo escribió:
Yo diría que para esas cosas es precisamente el módulo Path.
Sí, estoy trasteando con él, creo que la solución viene por usar add_path_received(), pero tengo que mirarlo y probarlo con más detalle.
Supongo que lo tienes por ahí, pero por si acaso el RFC que habla del "Path" es éste: http://www.faqs.org/rfcs/rfc3327.html
El Wednesday 16 January 2008 09:36:48 Iñaki Baz Castillo escribió:
On Wednesday 16 January 2008 09:42:34 Raúl Alexis Betancor Santana wrote:
El Wednesday 16 January 2008 08:30:59 Iñaki Baz Castillo escribió:
Yo diría que para esas cosas es precisamente el módulo Path.
Sí, estoy trasteando con él, creo que la solución viene por usar add_path_received(), pero tengo que mirarlo y probarlo con más detalle.
Supongo que lo tienes por ahí, pero por si acaso el RFC que habla del "Path" es éste: http://www.faqs.org/rfcs/rfc3327.html
Bien, después de 2 días peleandome con esto .. no doy con la solución, a ver si me echáis una mano.
Me he empapado el RFC del path y la docu de openser sobre el módulo en cuestión, he cambiado el guión para que en los REQUEST que me lleguen al proxy1 desde proxy2, si detecta NAT, use add_path_received() y sino detecta NAT, pues usa add_path(). Esta parte está funcionando bien, porque veo con el "ul show" que el UA se ha registrado contra el P2 correctamente y que este añade el path y hace un t_replicate al P1, al P1 llega el paquete, lo coge por trusted y hace el save("location", 0x03) correspondiente. Hasta aquí todo OK.
El problema lo tengo en cuanto llega un INVITE para el UA que está registrado en P2, pero el INVITE llega por el P1. Entra en el proceso normal y corriente, llega al lookup("location") y ya se monta el pollo, porque me cambia el R-URI de UA1@dominio, por los datos del Contact que están en la base de datos de location. Y la cosa se lía, porque de la consulta a lookup también se dá cuenta P1 que hay un Path, y lo que hace es enviarle el INVITE a P2 pero con el R-URI puesto al valor del Contact, lo que provoca que P2 acepte el INVITE porque viene de un trusted, pero luego cante un "Relay Denied" porque el $rD del $rU no es local.
¿Alguna sugerencia?, ¿Como puedo hacer que no me cambie el RURI por el del contact en el nodo que no tenia el registro del UA y simplementa haga caso del Path?, osea quiero que el mensaje INVITE que ha entrado por el P1 llegue al P2 sin modificar en el caso de que el UA está registrado en el P1 y no en el P2
Hola,
El Wednesday 16 January 2008 09:36:48 Iñaki Baz Castillo escribió:
On Wednesday 16 January 2008 09:42:34 Raúl Alexis Betancor Santana wrote:
El Wednesday 16 January 2008 08:30:59 Iñaki Baz Castillo escribió:
Yo diría que para esas cosas es precisamente el módulo Path.
Sí, estoy trasteando con él, creo que la solución viene por usar add_path_received(), pero tengo que mirarlo y probarlo con más detalle.
Supongo que lo tienes por ahí, pero por si acaso el RFC que habla del "Path" es éste: http://www.faqs.org/rfcs/rfc3327.html
Bien, después de 2 días peleandome con esto .. no doy con la solución, a ver si me echáis una mano.
Me he empapado el RFC del path y la docu de openser sobre el módulo en cuestión, he cambiado el guión para que en los REQUEST que me lleguen al proxy1 desde proxy2, si detecta NAT, use add_path_received() y sino detecta NAT, pues usa add_path(). Esta parte está funcionando bien, porque veo con el "ul show" que el UA se ha registrado contra el P2 correctamente y que este añade el path y hace un t_replicate al P1, al P1 llega el paquete, lo coge por trusted y hace el save("location", 0x03) correspondiente. Hasta aquí todo OK.
El problema lo tengo en cuanto llega un INVITE para el UA que está registrado en P2, pero el INVITE llega por el P1. Entra en el proceso normal y corriente, llega al lookup("location") y ya se monta el pollo, porque me cambia el R-URI de UA1@dominio, por los datos del Contact que están en la base de datos de location. Y la cosa se lía, porque de la consulta a lookup también se dá cuenta P1 que hay un Path, y lo que hace es enviarle el INVITE a P2 pero con el R-URI puesto al valor del Contact, lo que provoca que P2 acepte el INVITE porque viene de un trusted, pero luego cante un "Relay Denied" porque el $rD del $rU no es local.
¿Alguna sugerencia?, ¿Como puedo hacer que no me cambie el RURI por el del contact en el nodo que no tenia el registro del UA y simplementa haga caso del Path?, osea quiero que el mensaje INVITE que ha entrado por el P1 llegue al P2 sin modificar en el caso de que el UA está registrado en el P1 y no en el P2
¿Tienes puesto esto?:
modparam("registrar", "use_path", 1)
¿Que modparams tienes para el módulo path?.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
On Mon, Jan 21, 2008 at 01:02:10PM +0100, Jesus Rodriguez wrote:
Ups .. no había visto tu respuesta ...
¿Tienes puesto esto?:
modparam("registrar", "use_path", 1)
modparam("registrar", "use_path", 1) modparam("registrar", "path_mode", 2) modparam("registrar", "path_use_received", 0) modparam("registrar", "received_avp", "$avp(i:801)")
¿Que modparams tienes para el módulo path?.
modparam("path", "use_received", 1)
El único que admite.
La cosa es que el INVITE que entra por el P1 y vá para un UA que está registrado en el P2 llega, pero el P1 al hacer el lookup("location") cambia el RURI por los datos del contact y cuando eso llega al P2, este lo rechaza porque la comprobación de is_local_domain($rd) falla (el $rd contiene ahora los datos del contact).
He probado guardando el $ru antes de hacer el location y volviendolo a setear antes de hacer el t_relay al P2, esto hace que la señalización funcione perfecta .. pero los UA's que intervienen en la prueba solo reciben su própio RTP, como si en vez de llamar de UA1 a UA2 estubiesen llamando a un EchoTest.
Cualquier pista o enlace a documentación será agradecido .. :-)
Saludos -- Raúl Alexis Betancor Santana Dimensión Virtual S.L.
On Tuesday 22 January 2008 10:25:22 Raúl Alexis Betancor Santana wrote:
La cosa es que el INVITE que entra por el P1 y vá para un UA que está registrado en el P2 llega, pero el P1 al hacer el lookup("location") cambia el RURI por los datos del contact y cuando eso llega al P2, este lo rechaza porque la comprobación de is_local_domain($rd) falla (el $rd contiene ahora los datos del contact).
Se me ocurre de idea feliz que podrías hacer un "append_branch()" para manejar dos instancias del INVITE, hacer el "lookup" sobre una de ellas y en caso de que tenga PATH y todo eso redirigir el INVITE al otro nodo.
Pero esta última redirección debería hacerse en plan: t_relay("nodo2",flags) Es decir, sin alterar el RURI del INVITE original para que no tengas problemas con los dominios y tal.
He probado guardando el $ru antes de hacer el location y volviendolo a setear antes de hacer el t_relay al P2, esto hace que la señalización funcione perfecta .. pero los UA's que intervienen en la prueba solo reciben su própio RTP, como si en vez de llamar de UA1 a UA2 estubiesen llamando a un EchoTest.
Esto ya se me escapa por completo, no entiendo qué es eso de que un UAC sólo se escuche a sí mismo, ¿cómo es posible? ¿has monitorizado entre qué entidades se está enviando RTP?
Saludos.
On Tue, Jan 22, 2008 at 01:25:32PM +0100, Iñaki Baz Castillo wrote:
On Tuesday 22 January 2008 10:25:22 Raúl Alexis Betancor Santana wrote:
La cosa es que el INVITE que entra por el P1 y vá para un UA que está registrado en el P2 llega, pero el P1 al hacer el lookup("location") cambia el RURI por los datos del contact y cuando eso llega al P2, este lo rechaza porque la comprobación de is_local_domain($rd) falla (el $rd contiene ahora los datos del contact).
Se me ocurre de idea feliz que podrías hacer un "append_branch()" para manejar dos instancias del INVITE, hacer el "lookup" sobre una de ellas y en caso de que tenga PATH y todo eso redirigir el INVITE al otro nodo.
La pregunta mágica es .. ¿Y como averiguar que tienen path? .. porque he intentado con un $hdr(Path) y nanai, con un is_present_hf("Path") y tampoco. Estoy revisando el código de lookup() a ver donde demonios tiene el tio en cuenta el Path, porque el módulo path.so solo registra un callback hacia el módulo rr.
Pero esta última redirección debería hacerse en plan: t_relay("nodo2",flags) Es decir, sin alterar el RURI del INVITE original para que no tengas problemas con los dominios y tal.
La cuestión es lo que he dicho antes .. como averiguar que ese lookup("location"), va a volver con Path.
He probado guardando el $ru antes de hacer el location y volviendolo a setear antes de hacer el t_relay al P2, esto hace que la señalización funcione perfecta .. pero los UA's que intervienen en la prueba solo reciben su própio RTP, como si en vez de llamar de UA1 a UA2 estubiesen llamando a un EchoTest.
Esto ya se me escapa por completo, no entiendo qué es eso de que un UAC sólo se escuche a sí mismo, ¿cómo es posible? ¿has monitorizado entre qué entidades se está enviando RTP?
Si, ambos UAC están registrados en proxies diferentes y ambos negocian con mediaproxy para salvar el NAT, pero por algún misterio de la vida que aun tengo por comprobar ... lo que hacen es montar un bucle con el RTP del UAC1 y el UAC2, osea .. a UAC1 le envía su propio RTP de vuelta y a UAC2 lo mismo.
De esta salgo escaldao de NAT ... XP
Saludos -- Raúl Alexis Betancor Santana Dimensión Virtual S.L.
On Tuesday 22 January 2008 16:32:14 Raúl Alexis Betancor Santana wrote:
On Tue, Jan 22, 2008 at 01:25:32PM +0100, Iñaki Baz Castillo wrote:
On Tuesday 22 January 2008 10:25:22 Raúl Alexis Betancor Santana wrote:
La cosa es que el INVITE que entra por el P1 y vá para un UA que está registrado en el P2 llega, pero el P1 al hacer el lookup("location") cambia el RURI por los datos del contact y cuando eso llega al P2, este lo rechaza porque la comprobación de is_local_domain($rd) falla (el $rd contiene ahora los datos del contact).
Se me ocurre de idea feliz que podrías hacer un "append_branch()" para manejar dos instancias del INVITE, hacer el "lookup" sobre una de ellas y en caso de que tenga PATH y todo eso redirigir el INVITE al otro nodo.
La pregunta mágica es .. ¿Y como averiguar que tienen path? .. porque he intentado con un $hdr(Path) y nanai, con un is_present_hf("Path") y tampoco.
Eso nunca va a funcionar ya que la adicción o supresión de cabeceras se hacen efectivas al abandonar el proxy, nunca durante el proceso del mensaje.
Estoy revisando el código de lookup() a ver donde demonios tiene el tio en cuenta el Path, porque el módulo path.so solo registra un callback hacia el módulo rr.
¿Has leído esto? Módulo "registrar": 1.1.1. PATH support http://www.openser.org/docs/modules/1.3.x/registrar.html#AEN41
On Tue, Jan 22, 2008 at 04:47:07PM +0100, Iñaki Baz Castillo wrote:
La pregunta mágica es .. ¿Y como averiguar que tienen path? .. porque he intentado con un $hdr(Path) y nanai, con un is_present_hf("Path") y tampoco.
Eso nunca va a funcionar ya que la adicción o supresión de cabeceras se hacen efectivas al abandonar el proxy, nunca durante el proceso del mensaje.
Ya, ya se que se produce el cambio cuando sale, pero creo que no me has entendido ... pongo un ejemplo de traza: Solo pongo el register de un UAC para abreviar.
UAC1 P1 P2 UAC2 REGISTER -> <- 401 REGISTER -> <- 200 add_path t_replicate -> save("location",0x03) <- INVITE UAC1 401 -> <- INVITE UAC1 100 -> lookup() <- t_relay() allow_trusted() sl_reply("503")-> -> 503
El 503 se produce porque cuando el P2 hace el lookup(), encuentra al UAC1 en su base de datos (gracias a replicate), pero cambia el RURI ANTES de darse cuenta de que el UAC1 tiene en su AOR un Path como una casa y cuando el INVITE llega a P1, el RURI ya no es válido. Si cambio el RURI ($ru) después del lookup, la señalización continua correcta, pero se me monta el bucle del RTP.
Estoy revisando el código de lookup() a ver donde demonios tiene el tio en cuenta el Path, porque el módulo path.so solo registra un callback hacia el módulo rr.
¿Has leído esto? Módulo "registrar": 1.1.1. PATH support http://www.openser.org/docs/modules/1.3.x/registrar.html#AEN41
Si y dice clarito ...
" A call to lookup(...) always uses the path header if found, and inserts it as Route HF either in front of the first Route HF, or after the last Via HF if no Route is present. It also sets the destination uri to the first Path uri, thus overwriting the received-uri, because NAT has to be handled at the outbound-proxy of the UAC (the first hop after client's NAT)."
En cristiano, que encontrará el Path y modificará el orden de los Route acorde, pero también dice que modificará el RURI.
Umm ..., se me ocurre que si trato el INVITE que entra el P1 desde P2, como si fuese desde un GW PSTN (que tienen otro tratamiento diferente), puede que cuele ... voy a probar.
Saludos. -- Raúl Alexis Betancor Santana Dimensión Virtual S.L.
On Tuesday 22 January 2008 17:16:23 Raúl Alexis Betancor Santana wrote:
En cristiano, que encontrará el Path y modificará el orden de los Route acorde, pero también dice que modificará el RURI.
Umm ..., se me ocurre que si trato el INVITE que entra el P1 desde P2, como si fuese desde un GW PSTN (que tienen otro tratamiento diferente), puede que cuele ... voy a probar.
Sí, es lo que te iba a decir, no hagas una comprobación de dominio ni modificación de RURI cuando te venga un INVITE (o lo que sea) desde P2. Que P1 se limite a hacer un triste "t_relay()" a ver si cuela.
On Tue, Jan 22, 2008 at 05:34:31PM +0100, Iñaki Baz Castillo wrote:
On Tuesday 22 January 2008 17:16:23 Raúl Alexis Betancor Santana wrote:
En cristiano, que encontrará el Path y modificará el orden de los Route acorde, pero también dice que modificará el RURI.
Umm ..., se me ocurre que si trato el INVITE que entra el P1 desde P2, como si fuese desde un GW PSTN (que tienen otro tratamiento diferente), puede que cuele ... voy a probar.
Sí, es lo que te iba a decir, no hagas una comprobación de dominio ni modificación de RURI cuando te venga un INVITE (o lo que sea) desde P2. Que P1 se limite a hacer un triste "t_relay()" a ver si cuela.
Pues la solución ha sido esa, tratar los mensajes INVITE que vienen desde el Proxy "contrario" como si fuesen gateways PSTN, osea, sin validar nada, ni dominio ni ná .. limitarse a "buscar" al usuario y hacer un relay.
Buff .. y casi una semana peleandome con esto.
Saludos -- Raúl Alexis Betancor Santana Dimensión Virtual S.L.
sr-users-es@lists.kamailio.org
-
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Jesus Rodriguez -
Raúl Alexis Betancor Santana