SRV request falls back to A/AAAA prematurely

[rtreleaven]

version
OSX Desktop 4.0 - QT 5.9.0
Core 3.11.2-158-g4c291e2

steps to reproduce
configure network->sip_udp_port = enabled
configure network->sip_tcp_port = enabled

create a tcp SRV record for your_domain.com
ensure that no UDP SRV record exists for your_domain.com
place a call to joe@your_domain.com

observed
2017-08-04 12:21:32:797 MESSAGE resolver_process_data dns_res_check() in progress
2017-08-04 12:21:32:837 MESSAGE No SRV result for [_sip._udp.your_domain.com], trying A/AAAA.

expected
resolver should try SRV query for UDP, TCP and possibly TLS before falling back to A/AAAA
Alternately, implement NAPTR support

Background
UDP is becoming less and less suitable for SIP transport.

1. SIP methods are getting large enough to exceed the maximum size of UDP payloads.
2. UDP does not have a handshake mechanism, so requests with spoofed source addresses make it up the stack.
   Therefore an IDS/IPS can be tricked into blocking legitimate ip addresses.

[ghismary]

Do you know of an existing domain that do not have a UDP SRV record but have TCP one so that I can debug this without having to configure a new domain?

[rtreleaven]

fv.bunnykick.ca

…

On Fri, Aug 4, 2017 at 1:36 PM, Ghislain MARY ***@***.***> wrote: Do you know of an existing domain that do not have a UDP SRV record but have TCP one so that I can debug this without having to configure a new domain? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#57 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AdEjOyA7nl4HVYXe0GerPb38NygzDXeGks5sU1aVgaJpZM4Ot8Yt> .

-- Sincerely, Russell Treleaven sip:rtreleaven@sip.bunnykick.ca

[rtreleaven]

workaround is to add the transport to the uri joe@your_domain.com;transport=tcp

[ghismary]

I've checked, this is not a bug. If you do not specify the transport to use, the transport is UDP and then it is perfectly ok to perform the SRV query for _sip._udp.your_domain.com.
Specifying the TCP transport is not a workaround, it's the correct way to configure the proxy config.

[etamme]

If you do not specify the transport to use, the transport is UDP

This is absolutely false. RFC 3263 has a very clear process for doing NAPTR, SRV, and A/AAAA lookups, in that order.

Please, take some time and read https://tools.ietf.org/html/rfc3263 Specifically section 4.1, selecting a protocol.

https://tools.ietf.org/html/rfc3263#section-4.1

[rtreleaven]

Please re-open this bug.

[systemcrash]

I see no "MUST" here, from RFC3263:

... if no transport protocol or port is specified, and the
target is not a numeric IP address, the client SHOULD perform a NAPTR
query for the domain in the URI.

BUT

SIP RFC 3261 clearly mandates UDP as the default, with TCP as a fallback. So both should definitely be tried. UDP->TCP. SRV lookups should definitely parse for all available transports/protocols, to attempt to fulfill the request as well possible.
https://tools.ietf.org/html/rfc3261#section-18

with the following proviso/caveat (emphasis on the transport parameter):
https://tools.ietf.org/html/rfc3261#section-19.1.4

"
o For two URIs to be equal, the user, password, host, and port
components must match.

     A URI omitting the user component will not match a URI that
     includes one.  A URI omitting the password component will not
     match a URI that includes one.

     A URI omitting any component with a default value will not
     match a URI explicitly containing that component with its
     default value.  For instance, a URI omitting the optional port
     component will not match a URI explicitly declaring port 5060.
     The same is true for the transport-parameter, ttl-parameter,
     user-parameter, and method components.

        Defining sip:user@host to not be equivalent to
        sip:user@host:5060 is a change from RFC 2543.  When deriving
        addresses from URIs, equivalent addresses are expected from
        equivalent URIs.  The URI sip:user@host:5060 will always
        resolve to port 5060.  The URI sip:user@host may resolve to
        other ports through the DNS SRV mechanisms detailed in [4].

"
i.e. joe@your_domain.com implies UDP, and joe@your_domain.com;transport=tcp clearly implying TCP. But this is not about matching a URI since it is a new call, and fallback TCP mechanism should be tried, and the relevant VIA header stamped with TCP when this transport fallback is tried.

Although NAPTR would be more accommodating.

[rtreleaven]

please reopen this bug