El Wednesday 16 January 2008 08:30:59 Iñaki Baz Castillo escribió: 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 -- Raúl Alexis Betancor Santana Dimensión Virtual S.L.

El Wednesday 16 January 2008 09:36:48 Iñaki Baz Castillo escribió: 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 -- Raúl Alexis Betancor Santana Dimensión Virtual S.L.

On Mon, Jan 21, 2008 at 01:02:10PM +0100, Jesus Rodriguez wrote: Ups .. no había visto tu respuesta ... modparam("registrar", "use_path", 1) modparam("registrar", "path_mode", 2) modparam("registrar", "path_use_received", 0) modparam("registrar", "received_avp", "$avp(i:801)") 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 Tue, Jan 22, 2008 at 01:25:32PM +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. 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. La cuestión es lo que he dicho antes .. como averiguar que ese lookup("location"), va a volver con Path. 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 Tue, Jan 22, 2008 at 04:47:07PM +0100, Iñaki Baz Castillo wrote: 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. 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 Tue, Jan 22, 2008 at 05:34:31PM +0100, Iñaki Baz Castillo wrote: 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.