[OpenSIPS-Users] Record-Route and Dialog topology_hiding()
Bogdan-Andrei Iancu
bogdan at opensips.org
Wed Oct 5 15:12:41 CEST 2016
Ben,
The match_dialog() does not uses or rely on the loose_route()
functionality- I briefly checked the code in 1.11; but if you have some
logs to show it otherwise, do not hesitate to share with me (of course,
if you are 100% sure you do not also call loose_route() from scritp ;) ).
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 04.10.2016 16:03, Newlin, Ben wrote:
>
> 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 <bogdan at opensips.org>
> *Date: *Tuesday, October 4, 2016 at 5:28 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()
>
> 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>
> <mailto:bogdan at opensips.org>
> *Date: *Friday, September 30, 2016 at 4:39 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, 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>
>
> 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/20161005/e954fedc/attachment-0001.htm>
More information about the Users
mailing list