[OpenSIPS-Users] on routing invite's in a trunk context.
Ben Newlin
Ben.Newlin at genesys.com
Mon Oct 9 14:05:23 UTC 2023
Johan,
I think you must have left some pieces out of your initial description then. You stated that node A is sending directly to your OpenSIPS node, so the source IP and Via would both point to node A.
As I mentioned, changes to Contact and Record-Route headers will only affect the routing of sequential requests for the dialog. They will not impact the routing of responses. I don’t think that OpenSIPS provides any mechanism to change the destination of responses it proxies, since as you said this is outside of the RFC.
Ben Newlin
From: Users <users-bounces at lists.opensips.org> on behalf of Johan De Clercq <johan at democon.be>
Date: Saturday, October 7, 2023 at 1:40 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] on routing invite's in a trunk context.
EXTERNAL EMAIL - Please use caution with links and attachments
________________________________
It’s a very non rfc scenario. Source ip and via are the ip of a loadbalancer that I need to skip …. ;-(. The contact does have the correct ip. Anyway, you gave me a good hint. I will add the contact ip as record route and see what that gives.
Verzonden vanuit Outlook voor iOS<https://aka.ms/o0ukef>
________________________________
Van: Users <users-bounces at lists.opensips.org> namens Ben Newlin <Ben.Newlin at genesys.com>
Verzonden: Friday, October 6, 2023 5:35:40 PM
Aan: OpenSIPS users mailling list <users at lists.opensips.org>
Onderwerp: Re: [OpenSIPS-Users] on routing invite's in a trunk context.
Johan,
This is actually a pretty standard SIP flow that we use all the time. I recommend this article [1] for an overview of how routing works in SIP.
In short, the Contact and Record-Route headers are only used for routing of requests not responses, and mostly only sequential requests which are requests within a dialog. The topology_hiding_match and loose_route functions both operate on requests only, so they can both only be called from a request_route [1] [2].
The 200 OK is a response within the initial INVITE transaction. Responses within a SIP transaction are routed based on the source IP of request and/or the Via headers. OpenSIPS should just handle that for you, unless you have some strange routing.
[1] https://kb.smartvox.co.uk/opensips/contact-and-record-route-headers-explained/<https://kb.smartvox.co.uk/opensips/contact-and-record-route-headers-explained/>
[2] https://opensips.org/docs/modules/3.2.x/topology_hiding.html#func_topology_hiding_match<https://opensips.org/docs/modules/3.2.x/topology_hiding.html#func_topology_hiding_match>
[3] https://opensips.org/docs/modules/3.2.x/rr.html#func_loose_route<https://opensips.org/docs/modules/3.2.x/rr.html#func_loose_route>
Ben Newlin
From: Users <users-bounces at lists.opensips.org> on behalf of johan <johan at democon.be>
Date: Friday, October 6, 2023 at 10:30 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: [OpenSIPS-Users] on routing invite's in a trunk context.
EXTERNAL EMAIL - Please use caution with links and attachments
This is a general question on routing (to be honest: it is a really
strange case).
A has a sip trunk to B (opensips), B has a sip trunk to C
A sends an invite to B with contact header A' and record-route header
to A''
B string the record_route header , calls topology hiding and droutes the
call to C
C sends 200 OK back but it needs to be routed on the content of the
contact header.
Now how does this route to A ? Is this the default
topology_hiding_match() case ? Or do I need to do something special ?
_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20231009/144fe254/attachment-0001.html>
More information about the Users
mailing list