Yes, that is what you suggested before. My comments below were stating
that that does not work. Specifically, “the match_dialog function must
do loose routing on its own” because even when I only call
match_dialog() from the script, I can still see the loose_route
processing being triggered in the logs.
Ben Newlin
*From: *Bogdan-Andrei Iancu <[email protected]>
*Date: *Tuesday, October 4, 2016 at 5:28 AM
*To: *"Newlin, Ben" <[email protected]>, OpenSIPS users mailling
list <[email protected]>
*Subject: *Re: [OpenSIPS-Users] Record-Route and Dialog topology_hiding()
Ben,
In 1.11, if you do TH, you should use match_dialog() function and not
loose_route() at all.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 30.09.2016 16:21, Newlin, Ben wrote:
No problem.
Thanks, but I am not using 2.2 and not using the topology_hiding
module. I am using the Dialog module with the topology_hiding
function in 1.11.
Ben Newlin
*From: *Bogdan-Andrei Iancu <[email protected]>
<mailto:[email protected]>
*Date: *Friday, September 30, 2016 at 4:39 AM
*To: *"Newlin, Ben" <[email protected]>
<mailto:[email protected]>, OpenSIPS users mailling list
<[email protected]> <mailto:[email protected]>
*Subject: *Re: [OpenSIPS-Users] Record-Route and Dialog
topology_hiding()
Hi Ben,
Sorry, I missed your email :(.
But you should not do match_dialog, but topology_hiding_match()
http://www.opensips.org/html/docs/modules/2.2.x/topology_hiding.html#id293644
This is not require any loose_route() or so.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 05.08.2016 17:22, Newlin, Ben wrote:
Bogdan,
Just as an update, this does not work. The match_dialog
function must do loose routing on its own and even though I
call remove_hf(“Route”) before match_dialog(), it still
processes the Route header on the incoming message. So
match_dialog returns true, but the TH refactoring is not
applied and $du is set to the IP from the incoming message’s
Route header, which is my server.
Ben Newlin
*From: *Bogdan-Andrei Iancu <[email protected]>
<mailto:[email protected]>
*Date: *Monday, August 1, 2016 at 7:13 AM
*To: *"Newlin, Ben" <[email protected]>
<mailto:[email protected]>, OpenSIPS users mailling list
<[email protected]> <mailto:[email protected]>
*Subject: *Re: [OpenSIPS-Users] Record-Route and Dialog
topology_hiding()
Hi Ben,
I see your problem here. So, let's explore this:
1) for sending the call to carrier, on OpenSIPS, you do TH
(with advertise) resulting in a Contact with the public IP of
the SBC.
2) also, manually add a RR header with the private IP of OpenSIPS.
3) send call to SBC, which will add its own RR stuff.
Now, on the sequential request from Carrier, the RURI will
contain the Contact of OpenSIPS (the pub IP of SBC), some
Route hdrs due the SBC and the Route we added on OpenSIPS.
- when request gets to SBC, the SBC will do loose route,
consume its Route headers, and it will use the next available
Route which points to the priv IP of OpenSIPS (and it will not
use the public IP in RURI for routing)
- requests gets to OpenSIPS, simply remove_hf() and Route
headers (do not do any loose_route() as it is useless) and hit
th_matching -> this will refactor the request (RURI, Contact,
Route) for the leg on the other side -> this should be fine.
For the other direction (still sequential), you do th_matching
on OpenSIPS and nothing more. This will send a request holding
the Routes due the SBC, a Contact with the public IP and and
RURI pointing probably to the carrier.
Shortly you do standard TH, but on outbound scenario, add a
fake RR header to trick the SBC to route the sequential to
your OpenSIPS.
Does it make sense ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 29.07.2016 18:05, Newlin, Ben wrote:
Here is the scenario:
My servers are only listening on a private IP address.
There is a public address on our SBC. I have a carrier
that requires that the Contact IP address matches the
public address we provided to them. So when I do TH on my
server I have to also do set_advertised_address to
advertise the public address in the Contact header.
Sequential requests use the Contact as the Request URI and
the SBC is doing RR so all requests will come back through
it. When the SBC receives a sequential request it strips
its Route headers and forwards to the Request URI
(previous Contact URI). But that URI now points back to
the SBC, so it cannot deliver the request. If my server
could Record-Route the initial request with its private
address, the SBC would be able to route the request back
to it.
Here is a trace of my scenario:
http://pastebin.com/x927mFtq. I created it with SIPp so
some endpoints are on the same IPs but with different
ports. The public IP is 192.168.99.100, with port 7060
representing the PSTN carrier and port 5060 the SBC. The
private IP is 10.0.2.15, with port 5060 being the SBC
again and port 6060 being my server. You can see that the
ACK cannot be delivered correctly to my server with this
configuration.
The problem here stems from the fact that Topology Hiding
should really be done at the edge of the network in order
to be most effective. But my OpenSIPS server doesn’t sit
on the Edge of the network, it is behind an SBC. So TH is
complicated by the fact that my OpenSIPS has no public IP
of its own and must advertise the public IP of the SBC
instead, but future requests must still be routable into
the private network. I am really using TH to hide the two
ends of the call from each other, not to hide my internal
network topology.
Ben Newlin
*From: *Bogdan-Andrei Iancu <[email protected]>
<mailto:[email protected]>
*Date: *Friday, July 29, 2016 at 8:40 AM
*To: *"Newlin, Ben" <[email protected]>
<mailto:[email protected]>, OpenSIPS users mailling list
<[email protected]> <mailto:[email protected]>
*Subject: *Re: [OpenSIPS-Users] Record-Route and Dialog
topology_hiding()
Hi Ben,
Sorry to disagree, but IMHO they do exclude one each other.
Adding RR to TH should not be seen as a way of fixing some
broken TH scenarios (with advertise).
So, let me try to understand what is not working for you.
You do TH and advertise. In this case, normally, in the
Contact headers generated by OpenSIPS (as a result of TH),
it should be the TH interface, right ? What exactly seems
to be the problem ? do you have a trace to show the issues ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 27.07.2016 16:05, Newlin, Ben wrote:
I understand that normally you would not need RR with
TH, but the two concepts are not mutually exclusive in
SIP. As I said, I have a need to Record-Route the call
on my server as I am advertising a different address
than I am listening on. This means that TH will
populate the Contact header with the advertised
address and if I cannot Record-Route with the actual
address then I will not receive sequential requests.
Ben Newlin
*From: *Bogdan-Andrei Iancu <[email protected]>
<mailto:[email protected]>
*Date: *Wednesday, July 27, 2016 at 3:59 AM
*To: *OpenSIPS users mailling list
<[email protected]>
<mailto:[email protected]>, "Newlin, Ben"
<[email protected]> <mailto:[email protected]>
*Subject: *Re: [OpenSIPS-Users] Record-Route and
Dialog topology_hiding()
Hi Ben,
As I mentioned in different thread, TH is not
compatible with the RR mechanism. If you do TH, your
OpenSIPS will act as and end point (from SIP
perspective), so there will be no Route/RR headers at
all. So no need to do loose_route or so. You just do
TH matching for the sequential requests and nothing more.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 22.07.2016 16:48, Newlin, Ben wrote:
Hi,
I am using the Dialog module with
topology_hiding() in my server and I have a need
to Record-Route the call on my server as I am
advertising a different address than I am
listening on. I have found what I believe is an
inconsistency in the handling of Record-Route
within the Dialog topology_hiding functionality.
The topology_hiding isn’t a true B2BUA, but it
does set up different parameters for the incoming
UAC and outgoing UAS sides of the call for the Via
headers, Record-Route and Route headers, and the
Contact header(s).
The problem is that the record_route() and
loose_route() functions operate on different sides
of the call. The record_route() function will only
add a Record-Route header to the outgoing UAS side
of the call. And since the record_route() function
cannot be called from onreply_route, but is no way
to add a Record-Route header to the UAC side of
the call.
On the other hand, the loose_route() function only
operates on the incoming UAC side of the call and
there is no way to perform loose_route() on the
UAS side of the call.
So there is a situation where Record-Route headers
can only be added on the outgoing UAS side, but
the associated Route headers can only be removed
on the incoming UAC side (where they won’t exist
since they can’t be added) and any added headers
on the UAS side cannot be processed properly due
to the lack of loose_route.
I can provide further information if this is
unclear. It should be easily reproducible by
attempting to use record_route in a
topology_hiding scenario. The route is added to
the outbound leg, but is not removed by
loose_route so the message is looped back every time.
*Ben Newlin***| Sr Voice Network Engineer, PureCloud
phone & fax +1.317.957.1009 | [email protected]
<mailto:[email protected]>
removed by sender.
www.inin.com <http://www.inin.com>
_______________________________________________
Users mailing list
[email protected]
<mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
