[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