[jitsi-dev] SIP Accounts: Registrar and Proxy


#1

Hey

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
   - auto-detect:
    - 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?

Thanks,
Ingo


#2

Hi,

I also spotted some problem in this area and have some modifications
in my workspace.
The problem I saw and tried to solve is for example if you have DNS
entries which changes the order (it can be fo load balancing) because
of the two DNS resolution made one for registrar and one for the proxy
you can end up with wrong and different settings for registrar and
proxy (different transport for example).
And yes you are right, there is no need of those two dns resolutions
and so I left only one that is used for initializing registrar and
outbound proxy.
We need those dns queries to be done when making registar connection
object cause in case of automatic configuration (when doing NAPTR
query) we must take into account the protocol that will be used and no
real connection is done.
WDYT?

If you want I can send you a patch so we can test my modifications
before committing them :slight_smile:

Thanks
damencho

···

On Tue, Aug 2, 2011 at 12:04 PM, Bauersachs Ingo <ingo.bauersachs@fhnw.ch> wrote:

Hey

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
- auto-detect:
- 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?

Thanks,
Ingo