[jitsi-dev] problem with NAPTR persists


#1

Hello,

we have discuss this issue in thread:
"SIP not working in Ubuntu 12.04.1 64b"

the conclusion was
1. JITSI should prefer usage of TCP (e.g. while UDP big packet fragmentation problem)
2. but NAPTR must allow this by priority setting
3. JITSI should use SIPS if available

Thanks great support of my SIP provider we had set it on server.
(before there was (100,50) for UDP and (200,50) for TCP -> ad.2 -> UDP was used)

but now:

$ host -t NAPTR sip.odorik.cz
sip.odorik.cz has NAPTR record 100 50 "s" "SIP+D2T" "" _sip._tcp.sip.odorik.cz.
sip.odorik.cz has NAPTR record 100 50 "s" "SIP+D2U" "" _sip._udp.sip.odorik.cz.
sip.odorik.cz has NAPTR record 100 51 "s" "SIPS+D2T" "" _sips._tcp.sip.odorik.cz.

But JITSI still uses UDP, not TCP - even if the choice is only and only on JITSI.

And the SIPS is not used too.

SIP client must respect first priority in NAPTR (100 < 200 in our cases in previous) but the second one is only recommendation and client can use it how he want.

Thats mean in current case:
UDP = 100.50
TCP = 100,50 or 100,51 or 100,whatever

JITSI should use TCP !

And if there is SIPS 100,51 then JITSI should use SIPS too (if configured to prefer encrypted connection).

But JITSI do not do that :frowning:

--kapetr


#2

Hello,

we have discuss this issue in thread:
"SIP not working in Ubuntu 12.04.1 64b"

the conclusion was
1. JITSI should prefer usage of TCP (e.g. while UDP big packet fragmentation problem)
2. but NAPTR must allow this by priority setting
3. JITSI should use SIPS if available

Thanks great support of my SIP provider we had set it on server.
(before there was (100,50) for UDP and (200,50) for TCP -> ad.2 -> UDP was used)

but now:

$ host -t NAPTR sip.odorik.cz
sip.odorik.cz has NAPTR record 100 50 "s" "SIP+D2T" "" _sip._tcp.sip.odorik.cz.
sip.odorik.cz has NAPTR record 100 50 "s" "SIP+D2U" "" _sip._udp.sip.odorik.cz.
sip.odorik.cz has NAPTR record 100 51 "s" "SIPS+D2T" "" _sips._tcp.sip.odorik.cz.

But JITSI still uses UDP, not TCP - even if the choice is only and only on JITSI.

And the SIPS is not used too.

SIP client must respect first priority in NAPTR (100 < 200 in our cases in previous) but the second one is only recommendation and client can use it how he want.

The records for udp and tcp above contains exactly the same numbers. I don't see "200" anywhere.

/Mikael

···

On 01/03/2013 12:07 PM, kapetr wrote:

Thats mean in current case:
UDP = 100.50
TCP = 100,50 or 100,51 or 100,whatever

JITSI should use TCP !

And if there is SIPS 100,51 then JITSI should use SIPS too (if configured to prefer encrypted connection).

But JITSI do not do that :frowning:

--kapetr


#3

Read more carefully, Mikael.

"(before there was (100,50) for UDP and (200,50) for TCP -> ad.2 -> UDP was used)"

----- PŮVODNÍ ZPRÁVA -----
Od: "Mikael Magnusson" <mikma264@gmail.com>
Komu: dev@jitsi.java.net
Předmět: [jitsi-dev] Re: problem with NAPTR persists

···

Datum: 3.1.2013 - 13:11:58

On 01/03/2013 12:07 PM, kapetr wrote:
> Hello,
>
> we have discuss this issue in thread:
> "SIP not working in Ubuntu 12.04.1 64b"
>
> the conclusion was
> 1. JITSI should prefer usage of TCP (e.g. while UDP big packet fragmentation problem)
> 2. but NAPTR must allow this by priority setting
> 3. JITSI should use SIPS if available
>
>
> Thanks great support of my SIP provider we had set it on server.
> (before there was (100,50) for UDP and (200,50) for TCP -> ad.2 -> UDP was used)
>
> but now:
>
> $ host -t NAPTR sip.odorik.cz
> sip.odorik.cz has NAPTR record 100 50 "s" "SIP+D2T" "" _sip._tcp.sip.odorik.cz.
> sip.odorik.cz has NAPTR record 100 50 "s" "SIP+D2U" "" _sip._udp.sip.odorik.cz.
> sip.odorik.cz has NAPTR record 100 51 "s" "SIPS+D2T" "" _sips._tcp.sip.odorik.cz.
>
> But JITSI still uses UDP, not TCP - even if the choice is only and only on JITSI.
>
> And the SIPS is not used too.
>
> SIP client must respect first priority in NAPTR (100 < 200 in our cases in previous) but the second one is only recommendation and client can use it how he want.

The records for udp and tcp above contains exactly the same numbers. I
don't see "200" anywhere.

/Mikael

>
> Thats mean in current case:
> UDP = 100.50
> TCP = 100,50 or 100,51 or 100,whatever
>
> JITSI should use TCP !
>
> And if there is SIPS 100,51 then JITSI should use SIPS too (if configured to prefer encrypted connection).
>
> But JITSI do not do that :frowning:
>
> --kapetr
>


#4

Have you actually tried this with higher order and preference for tcp or
tls?

Is your report only about the case where order and preference give a tie
over udp and tcp?

--sent from my mobile

···

On Jan 5, 2013 2:14 PM, "kapetr" <kapetr@mizera.cz> wrote:

Read more carefully, Mikael.

"(before there was (100,50) for UDP and (200,50) for TCP -> ad.2 -> UDP
was used)"

----- PŮVODNÍ ZPRÁVA -----
Od: "Mikael Magnusson" <mikma264@gmail.com>
Komu: dev@jitsi.java.net
Předmět: [jitsi-dev] Re: problem with NAPTR persists
Datum: 3.1.2013 - 13:11:58

> On 01/03/2013 12:07 PM, kapetr wrote:
> > Hello,
> >
> > we have discuss this issue in thread:
> > "SIP not working in Ubuntu 12.04.1 64b"
> >
> > the conclusion was
> > 1. JITSI should prefer usage of TCP (e.g. while UDP big packet
fragmentation problem)
> > 2. but NAPTR must allow this by priority setting
> > 3. JITSI should use SIPS if available
> >
> >
> > Thanks great support of my SIP provider we had set it on server.
> > (before there was (100,50) for UDP and (200,50) for TCP -> ad.2 -> UDP
was used)
> >
> > but now:
> >
> > $ host -t NAPTR sip.odorik.cz
> > sip.odorik.cz has NAPTR record 100 50 "s" "SIP+D2T" "" _sip._
tcp.sip.odorik.cz.
> > sip.odorik.cz has NAPTR record 100 50 "s" "SIP+D2U" "" _sip._
udp.sip.odorik.cz.
> > sip.odorik.cz has NAPTR record 100 51 "s" "SIPS+D2T" "" _sips._
tcp.sip.odorik.cz.
> >
> > But JITSI still uses UDP, not TCP - even if the choice is only and
only on JITSI.
> >
> > And the SIPS is not used too.
> >
> > SIP client must respect first priority in NAPTR (100 < 200 in our
cases in previous) but the second one is only recommendation and client can
use it how he want.
>
> The records for udp and tcp above contains exactly the same numbers. I
> don't see "200" anywhere.
>
> /Mikael
>
> >
> > Thats mean in current case:
> > UDP = 100.50
> > TCP = 100,50 or 100,51 or 100,whatever
> >
> > JITSI should use TCP !
> >
> > And if there is SIPS 100,51 then JITSI should use SIPS too (if
configured to prefer encrypted connection).
> >
> > But JITSI do not do that :frowning:
> >
> > --kapetr
> >
>
>


#5

Hey all

The current proxy detection code only follows the preference given in the NAPTRs. If there are multiple NAPTRs with the same priority, it even gets random what we use and the weight is currently not used in any way (same goes for regexes in the NAPTRs, btw.).

So we actually should:
- Use /our/ protocol preference when the priority is the same in NAPTRs
- Respect the weight on same priorities after the protocol is selected (in SRV as well as NAPTR)
- If neither NAPTR nor SRV are present, try connecting with all protocols instead of only UDP

Regards,
Ingo


#6

Hello,

once again:

- the "order" (first - in our case 100 or 200) must be followed by client => TCP (200) could be only used if UDP (100) is failed to connect. But if both are =100 =>Jitsi can choice.

=> if we want Jitsi to prefer TCP over UDP, or prefer secTCP over TCP then

in NAPTR: TCP lover or !!!EQUAL!!! to UDP, ...

- the "preference" need not be respected! => if "order" UDP=TCP => JITSI should use TCP, (as many times discussed before), ...

====>>>>
please: add to Jitsi to prefer TCP over UDP (it is not true today)
please: add to Jitsi to prefer sec TCP over TCP (if so configured by user). (-"-)

Thanks --kapetr

----- PŮVODNÍ ZPRÁVA -----
Od: "Emil Ivov" <emcho@jitsi.org>
Komu: dev@jitsi.java.net
Předmět: [jitsi-dev] Re: problem with NAPTR persists

···

Datum: 5.1.2013 - 14:25:58

Have you actually tried this with higher order and preference for tcp or
tls?

Is your report only about the case where order and preference give a tie
over udp and tcp?

--sent from my mobile
On Jan 5, 2013 2:14 PM, "kapetr" <kapetr@mizera.cz> wrote:

> Read more carefully, Mikael.
>
> "(before there was (100,50) for UDP and (200,50) for TCP -> ad.2 -> UDP
> was used)"
>
> ----- PŮVODNÍ ZPRÁVA -----
> Od: "Mikael Magnusson" <mikma264@gmail.com>
> Komu: dev@jitsi.java.net
> Předmět: [jitsi-dev] Re: problem with NAPTR persists
> Datum: 3.1.2013 - 13:11:58
>
> > On 01/03/2013 12:07 PM, kapetr wrote:
> > > Hello,
> > >
> > > we have discuss this issue in thread:
> > > "SIP not working in Ubuntu 12.04.1 64b"
> > >
> > > the conclusion was
> > > 1. JITSI should prefer usage of TCP (e.g. while UDP big packet
> fragmentation problem)
> > > 2. but NAPTR must allow this by priority setting
> > > 3. JITSI should use SIPS if available
> > >
> > >
> > > Thanks great support of my SIP provider we had set it on server.
> > > (before there was (100,50) for UDP and (200,50) for TCP -> ad.2 -> UDP
> was used)
> > >
> > > but now:
> > >
> > > $ host -t NAPTR sip.odorik.cz
> > > sip.odorik.cz has NAPTR record 100 50 "s" "SIP+D2T" "" _sip._
> tcp.sip.odorik.cz.
> > > sip.odorik.cz has NAPTR record 100 50 "s" "SIP+D2U" "" _sip._
> udp.sip.odorik.cz.
> > > sip.odorik.cz has NAPTR record 100 51 "s" "SIPS+D2T" "" _sips._
> tcp.sip.odorik.cz.
> > >
> > > But JITSI still uses UDP, not TCP - even if the choice is only and
> only on JITSI.
> > >
> > > And the SIPS is not used too.
> > >
> > > SIP client must respect first priority in NAPTR (100 < 200 in our
> cases in previous) but the second one is only recommendation and client can
> use it how he want.
> >
> > The records for udp and tcp above contains exactly the same numbers. I
> > don't see "200" anywhere.
> >
> > /Mikael
> >
> > >
> > > Thats mean in current case:
> > > UDP = 100.50
> > > TCP = 100,50 or 100,51 or 100,whatever
> > >
> > > JITSI should use TCP !
> > >
> > > And if there is SIPS 100,51 then JITSI should use SIPS too (if
> configured to prefer encrypted connection).
> > >
> > > But JITSI do not do that :frowning:
> > >
> > > --kapetr
> > >
> >
> >
>
>


#7

Yes! Bingo :slight_smile:

So - it is not implemented yet (as was discussed), but hopefully it will be.
And while JITSI has great problem with big UDP packets, it should be soon.

Thanks --kapetr

----- PŮVODNÍ ZPRÁVA -----
Od: "Ingo Bauersachs" <ingo@jitsi.org>
Komu: dev@jitsi.java.net
Předmět: [jitsi-dev] Re: problem with NAPTR persists

···

Datum: 5.1.2013 - 15:16:38

Hey all

The current proxy detection code only follows the preference given in the NAPTRs. If there are multiple NAPTRs with the same priority, it even gets random what we use and the weight is currently not used in any way (same goes for regexes in the NAPTRs, btw.).

So we actually should:
- Use /our/ protocol preference when the priority is the same in NAPTRs
- Respect the weight on same priorities after the protocol is selected (in SRV as well as NAPTR)
- If neither NAPTR nor SRV are present, try connecting with all protocols instead of only UDP

Regards,
Ingo


#8

Hello Kapetr,

Thank you for reporting this issue.

Jitsi r10300 deals with the sorting NATPR issue (1-order, 2-preference, 3-protocol type [TLS > TCP > UDP]).
Please give it a try and give us some feedback.

Regards,
Vincent

···

On 1/7/13 1:26 PM, kapetr wrote:

Hello,

once again:

- the "order" (first - in our case 100 or 200) must be followed by client => TCP (200) could be only used if UDP (100) is failed to connect. But if both are =100 =>Jitsi can choice.

=> if we want Jitsi to prefer TCP over UDP, or prefer secTCP over TCP then

in NAPTR: TCP lover or !!!EQUAL!!! to UDP, ...

- the "preference" need not be respected! => if "order" UDP=TCP => JITSI should use TCP, (as many times discussed before), ...

====>>>>
please: add to Jitsi to prefer TCP over UDP (it is not true today)
please: add to Jitsi to prefer sec TCP over TCP (if so configured by user). (-"-)

Thanks --kapetr

----- P�VODN� ZPR�VA -----
Od: "Emil Ivov" <emcho@jitsi.org>
Komu: dev@jitsi.java.net
P�edm�t: [jitsi-dev] Re: problem with NAPTR persists
Datum: 5.1.2013 - 14:25:58

Have you actually tried this with higher order and preference for tcp or
tls?

Is your report only about the case where order and preference give a tie
over udp and tcp?

--sent from my mobile
On Jan 5, 2013 2:14 PM, "kapetr" <kapetr@mizera.cz> wrote:

Read more carefully, Mikael.

"(before there was (100,50) for UDP and (200,50) for TCP -> ad.2 -> UDP
was used)"

----- P�VODN� ZPR�VA -----
Od: "Mikael Magnusson" <mikma264@gmail.com>
Komu: dev@jitsi.java.net
P�edm�t: [jitsi-dev] Re: problem with NAPTR persists
Datum: 3.1.2013 - 13:11:58

On 01/03/2013 12:07 PM, kapetr wrote:

Hello,

we have discuss this issue in thread:
"SIP not working in Ubuntu 12.04.1 64b"

the conclusion was
1. JITSI should prefer usage of TCP (e.g. while UDP big packet

fragmentation problem)

2. but NAPTR must allow this by priority setting
3. JITSI should use SIPS if available

Thanks great support of my SIP provider we had set it on server.
(before there was (100,50) for UDP and (200,50) for TCP -> ad.2 -> UDP

was used)

but now:

$ host -t NAPTR sip.odorik.cz
sip.odorik.cz has NAPTR record 100 50 "s" "SIP+D2T" "" _sip._

tcp.sip.odorik.cz.

sip.odorik.cz has NAPTR record 100 50 "s" "SIP+D2U" "" _sip._

udp.sip.odorik.cz.

sip.odorik.cz has NAPTR record 100 51 "s" "SIPS+D2T" "" _sips._

tcp.sip.odorik.cz.

But JITSI still uses UDP, not TCP - even if the choice is only and

only on JITSI.

And the SIPS is not used too.

SIP client must respect first priority in NAPTR (100 < 200 in our

cases in previous) but the second one is only recommendation and client can
use it how he want.

The records for udp and tcp above contains exactly the same numbers. I
don't see "200" anywhere.

/Mikael

Thats mean in current case:
UDP = 100.50
TCP = 100,50 or 100,51 or 100,whatever

JITSI should use TCP !

And if there is SIPS 100,51 then JITSI should use SIPS too (if

configured to prefer encrypted connection).

But JITSI do not do that :frowning:

--kapetr

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org