The traffic goes from the server making the call to the opensips proxy to the 
carrier. The /304 doesn't exist in the original invite from the server that 
makes the call. Do you want to see the packets from the calling server to the 
opensips box to the carrier? 

But most importantly, I'm still having trouble getting topology hiding to work. 
I made the change you suggested, but it appears that opensips is throwing away 
all responses it's receiving from the carrier, which means that opensips thinks 
the call never got set up and the invite was never accepted, and then it 
eventually responds 408 to the original calling server. In fact the invite WAS 
accepted, and the carrier sent back a 200 ok, but opensips threw it away and 
never acknowledged it. The outgoing invite from the opensips server looks 
correct -- opensips has modified the route and contact headers to its own IP, 
but obviously it doesn't know what to do with the responses that are coming 
back to it. 

The /304 issue is odd and could be causing us issues with certain carriers, but 
right now I'd like to get topology hiding working with even ONE carrier, and I 
can't do that yet. All I did was add the section you showed in your response -- 

if (loose_route() || match_dialog()) { 
if ($DLG_status==NULL) { 
xlog(" cannot match request to a dialog \n"); 
# something wrong - might want to drop such requests 
} 

... as a replacement to ... 

if (loose_route()) { 

And I added -- 

if (is_method("INVITE")) { 

topology_hiding(); 
} 

... right after -- 

# account only INVITEs 
if (is_method("INVITE")) { 

setflag(ACC_DO); # do accounting 
} 


All this is from the stock config file, with only my listen IPs and a couple 
aliases added, and obviously the dialog module loaded as well to allow for 
topology hiding. 

Thanks! 

-BJ 

----- Original Message -----

From: "Vlad Paiu" <vladp...@opensips.org> 
To: users@lists.opensips.org 
Sent: Wednesday, February 5, 2014 6:19:41 AM 
Subject: Re: [OpenSIPS-Users] topology hiding 

Hello, 

The sequential processing part is a little bit wrong - you should have 

if (loose_route() || match_dialog()) { 
if ($DLG_status==NULL) { 
xlog(" cannot match request to a dialog \n"); 
# something wrong - might want to drop such requests 
} 


Can you please also post a trace of the traffic flow when the Route 
header gets that bogus \304 header ? Trying to replicate this on my side 
and see what's wrong. 

Best Regards, 

Vlad Paiu 
OpenSIPS Developer 
http://www.opensips-solutions.com 

On 03.02.2014 20:36, BJ Quinn wrote: 
> Oh and the only manual manipulation of the route headers was an attempt to 
> get rid of that \304 in the header. 
> 
> I think the \304 thing may be a red herring for now. I still can't get the 
> topology hiding to work. Below is my config file. It's literally the default 
> config file with nothing changed but I've put in my IP address on the listen 
> line, added a couple of aliases, added UAC module to try to change the from 
> header (that works) and the dialog module and a couple of modifications to 
> the route to make topology hiding work (not working for me). 
> 
> Am I putting this in the wrong part of the route? 
> 
> Thx 
> 
> -BJ Quinn 
> 
> --- 
> debug=3 
> log_stderror=no 
> log_facility=LOG_LOCAL0 
> 
> fork=yes 
> children=4 
> 
> auto_aliases=no 
> 
> listen=udp:xx.xx.xx.9:5060 
> 
> disable_tcp=yes 
> 
> disable_tls=yes 
> 
> alias=xx.xx.xx.76:5060 
> alias=xx.xx.xx.77:5060 
> 
> mpath="/usr/lib64/opensips/modules" 
> 
> loadmodule "signaling.so" 
> 
> loadmodule "sl.so" 
> 
> loadmodule "tm.so" 
> modparam("tm", "fr_timer", 5) 
> modparam("tm", "fr_inv_timer", 30) 
> modparam("tm", "restart_fr_on_each_reply", 0) 
> modparam("tm", "onreply_avp_mode", 1) 
> 
> loadmodule "rr.so" 
> modparam("rr", "append_fromtag", 0) 
> 
> loadmodule "maxfwd.so" 
> 
> loadmodule "sipmsgops.so" 
> 
> loadmodule "mi_fifo.so" 
> modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") 
> modparam("mi_fifo", "fifo_mode", 0666) 
> 
> loadmodule "uri.so" 
> modparam("uri", "use_uri_table", 0) 
> 
> loadmodule "usrloc.so" 
> modparam("usrloc", "nat_bflag", "NAT") 
> modparam("usrloc", "db_mode", 0) 
> 
> loadmodule "registrar.so" 
> modparam("registrar", "tcp_persistent_flag", "TCP_PERSISTENT") 
> 
> loadmodule "acc.so" 
> modparam("acc", "early_media", 0) 
> modparam("acc", "report_cancels", 0) 
> modparam("acc", "detect_direction", 0) 
> modparam("acc", "failed_transaction_flag", "ACC_FAILED") 
> modparam("acc", "log_flag", "ACC_DO") 
> modparam("acc", "log_missed_flag", "ACC_MISSED") 
> 
> # added to rewrite from header 
> loadmodule "uac.so" 
> loadmodule "uac_auth.so" 
> modparam("uac","restore_mode","manual") 
> 
> #added for topology hiding 
> loadmodule "dialog.so" 
> 
> route{ 
> if (!mf_process_maxfwd_header("10")) { 
> sl_send_reply("483","Too Many Hops"); 
> exit; 
> } 
> 
> if (has_totag()) { 
> if (loose_route()) { 
> # added for topology hiding 
> if ($DLG_status==NULL && !match_dialog() ) { 
> xlog(" cannot match request to a dialog \n"); 
> } 
> #/added for topology hiding 
> 
> if (is_method("BYE")) { 
> setflag(ACC_DO); 
> setflag(ACC_FAILED); 
> } else if (is_method("INVITE")) { 
> record_route(); 
> } 
> 
> route(relay); 
> } else { 
> 
> if ( is_method("ACK") ) { 
> if ( t_check_trans() ) { 
> t_relay(); 
> exit; 
> } else { 
> exit; 
> } 
> } 
> sl_send_reply("404","Not here"); 
> } 
> exit; 
> } 
> 
> if (is_method("CANCEL")) 
> { 
> if (t_check_trans()) 
> t_relay(); 
> exit; 
> } 
> 
> t_check_trans(); 
> 
> if ( !(is_method("REGISTER") ) ) { 
> if (from_uri==myself) 
> { 
> } else { 
> if (!uri==myself) { 
> send_reply("403","Rely forbidden"); 
> exit; 
> } 
> } 
> } 
> 
> if (loose_route()) { 
> xlog("L_ERR", 
> "Attempt to route with preloaded Route's [$fu/$tu/$ru/$ci]"); 
> if (!is_method("ACK")) 
> sl_send_reply("403","Preload Route denied"); 
> exit; 
> } 
> 
> if (!is_method("REGISTER|MESSAGE")) 
> record_route(); 
> 
> if (is_method("INVITE")) { 
> 
> setflag(ACC_DO); # do accounting 
> } 
> 
> if (is_method("INVITE")) { 
> # rewrite from header 
> uac_replace_from("sip:$f...@xx.xx.xx.9"); 
> # trying to fix that /304 problem 
> #remove_hf("Route"); 
> #append_hf("Route: <sip:xx.xx.xx.9;lr>"); 
> create_dialog(); 
> topology_hiding(); 
> exit; 
> } 
> 
> if (!uri==myself) { 
> append_hf("P-hint: outbound\r\n"); 
> route(relay); 
> } 
> 
> if (is_method("PUBLISH|SUBSCRIBE")) 
> { 
> sl_send_reply("503", "Service Unavailable"); 
> exit; 
> } 
> 
> if (is_method("REGISTER")) 
> { 
> if ( 0 ) setflag(TCP_PERSISTENT); 
> if (!save("location")) 
> sl_reply_error(); 
> 
> exit; 
> } 
> 
> if ($rU==NULL) { 
> sl_send_reply("484","Address Incomplete"); 
> exit; 
> } 
> 
> if (!lookup("location","m")) { 
> t_newtran(); 
> t_reply("404", "Not Found"); 
> exit; 
> } 
> 
> setflag(ACC_MISSED); 
> route(relay); 
> } 
> 
> 
> route[relay] { 
> if (is_method("INVITE")) { 
> t_on_branch("per_branch_ops"); 
> t_on_reply("handle_nat"); 
> t_on_failure("missed_call"); 
> } 
> 
> if (!t_relay()) { 
> send_reply("500","Internal Error"); 
> }; 
> exit; 
> } 
> 
> 
> 
> 
> branch_route[per_branch_ops] { 
> xlog("new branch at $ru\n"); 
> } 
> 
> 
> onreply_route[handle_nat] { 
> 
> xlog("incoming reply\n"); 
> } 
> 
> 
> failure_route[missed_call] { 
> if (t_was_cancelled()) { 
> exit; 
> } 
> } 
> 
> 
> --- 
> 
> ----- Original Message ----- 
> From: "BJ Quinn" <bjqu...@seidal.com> 
> To: "OpenSIPS users mailling list" <users@lists.opensips.org> 
> Sent: Monday, February 3, 2014 10:27:22 AM 
> Subject: Re: [OpenSIPS-Users] topology hiding 
> 
> Thanks, I'll do that. What about the topology hiding? Am I doing that 
> incorrectly? 
> 
> -BJ 
> 
> ----- Original Message ----- 
> From: "Vlad Paiu" <vladp...@opensips.org> 
> To: users@lists.opensips.org 
> Sent: Monday, February 3, 2014 7:46:41 AM 
> Subject: Re: [OpenSIPS-Users] topology hiding 
> 
> Hello, 
> 
> No, you should not regex out those bogus characters, this seems like a 
> bug - could you please send us to SIP trace for your scenario so I can 
> understand how and when it's happening ? Are you currently doing any 
> manual manipulation on the Route headers in your script ? 
> 
> Also, if possible, Please open an issue on 
> https://github.com/OpenSIPS/opensips/issue for this so we can better 
> keep track of it. 
> 
> 
> Best Regards, 
> 
> Vlad Paiu 
> OpenSIPS Developer 
> http://www.opensips-solutions.com 
> 
> On 01.02.2014 02:26, BJ Quinn wrote: 
>> Hi, 
>> 
>> I'd like to use topology_hiding(), but I can't quite understand how to 
>> integrate it into the routing part of the configuration file. I have my 
>> opensips box on a public IP and some machines initiating calls through the 
>> opensips box that are also on public IPs, so no NAT going on or anything 
>> like that. However, a couple of the carriers we're trying to use don't like 
>> seeing the IP address of the machines initiating the call (in Route and 
>> Contact headers, etc.) and that's causing problems including some carriers 
>> don't think the call has set up properly (even though it goes through), 
>> which leads to missing BYEs. Anyway, seems like topology_hiding() is a great 
>> idea anyway, regardless of the fact that I've had a carrier specifically 
>> request it. 
>> 
>> I'm using 1.10. So I've started with the basic Residential scenario made 
>> from osipsconfig. I didn't check any of the options (like ENABLE_TCP, 
>> USE_ALIASES, etc.) and modified only my IP address and added a couple of 
>> aliases for the machines making the calls. I added the following outside of 
>> the routing logic to load the dialog module to make topology_hiding() 
>> available. 
>> 
>> loadmodule "dialog.so" 
>> 
>> Then, under "if(has_totag()) { if (loose_route()) {" I added -- 
>> 
>> if ($DLG_status==NULL && !match_dialog() ) { 
>> xlog(" cannot match request to a dialog \n"); 
>> } 
>> 
>> And outside of the "if(has_totag())" section I added -- 
>> 
>> if (is_method("INVITE")) { 
>> create_dialog(); 
>> topology_hiding(); 
>> } 
>> 
>> Without these added sections, things are fine on some carriers and with 
>> other carriers I have the problems described above which causes me to want 
>> to enable topology hiding. With these added sections, I get 408 timeouts 
>> since it appears that the opensips box is responding NOT HERE to the 
>> carrier's 200 OKs. 
>> 
>> Also, possibly unrelated, in either case I'm getting a weird "\304" added to 
>> my Route header. Should I just replace the Route header and regex that out? 
>> 
>> Route: <sip:xx.xx.xx.xx:\304;lr> 
>> 
>> Thanks! 
>> 
>> -BJ Quinn 
>> 
>> _______________________________________________ 
>> Users mailing list 
>> Users@lists.opensips.org 
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users 
> 
> _______________________________________________ 
> Users mailing list 
> Users@lists.opensips.org 
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users 
> 
> 
> _______________________________________________ 
> Users mailing list 
> Users@lists.opensips.org 
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users 
> 
> 
> _______________________________________________ 
> Users mailing list 
> Users@lists.opensips.org 
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users 


_______________________________________________ 
Users mailing list 
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users 

_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to