Hi Ben,
Sorry to disagree, but IMHO they do exclude one eachother.
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]>
*Date: *Wednesday, July 27, 2016 at 3:59 AM
*To: *OpenSIPS users mailling list <[email protected]>,
"Newlin, Ben" <[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]>
mage 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
