[sip-comm-dev] patch sip reconnecting SRV,AAAA,A


#1

Hi all,

I was recently working on a problem with connecting to ipv4 services
on ipv6 enabled hosts. I made a resolution for it but need some ipv6
and sip expert opinion on it.

The problem:
can be easily seen on Linux with java.net.preferIPv6Addresses=true.
Recently a new default value was set to most Linux distributions
net.inet6.ip6.v6only=1, bind ipv6 only.
So when you try to connect to ipv4 service which has ipv6 DNS records
our behaviour is to try only using ipv6 address and at the end it
fails.

The resolution:
our SipRegistrarConnection gets a single address to connect to, but
I've made it to take an array of addresses and after the first timeout
it tries the second address and so on. The addresses we pass are
ordered - first the SRV records if any, after that AAAA or A records
who is first depends on the value of the system property
java.net.preferIPv6Addresses.

This way we order the connect to hosts and don't rely on the OS behaviour.

I made similar thing and to jabber protocol provider to solve the same
problem there.

Anybody to test or comment it is welcome :slight_smile:
Thanks
damencho

reconnect_patch_sip.diff (16.9 KB)


#2

Hi Damian,

Le 08/09/2010 08:42, Damian Minkov a �crit :

Hi all,

I was recently working on a problem with connecting to ipv4 services
on ipv6 enabled hosts. I made a resolution for it but need some ipv6
and sip expert opinion on it.

The problem:
can be easily seen on Linux with java.net.preferIPv6Addresses=true.
Recently a new default value was set to most Linux distributions
net.inet6.ip6.v6only=1, bind ipv6 only.
So when you try to connect to ipv4 service which has ipv6 DNS records
our behaviour is to try only using ipv6 address and at the end it
fails.
   The resolution:
our SipRegistrarConnection gets a single address to connect to, but
I've made it to take an array of addresses and after the first timeout
it tries the second address and so on. The addresses we pass are
ordered - first the SRV records if any, after that AAAA or A records
who is first depends on the value of the system property
java.net.preferIPv6Addresses.

This way we order the connect to hosts and don't rely on the OS behaviour.

I made similar thing and to jabber protocol provider to solve the same
problem there.

Anybody to test or comment it is welcome :slight_smile:
   
The patch looks great. After an initial test, it seems to work fine if SIP transport is UDP but not TCP or TLS. For the last two cases, it raises an exception:
20:11:51.440 GRAVE: impl.protocol.sip.SipRegistrarConnection.register().262 Could not send out the register request!

It is because the TCP three way handshake is not finished and the SIP data cannot be sent. To solve this, we could retry with another address (with the mechanism you propose) if this exception is raised.

I will test it more tomorrow.

Regards,

···

--
Seb

Thanks
damencho
   
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi,

I think I have tested the scenario with TCP and TLS and it was
working, I will check it again maybe missed something in the patch.

Thanks
damencho

···

On Wed, Sep 8, 2010 at 9:40 PM, Sebastien Vincent <seb@sip-communicator.org> wrote:

Hi Damian,

Le 08/09/2010 08:42, Damian Minkov a écrit :

Hi all,

I was recently working on a problem with connecting to ipv4 services
on ipv6 enabled hosts. I made a resolution for it but need some ipv6
and sip expert opinion on it.

The problem:
can be easily seen on Linux with java.net.preferIPv6Addresses=true.
Recently a new default value was set to most Linux distributions
net.inet6.ip6.v6only=1, bind ipv6 only.
So when you try to connect to ipv4 service which has ipv6 DNS records
our behaviour is to try only using ipv6 address and at the end it
fails.

The resolution:
our SipRegistrarConnection gets a single address to connect to, but
I've made it to take an array of addresses and after the first timeout
it tries the second address and so on. The addresses we pass are
ordered - first the SRV records if any, after that AAAA or A records
who is first depends on the value of the system property
java.net.preferIPv6Addresses.

This way we order the connect to hosts and don't rely on the OS behaviour.

I made similar thing and to jabber protocol provider to solve the same
problem there.

Anybody to test or comment it is welcome :slight_smile:

The patch looks great. After an initial test, it seems to work fine if SIP
transport is UDP but not TCP or TLS. For the last two cases, it raises an
exception:
20:11:51.440 GRAVE: impl.protocol.sip.SipRegistrarConnection.register().262
Could not send out the register request!

It is because the TCP three way handshake is not finished and the SIP data
cannot be sent. To solve this, we could retry with another address (with the
mechanism you propose) if this exception is raised.

I will test it more tomorrow.

Regards,
--
Seb

Thanks
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Yes you are right, that condition is not present in the patch, will
try to update it tomorrow morning.

Thanks
damencho

···

On Wed, Sep 8, 2010 at 9:47 PM, Damian Minkov <damencho@sip-communicator.org> wrote:

Hi,

I think I have tested the scenario with TCP and TLS and it was
working, I will check it again maybe missed something in the patch.

Thanks
damencho

On Wed, Sep 8, 2010 at 9:40 PM, Sebastien Vincent > <seb@sip-communicator.org> wrote:

Hi Damian,

Le 08/09/2010 08:42, Damian Minkov a écrit :

Hi all,

I was recently working on a problem with connecting to ipv4 services
on ipv6 enabled hosts. I made a resolution for it but need some ipv6
and sip expert opinion on it.

The problem:
can be easily seen on Linux with java.net.preferIPv6Addresses=true.
Recently a new default value was set to most Linux distributions
net.inet6.ip6.v6only=1, bind ipv6 only.
So when you try to connect to ipv4 service which has ipv6 DNS records
our behaviour is to try only using ipv6 address and at the end it
fails.

The resolution:
our SipRegistrarConnection gets a single address to connect to, but
I've made it to take an array of addresses and after the first timeout
it tries the second address and so on. The addresses we pass are
ordered - first the SRV records if any, after that AAAA or A records
who is first depends on the value of the system property
java.net.preferIPv6Addresses.

This way we order the connect to hosts and don't rely on the OS behaviour.

I made similar thing and to jabber protocol provider to solve the same
problem there.

Anybody to test or comment it is welcome :slight_smile:

The patch looks great. After an initial test, it seems to work fine if SIP
transport is UDP but not TCP or TLS. For the last two cases, it raises an
exception:
20:11:51.440 GRAVE: impl.protocol.sip.SipRegistrarConnection.register().262
Could not send out the register request!

It is because the TCP three way handshake is not finished and the SIP data
cannot be sent. To solve this, we could retry with another address (with the
mechanism you propose) if this exception is raised.

I will test it more tomorrow.

Regards,
--
Seb

Thanks
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi,

I've tested it and with TCP and TLS and now I think everything is
fine. Attaching the latest patch.

Thanks
damencho

reconnect_patch_sip.diff (18.5 KB)

···

On Wed, Sep 8, 2010 at 9:58 PM, Damian Minkov <damencho@sip-communicator.org> wrote:

Yes you are right, that condition is not present in the patch, will
try to update it tomorrow morning.

Thanks
damencho

On Wed, Sep 8, 2010 at 9:47 PM, Damian Minkov > <damencho@sip-communicator.org> wrote:

Hi,

I think I have tested the scenario with TCP and TLS and it was
working, I will check it again maybe missed something in the patch.

Thanks
damencho

On Wed, Sep 8, 2010 at 9:40 PM, Sebastien Vincent >> <seb@sip-communicator.org> wrote:

Hi Damian,

Le 08/09/2010 08:42, Damian Minkov a écrit :

Hi all,

I was recently working on a problem with connecting to ipv4 services
on ipv6 enabled hosts. I made a resolution for it but need some ipv6
and sip expert opinion on it.

The problem:
can be easily seen on Linux with java.net.preferIPv6Addresses=true.
Recently a new default value was set to most Linux distributions
net.inet6.ip6.v6only=1, bind ipv6 only.
So when you try to connect to ipv4 service which has ipv6 DNS records
our behaviour is to try only using ipv6 address and at the end it
fails.

The resolution:
our SipRegistrarConnection gets a single address to connect to, but
I've made it to take an array of addresses and after the first timeout
it tries the second address and so on. The addresses we pass are
ordered - first the SRV records if any, after that AAAA or A records
who is first depends on the value of the system property
java.net.preferIPv6Addresses.

This way we order the connect to hosts and don't rely on the OS behaviour.

I made similar thing and to jabber protocol provider to solve the same
problem there.

Anybody to test or comment it is welcome :slight_smile:

The patch looks great. After an initial test, it seems to work fine if SIP
transport is UDP but not TCP or TLS. For the last two cases, it raises an
exception:
20:11:51.440 GRAVE: impl.protocol.sip.SipRegistrarConnection.register().262
Could not send out the register request!

It is because the TCP three way handshake is not finished and the SIP data
cannot be sent. To solve this, we could retry with another address (with the
mechanism you propose) if this exception is raised.

I will test it more tomorrow.

Regards,
--
Seb

Thanks
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi Damian,

Le 09/09/2010 11:15, Damian Minkov a �crit :

Hi,

I've tested it and with TCP and TLS and now I think everything is
fine. Attaching the latest patch.
   
I test it on my side and it works well.

···

--
Seb

Thanks
damencho

On Wed, Sep 8, 2010 at 9:58 PM, Damian Minkov > <damencho@sip-communicator.org> wrote:
   

Yes you are right, that condition is not present in the patch, will
try to update it tomorrow morning.

Thanks
damencho

On Wed, Sep 8, 2010 at 9:47 PM, Damian Minkov >> <damencho@sip-communicator.org> wrote:
     

Hi,

I think I have tested the scenario with TCP and TLS and it was
working, I will check it again maybe missed something in the patch.

Thanks
damencho

On Wed, Sep 8, 2010 at 9:40 PM, Sebastien Vincent >>> <seb@sip-communicator.org> wrote:
       

Hi Damian,

Le 08/09/2010 08:42, Damian Minkov a �crit :

Hi all,

I was recently working on a problem with connecting to ipv4 services
on ipv6 enabled hosts. I made a resolution for it but need some ipv6
and sip expert opinion on it.

The problem:
can be easily seen on Linux with java.net.preferIPv6Addresses=true.
Recently a new default value was set to most Linux distributions
net.inet6.ip6.v6only=1, bind ipv6 only.
So when you try to connect to ipv4 service which has ipv6 DNS records
our behaviour is to try only using ipv6 address and at the end it
fails.

The resolution:
our SipRegistrarConnection gets a single address to connect to, but
I've made it to take an array of addresses and after the first timeout
it tries the second address and so on. The addresses we pass are
ordered - first the SRV records if any, after that AAAA or A records
who is first depends on the value of the system property
java.net.preferIPv6Addresses.

This way we order the connect to hosts and don't rely on the OS behaviour.

I made similar thing and to jabber protocol provider to solve the same
problem there.

Anybody to test or comment it is welcome :slight_smile:

The patch looks great. After an initial test, it seems to work fine if SIP
transport is UDP but not TCP or TLS. For the last two cases, it raises an
exception:
20:11:51.440 GRAVE: impl.protocol.sip.SipRegistrarConnection.register().262
Could not send out the register request!

It is because the TCP three way handshake is not finished and the SIP data
cannot be sent. To solve this, we could retry with another address (with the
mechanism you propose) if this exception is raised.

I will test it more tomorrow.

Regards,
--
Seb

Thanks
damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net