[OpenSIPS-Devel] [opensips] (discussion only) uri_resolve method build dest uri with SRV support (#483)

[Jarrod Baumann]

To help explain the pull request and further the discussion...  I suppose some of this type of logic could be incorporated into the current sip_resolvehost method where it referenced a global variable for the preferred protocol ordering attempts

However, there are some benefits of having a script pvar populated with this list and used for the resolving logic:
1) If you are keeping track of the protocols and what's been attempted, it's easy to failover to the next protocol in the list.
2) If, for example, TLS is first in the list but a domain does not have TLS records, the end user could choose to cache an updated protocol list for the destination host so that it skipped TLS on subsequent attempts.  It does seem inefficient to prefer TLS and attempt it on every SRV record, but have 90% of the destinations not support it.
3) Furthering the first point, it provides a mechanism for failing over, not just for protocols (tcp->udp) but also accounts for weight and priority within the same protocol.

As an example for point 3, consider the following results of an SRV query with multiple weighted records:

_sip._tcp.opensips.org.	3600	IN	SRV	0 50   5060 romania.opensips.org.
_sip._tcp.opensips.org.	3600	IN	SRV	0 100 5060 usa.opensips.org.
_sip._tcp.opensips.org.	3600	IN	SRV	0 150 5060 outerspace.opensips.org.

Since tcp returned results, the tcp protocol would be shifted from the pvar protocol list, but since there were multiple results returned for the SRV record (hostent->(char **)h_addr_list) we would rewrite the list to something like this "tcp:0:100;tcp:0:150;udp".  If romania timed out and failure_route was entered, we would pass the updated protocol list pvar back to the command and it would know the next result to try would be the tcp record with 0 priority and 100 weight and so on.

Lastly, we need to be able to determine the destination uri IP address **before** the request_route or branch_route (or failure_route?) so we know the address family of the destination.  Again, this aids in offering IPv6 or IPv4 SDP in the initial INVITE request which I believe is necessary.  Perhaps there are other benefits for having this information as well?

Anyway, those are my thoughts to continue the discussion and sheds light on why I chose to build a new script command as opposed to modifying the existing sip_resolve logic.  Although I do think sip_resolvehost will need to be modified in order to accomplish this.  If I can get some help in determining a decent plan that everyone likes, I can come up with an initial pull request to try to accomplish this.


---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/483#issuecomment-97659181
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20150429/a5a2617b/attachment.htm>