[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