Re: [OpenSER-Users-ES] Y nos topamos con el NAT y t_replicate() ...

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