Hello Greger and SER users. About this issue here are some test that i made. I added the lookup("location") as you recommend me : # ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (loose_route()) { if (has_totag() && (method=="INVITE" || method=="ACK")) { lookup("location"); if (isflagset(6) || client_nat_test("3") || search("^Route:.*;nat=yes")){ setflag(6); use_media_proxy(); }; }; route(1); break; }; Unfortunately, i'm still unable to have voice in both ways, but this modification seems to handle better the reINVITE message. And this is why. For the normal approach (i mean the initial onsip_pstn configuration) the second INVITE was not using the mediaproxym as Greger pointed. Now, as you can see in the debugs that i'm attaching, the second invite is using the mediaproxy, and therefore the "c" parameter in the SDP message is being correctly modified by SER. So, i don't understand why this time the call is failing. Could it be that mediaproxy is not capable to handle the reINVITEs?. For example in the debug from mediaproxy (i'm also attaching this one), i see a warning message like this : warning: Received packet from a third party: 200.0.0.7:16432. It seems like mediaproxy is not accepting "voice packets" from the second IP (the one indicated by the reINVITE). Why? Also, when the call is established this is the output from the "session" command : Caller Via Called Status Duration Codec Type Traffic ---------------------------------------------------------------------------- -------------------------------------- 200.0.0.6:17480 - 200.0.0.5:35094 - 200.0.0.4:46115 inactive 0'24" G729 Audio 0/16.75k/16.75k The call is established but between the first IP (Asterisk box) and the endpoint public IP. So, could this be a problem with mediaproxy?. I read the changelog from the version 1.3.1 and this is what i found : Changes from version 1.2.1 to 1.3.0 ----------------------------------- - Only create a new session if a request belongs to the first INVITE (no longer creates new sessions on re-INVITEs) could it be related?. I also have a general question about the reINVITE. As you can see the first INVITE has in his URI the domain name for the number : 5555848114(a)sipvoiss.desarrollo.redvoiss.net (Frame 1 from the debug). The reINVITE sent by Asterisk has the URI : 5555848114(a)200.0.0.4. Is this ok?, despite of this the reINVITE is correctly redirected to the endpoint. (You can check this in the frame 13 from the debug). Thanks again. Regards, Ricardo Martinez.-