Re: [OpenSIPS-Users] topology hiding
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
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
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
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
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
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
