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.
- whenrequestgetsto 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_matchingon OpenSIPS
and nothing more. This will send arequest 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 <[email protected]>
*Date: *Friday, July 29, 2016 at 8:40 AM
*To: *"Newlin, Ben" <[email protected]>, OpenSIPS users mailling
list <[email protected]>
*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 <[email protected]>
<mailto:[email protected]>
*Date: *Wednesday, July 27, 2016 at 3:59 AM
*To: *OpenSIPS users mailling list <[email protected]>
<mailto:[email protected]>, "Newlin, Ben"
<[email protected]> <mailto:[email protected]>
*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 | [email protected]
<mailto:[email protected]>
age removed by sender.
www.inin.com <http://www.inin.com>
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
