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

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.