Hi Ben,
1) I'm not recommending, I'm giving a workaround to your problem,
considering the limited SBC that cannot do TH or advertise the desired
contact IP (and abusing OpenSIPS to deal with this limitationof the SBC).
2) I'm saying "fake" RR as you do it just for the SBC sake - from
OpenSIPS perspective has 0 valueand usage. You insert the RR headerwith
the single purpose of forcing the SBC "notto look" into the RURI and to
provide a workaround for routing to OpenSIPS. And it is fake as you do
not have to do the other half, the loose_route() part.
4) No, I do not agree- the RR and TH are excluding one each other IMO.
Once again, from the logical perspective of the SIP routing, this is is
a non-sense. I'm suggesting this forced "marriage" just to solve the SBC
problemand nothing more.
5) what you are attempting is not in the SIP normals - you are forcing
the boundaries just to overcome the limitations of the SBC.
6) I agree there should be nocrash, whatever crazy combination is used
from the script, and if ok with you, I would like to push forward here.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 01.08.2016 16:42, Newlin, Ben wrote:
Bogdan,
You are recommending using RR on my server with TH, which is exactly
what I want to do. Your solution is to do it manually because the RR
module can’t be used with the TH module. This is not faking or
tricking just because it is done manually; it is a real RR header and
the SBC would be following correct SIP routing processes.
So we agree that the SIP concepts of RR and TH are not mutually
exclusive, it is only the OpenSIPS modules that are incompatible. This
confirms what I saw in my testing and reported in the initial email.
I think it would be a useful enhancement if the two modules did work
together and the RR module supported doing everything you suggest
doing manually below, just as it does today when TH is not used. But
if that is not feasible or practical within the OpenSIPS architecture
I understand. In that case, I believe a note in the documentation of
the incompatibility between these modules would be beneficial as well,
as it would have saved me many hours attempting to make this work and
may save others that time as well.
Ben Newlin
*From: *Bogdan-Andrei Iancu <[email protected]>
*Date: *Monday, August 1, 2016 at 7:13 AM
*To: *"Newlin, Ben" <[email protected]>, OpenSIPS users mailling
list <[email protected]>
*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 <[email protected]>
<mailto:[email protected]>
*Date: *Friday, July 29, 2016 at 8:40 AM
*To: *"Newlin, Ben" <[email protected]>
<mailto:[email protected]>, OpenSIPS users mailling list
<[email protected]> <mailto:[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]>
ge 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
