Hi Andreas, it should depend also by how well the sip ua implements the RFC. In normal cases, I mark the natted requests with ";nat=yes" when record routing, and after I I will treat all the packets containing "nat=yes" like generated from behind nat and force rtp_proxy in their case.
Some sample config: # -------------------------------------- # NAT # -------------------------------------- if (nat_uac_test("7") || search("^Route:.*;nat=yes")) { force_rport(); if (is_method("REGISTER")) { fix_nated_register(); setbflag(6); } else { setflag(7); fix_nated_contact(); if (is_method("INVITE")){ fix_nated_sdp("1"); }; }; }; # -------------------------------------- # Record Routing # -------------------------------------- if (method=="INVITE" && isflagset(7)) { record_route_preset("$var(listen_ip);nat=yes"); } else if (method!="REGISTER") { record_route(); }; if (isbflagset(6) || isflagset(7)) { setbflag(10); force_rtp_proxy(); } Hope that helps. Cheers, DanB On 9/27/07, Andreas Sikkema <[EMAIL PROTECTED]> wrote: > Hi, > > > 2) I suspect that you have not treated properly reinvites in loose > > routing block. Some traces and configuration samples could permit us > > helping you more. > > What is the correct way of handling re-invites in a loose routing > block? So far I have disabled al reinvites because I also had > problems in this area... > > > -- > Andreas Sikkema > > _______________________________________________ > Users mailing list > Users@openser.org > http://openser.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users