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 <bog...@opensips.org>
*Date: *Friday, September 30, 2016 at 4:39 AM
*To: *"Newlin, Ben" <ben.new...@inin.com>, OpenSIPS users mailling
list <users@lists.opensips.org>
*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 <bog...@opensips.org>
<mailto:bog...@opensips.org>
*Date: *Monday, August 1, 2016 at 7:13 AM
*To: *"Newlin, Ben" <ben.new...@inin.com>
<mailto:ben.new...@inin.com>, OpenSIPS users mailling list
<users@lists.opensips.org> <mailto:users@lists.opensips.org>
*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 <bog...@opensips.org>
<mailto:bog...@opensips.org>
*Date: *Friday, July 29, 2016 at 8:40 AM
*To: *"Newlin, Ben" <ben.new...@inin.com>
<mailto:ben.new...@inin.com>, OpenSIPS users mailling list
<users@lists.opensips.org> <mailto:users@lists.opensips.org>
*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 <bog...@opensips.org>
<mailto:bog...@opensips.org>
*Date: *Wednesday, July 27, 2016 at 3:59 AM
*To: *OpenSIPS users mailling list
<users@lists.opensips.org>
<mailto:users@lists.opensips.org>, "Newlin, Ben"
<ben.new...@inin.com> <mailto:ben.new...@inin.com>
*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 | ben.new...@inin.com
<mailto:ben.new...@inin.com>
e removed by sender.
www.inin.com <http://www.inin.com>
_______________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
