[OpenSIPS-Users] Record-Route and Dialog topology_hiding()
Bogdan-Andrei Iancu
bogdan at opensips.org
Tue Oct 4 11:28:41 CEST 2016
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 <bogdan at opensips.org>
> *Date: *Friday, September 30, 2016 at 4:39 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,
>
> 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>
> <mailto:bogdan at opensips.org>
> *Date: *Monday, August 1, 2016 at 7:13 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,
>
> 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>
>
> e 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/20161004/90015318/attachment-0001.htm>
More information about the Users
mailing list