[OpenSIPS-Devel] [opensips] sip_resolvehost srv logic (#482)

[Jarrod Baumann]

This may be a non-issue, but I have been using `sip_resolvehost` in an attempt to create fall-through scenarios based on protocol preference, so I am just trying to understand the logic.

When a protocol is specified (`tls` for example, but a port is omitted when calling `sip_resolvehost`, an attempt is made to resolve the SRV record (`_sips._tcp.domain.com`).  If the SRV record does not exist, it simply tries to resolve the A record for the domain, but then preserves the attempted protocol and default port for that protocol in the return.

Here is a pseudo example of the flow:

1) sip_resolvehost(*name="opensips.org", *port=0, *protocol=PROTO_TLS)
2) attempt to find srv record _sips._tcp.opensips.org
3) no record exists
4) set the port to 5061 (the default for PROTO_TLS)
5) resolve the A record for opensips.org
6) return the results

It seems it would be better, if falling through to an A (or AAAA) record to set the port and protocol to a default:

```
diff --git a/resolve.c b/resolve.c
index 86ac6e5..8a5686c 100644
--- a/resolve.c
+++ b/resolve.c
@@ -1835,7 +1835,7 @@ do_srv:
                LM_WARN("domain name too long (%d),"
                        " unable to perform SRV lookup\n", name->len);
                /* set defaults */
-               if (port) *port = (is_sips)?SIPS_PORT:SIP_PORT;
+                if (port) *port = SIP_PORT;
                goto do_a;
        }
 
@@ -1876,7 +1876,7 @@ do_srv:
        LM_DBG("no valid SRV record found for %s, trying A record lookup...\n",
                tmp);
        /* set default port */
-       if (port) *port = protos[*proto].default_port;
+       if (port) *port = SIP_PORT;
 
 do_a:
        /* do A record lookup */
```

Or, if requesting a **specific** protocol, which was **not** found, then return 0 so a decision could be made upstream.

I may be way off base, just trying to see if this was the intended result.


---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/482
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20150428/31ac4156/attachment.htm>