Re: [OpenSIPS-Users] topology hiding

2014-02-10 Thread BJ Quinn
Ok so it looks like 1.10 may have been the problem. Things seem to be working 
with the same config on 1.9. I'm still getting that funny /304 in the route 
header, but now I've discovered that it's the software initiating the call that 
is adding that /304 (it only added it when it's in proxy mode, so I didn't see 
it in the other invites generated by this software from before I tried to put 
it behind the opensips proxy). 

So now here's my question. I'd like to simply strip out the /304 from the route 
header that comes from the software initiating the call (I don't think I can 
change that software). But that would require modifying the route header 
manually AND with topology hiding. Is that allowed? Do I do one or the other 
first? 

Thanks! 

-BJ 

- Original Message -

From: BJ Quinn bjqu...@seidal.com 
To: OpenSIPS users mailling list users@lists.opensips.org 
Sent: Saturday, February 8, 2014 12:33:38 PM 
Subject: Re: [OpenSIPS-Users] topology hiding 

According to http://lists.opensips.org/pipermail/users/2013-October/026992.html 
it appears that there's a bug in 1.10 for dialog based topology hiding? Maybe 
that's my problem? 

I'm using the RHEL RPMs for 1.10 stable. Maybe the issue mentioned in that post 
isn't my issue, or maybe the fix has been applied to the 1.10 RPMs? Or maybe I 
should downgrade to 1.9 and try again? 

-BJ 

- Original Message -

From: BJ Quinn bjqu...@seidal.com 
To: OpenSIPS users mailling list users@lists.opensips.org 
Sent: Friday, February 7, 2014 4:37:45 PM 
Subject: Re: [OpenSIPS-Users] topology hiding 

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 


___ 
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


Re: [OpenSIPS-Users] topology hiding

2014-02-08 Thread BJ Quinn
According to http://lists.opensips.org/pipermail/users/2013-October/026992.html 
it appears that there's a bug in 1.10 for dialog based topology hiding? Maybe 
that's my problem? 

I'm using the RHEL RPMs for 1.10 stable. Maybe the issue mentioned in that post 
isn't my issue, or maybe the fix has been applied to the 1.10 RPMs? Or maybe I 
should downgrade to 1.9 and try again? 

-BJ 

- Original Message -

From: BJ Quinn bjqu...@seidal.com 
To: OpenSIPS users mailling list users@lists.opensips.org 
Sent: Friday, February 7, 2014 4:37:45 PM 
Subject: Re: [OpenSIPS-Users] topology hiding 

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 

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


Re: [OpenSIPS-Users] topology hiding

2014-02-07 Thread BJ Quinn
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

Re: [OpenSIPS-Users] topology hiding

2014-02-03 Thread BJ Quinn
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


Re: [OpenSIPS-Users] topology hiding

2014-02-03 Thread BJ Quinn
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

[OpenSIPS-Users] topology hiding

2014-01-31 Thread BJ Quinn
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