[OpenSIPS-Users] Record-Route and Dialog topology_hiding()
Bogdan-Andrei Iancu
bogdan at opensips.org
Fri Sep 30 10:39:32 CEST 2016
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 <bogdan at opensips.org>
> *Date: *Monday, August 1, 2016 at 7:13 AM
> *To: *"Newlin, Ben" <Ben.Newlin at inin.com>, OpenSIPS users mailling
> list <users at 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 <bogdan at opensips.org>
> <mailto:bogdan at opensips.org>
> *Date: *Friday, July 29, 2016 at 8:40 AM
> *To: *"Newlin, Ben" <Ben.Newlin at inin.com>
> <mailto:Ben.Newlin at inin.com>, OpenSIPS users mailling list
> <users at lists.opensips.org> <mailto:users at 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 <bogdan at opensips.org>
> <mailto:bogdan at opensips.org>
> *Date: *Wednesday, July 27, 2016 at 3:59 AM
> *To: *OpenSIPS users mailling list <users at lists.opensips.org>
> <mailto:users at lists.opensips.org>, "Newlin, Ben"
> <Ben.Newlin at inin.com> <mailto:Ben.Newlin at 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.newlin at inin.com
> <mailto:ben.newlin at inin.com>
>
> ge removed by sender.
>
> www.inin.com <http://www.inin.com>
>
>
>
>
>
>
> _______________________________________________
>
> Users mailing list
>
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20160930/29cd0656/attachment-0001.htm>
More information about the Users
mailing list