I wanted to add the lookup of _sip._tcp.domain and _sips._tcp.domain to the automatic proxy detection, but I stumbled across various code flows I don't understand or that might be wrong:
a) A registrar address that cannot be resolved via DNS causes a connection failure.
This is OK if we don't use a proxy, but apart from registrarless accounts, we _always_ use a proxy. So why do we need to make a lookup of the registrar address at all?
b) If the registrar address is resolvable, and it would return multiple records we store them and try to connect to each of them in the order returned from DNS. Now on each try to register the account, the proxy is also initialized with the same address index as the currently tried registrar address. BUT: the proxy initialization makes its own DNS lookups (which might return a completely different number of records). So if the proxy hostname returns fewer records than the registrar hostname, we might run into an IndexOutOfRangeException.
Furthermore we connect to the next proxy even if only the connection to the registrar failed.
If I'm not completely missing something, I suppose it should work as follows:
1) Do NOT connect to the registrar at all
2) - use manually defined proxy if set
- get domain-part of the SIP-ID (NOT registrar)
- search for NAPTR, use it if present
- search for all SRV variations, use in our own preference*
- use direct A/AAAA lookups if NAPTR/SRV failed
* (defined by a new property, default is TLS -> TCP -> UDP)
(I already discussed 2) with Emil, so unless we both missed something this should be fine.)
Can anyone shed some light of why we connect to the registrar directly?