Mark, I think I know what is going on here. By a lucky coincidence I was testing two OpenSIPS servers back to back in a very similar setup to yours. Today I converted one of them to use Topology Hiding, (partly to try to help you but it was something I wanted anyway). After converting it to use Topology Hiding, I got an error that looks very similar to yours and I think the solution to my problem is quite likely to be the solution for you too.
Background: See my article below about Contact header fixing and look for the section "When is it wrong to fix a Contact header?" https://kb.smartvox.co.uk/opensips/nat-contact-and-via-fixing-in-sip-part-3/ It specifically refers to the case of two SIP proxies back-to-back. What I found today is that Topology Hiding makes this problem much harder to spot because the fixed Contact header will never appear in a SIP trace such as you get in sngrep. Instead, what you see in the sip trace is the usual hashed id substituted by the TH module. It makes debugging very confusing. When the 200 OK arrives at your 2nd OpenSIPS Proxy from your 1st OpenSIPS Proxy, are you calling fix_nated_contact() in onreply_route? If you are, I'd wager that's your problem. You must not fix the Contact header because you are receiving the 200 OK from another proxy. You could design a fix based on checking the source address of the reply, but alternatively it may also be possible to insert a more generalised solution in onreply_route. On your 2nd OpenSIPS Proxy (the one using Topology Hiding), I think some code like this might work: if (is_present_hf("Record-Route")) xlog("Found a Record-Route header. Not going to fix Contact\n"); else { if (nat_uac_test(65)) { fix_nated_contact(); xlog("Fixing Contact\n); } else xlog("No need to fix Contact header. Its alright anyway\n"); } John Quick Smartvox Limited _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
