14 Feb
2008
14 Feb
'08
2:30 p.m.
Hi, I register a X-Lite (TCP client) and a Twinkle (UDP client) behind NAT. I
dissable STUN, ICE, keepalive, "discover external address", etc... in both.
They send a REGISTER to my OpenSer with public IP so I enable OPTIONS pinging
ifor both (I confirm that "location" table has the same cflags for the you
entries and so, all is correct.
But I just see a periodical SIP OPTIONS by UDP for Twinkle. Are they exist in
case of TCP?
--
Iñaki Baz Castillo
15 Feb
15 Feb
5:01 a.m.
Iñaki Baz Castillo schrieb:
Hi, I register a X-Lite (TCP client) and a Twinkle
(UDP client) behind NAT. I
dissable STUN, ICE, keepalive, "discover external address", etc... in both.
They send a REGISTER to my OpenSer with public IP so I enable OPTIONS pinging
ifor both (I confirm that "location" table has the same cflags for the you
entries and so, all is correct.
But I just see a periodical SIP OPTIONS by UDP for Twinkle. Are they exist in
case of TCP?
Looks like this is a limitation of the natpinging. I would think it
should work with TCP/TLS too (useful to handle clients which close the
TCP connection after some time).
klaus
5:14 a.m.
El Friday 15 February 2008 11:01:02 Klaus Darilion escribió:
Iñaki Baz Castillo schrieb:
Dan-Pascau said in devel maillist:
"NAT pinging only handles UDP. For TCP there is a flag to set connection
persistence to the lifetime of the registration."
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hi, I register a X-Lite (TCP client) and a
Twinkle (UDP client) behind
NAT. I dissable STUN, ICE, keepalive, "discover external address", etc...
in both.
They send a REGISTER to my OpenSer with public IP so I enable OPTIONS
pinging ifor both (I confirm that "location" table has the same cflags
for the you entries and so, all is correct.
But I just see a periodical SIP OPTIONS by UDP for Twinkle. Are they
exist in case of TCP?
Looks like this is a limitation of the natpinging. I would think it
should work with TCP/TLS too (useful to handle clients which close the
TCP connection after some time).
6:08 a.m.
Iñaki Baz Castillo schrieb:
El Friday 15 February 2008 11:01:02 Klaus Darilion
escribió:
Yes. This avoids that openser drops the TCP connection. But if the
client is buggy (I remember some problems with SNOM phones) and drops
the TCP line after inactivity then it does not help. But maybe we should
not take care of dump clients ....:-)
Iñaki Baz Castillo schrieb:
Dan-Pascau said in devel maillist:
"NAT pinging only handles UDP. For TCP there is a flag to set connection
persistence to the lifetime of the registration." Hi, I register a X-Lite (TCP client) and a
Twinkle (UDP client) behind
NAT. I dissable STUN, ICE, keepalive, "discover external address", etc...
in both.
They send a REGISTER to my OpenSer with public IP so I enable OPTIONS
pinging ifor both (I confirm that "location" table has the same cflags
for the you entries and so, all is correct.
But I just see a periodical SIP OPTIONS by UDP for Twinkle. Are they
exist in case of TCP?
Looks like this is a limitation of the natpinging. I would
think it
should work with TCP/TLS too (useful to handle clients which close the
TCP connection after some time). 
6:09 a.m.
Hi Klaus,
I did some test last year with nathelper sending pings over TCP and it
proofed to be non-functional. If the TCP connection is closed (from
client side), the timer process will actually hang trying to open a TCP
connection via NAT....
Regards,
Bogdan
Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
Hi, I register a X-Lite (TCP client) and a
Twinkle (UDP client) behind NAT. I
dissable STUN, ICE, keepalive, "discover external address", etc... in both.
They send a REGISTER to my OpenSer with public IP so I enable OPTIONS pinging
ifor both (I confirm that "location" table has the same cflags for the you
entries and so, all is correct.
But I just see a periodical SIP OPTIONS by UDP for Twinkle. Are they exist in
case of TCP?
Looks like this is a limitation of the natpinging. I would think it
should work with TCP/TLS too (useful to handle clients which close the
TCP connection after some time).
klaus
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
8:17 a.m.
Bogdan-Andrei Iancu schrieb:
Hi Klaus,
I did some test last year with nathelper sending pings over TCP and it
proofed to be non-functional. If the TCP connection is closed (from
client side), the timer process will actually hang trying to open a TCP
connection via NAT....
This brings me to an INO very useful feature request I mentioned some
time ago: For certain kind of scenarios it would be useful to tell
openser to "not open a new TCP connection if there is no existing TCP
connection" - e.g. by having a flag somewhere.
Use cases: natpinging, requests forwarded to TCP clients behind NAT
(e.g. after lookup), ....
regards
klaus
Regards,
Bogdan
Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
Hi, I register a X-Lite (TCP client) and a
Twinkle (UDP client)
behind NAT. I dissable STUN, ICE, keepalive, "discover external
address", etc... in both.
They send a REGISTER to my OpenSer with public IP so I enable OPTIONS
pinging ifor both (I confirm that "location" table has the same
cflags for the you entries and so, all is correct.
But I just see a periodical SIP OPTIONS by UDP for Twinkle. Are they
exist in case of TCP?
Looks like this is a limitation of the natpinging. I would think it
should work with TCP/TLS too (useful to handle clients which close the
TCP connection after some time).
klaus
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
8:51 a.m.
Right, but is a bit delicate as from routing script (SIP level) we start
playing with the transport layer :
- first will generate some confusion
- it will become more difficult to script down your configuration.
I was paying some second thoughts to some discussions we had some time
ago, about embedding some automation for some very standard behaviours,
in order to reduce the scripting complexity.....
I will attack this issue during the next week IRC meeting.
Regards,
Bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu schrieb:
Hi Klaus,
I did some test last year with nathelper sending pings over TCP and
it proofed to be non-functional. If the TCP connection is closed
(from client side), the timer process will actually hang trying to
open a TCP connection via NAT....
This brings me to an INO very useful feature request I mentioned some
time ago: For certain kind of scenarios it would be useful to tell
openser to "not open a new TCP connection if there is no existing TCP
connection" - e.g. by having a flag somewhere.
Use cases: natpinging, requests forwarded to TCP clients behind NAT
(e.g. after lookup), ....
regards
klaus
Regards,
Bogdan
Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
Hi, I register a X-Lite (TCP client) and a
Twinkle (UDP client)
behind NAT. I dissable STUN, ICE, keepalive, "discover external
address", etc... in both.
They send a REGISTER to my OpenSer with public IP so I enable
OPTIONS pinging ifor both (I confirm that "location" table has the
same cflags for the you entries and so, all is correct.
But I just see a periodical SIP OPTIONS by UDP for Twinkle. Are
they exist in case of TCP?
Looks like this is a limitation of the natpinging. I would think it
should work with TCP/TLS too (useful to handle clients which close
the TCP connection after some time).
klaus
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
11:01 a.m.
Bogdan-Andrei Iancu wrote:
Right, but is a bit delicate as from routing script
(SIP level) we start
playing with the transport layer :
- first will generate some confusion
we could have default settings which have similar behavior like now.
- it will become more difficult to script down your
configuration.
yes - but it would me allow finetuning
regards
klaus
I was paying some second thoughts to some discussions we had some time
ago, about embedding some automation for some very standard behaviours,
in order to reduce the scripting complexity.....
I will attack this issue during the next week IRC meeting.
Regards,
Bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu schrieb:
Hi Klaus,
I did some test last year with nathelper sending pings over TCP and
it proofed to be non-functional. If the TCP connection is closed
(from client side), the timer process will actually hang trying to
open a TCP connection via NAT....
This brings me to an INO very useful feature request I mentioned some
time ago: For certain kind of scenarios it would be useful to tell
openser to "not open a new TCP connection if there is no existing TCP
connection" - e.g. by having a flag somewhere.
Use cases: natpinging, requests forwarded to TCP clients behind NAT
(e.g. after lookup), ....
regards
klaus
Regards,
Bogdan
Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
> Hi, I register a X-Lite (TCP client) and a Twinkle (UDP client)
> behind NAT. I dissable STUN, ICE, keepalive, "discover external
> address", etc... in both.
>
> They send a REGISTER to my OpenSer with public IP so I enable
> OPTIONS pinging ifor both (I confirm that "location" table has the
> same cflags for the you entries and so, all is correct.
>
> But I just see a periodical SIP OPTIONS by UDP for Twinkle. Are
> they exist in case of TCP?
>
Looks like this is a limitation of the natpinging. I would think it
should work with TCP/TLS too (useful to handle clients which close
the TCP connection after some time).
klaus
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
18 Feb
18 Feb
6:14 a.m.
Hi Klaus,
what about burying all this details in the registrar module (some
automatic behaviour) ? - if nat flag is set and TCP proto, automatically
set the TCP keepalive (if possible), TCP persistence and what ever other
flags....
Regards,
Bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu wrote:
Right, but is a bit delicate as from routing
script (SIP level) we
start playing with the transport layer :
- first will generate some confusion
we could have default settings which have similar behavior like now.
- it will become more difficult to script down
your configuration.
yes - but it would me allow finetuning
regards
klaus
I was paying some second thoughts to some discussions we had some
time ago, about embedding some automation for some very standard
behaviours, in order to reduce the scripting complexity.....
I will attack this issue during the next week IRC meeting.
Regards,
Bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu schrieb:
Hi Klaus,
I did some test last year with nathelper sending pings over TCP and
it proofed to be non-functional. If the TCP connection is closed
(from client side), the timer process will actually hang trying to
open a TCP connection via NAT....
This brings me to an INO very useful feature request I mentioned
some time ago: For certain kind of scenarios it would be useful to
tell openser to "not open a new TCP connection if there is no
existing TCP connection" - e.g. by having a flag somewhere.
Use cases: natpinging, requests forwarded to TCP clients behind NAT
(e.g. after lookup), ....
regards
klaus
Regards,
Bogdan
Klaus Darilion wrote:
> Iñaki Baz Castillo schrieb:
>
>> Hi, I register a X-Lite (TCP client) and a Twinkle (UDP client)
>> behind NAT. I dissable STUN, ICE, keepalive, "discover external
>> address", etc... in both.
>>
>> They send a REGISTER to my OpenSer with public IP so I enable
>> OPTIONS pinging ifor both (I confirm that "location" table has
>> the same cflags for the you entries and so, all is correct.
>>
>> But I just see a periodical SIP OPTIONS by UDP for Twinkle. Are
>> they exist in case of TCP?
>>
>
> Looks like this is a limitation of the natpinging. I would think
> it should work with TCP/TLS too (useful to handle clients which
> close the TCP connection after some time).
>
> klaus
>
> _______________________________________________
> Users mailing list
> Users(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
6:22 a.m.
Bogdan-Andrei Iancu schrieb:
Hi Klaus,
what about burying all this details in the registrar module (some
automatic behaviour) ? - if nat flag is set and TCP proto, automatically
set the TCP keepalive (if possible), TCP persistence and what ever other
flags....
IMO this sounds good - but I think it should be also configurable (to
make everybody happy).
But your idea could also be extended. Do not try to make new TCP
connections if branch is loaded by registrar module and NAT flag is set.
klaus
klaus
Regards,
Bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu wrote:
Right, but is a bit delicate as from routing
script (SIP level) we
start playing with the transport layer :
- first will generate some confusion
we could have default settings which have similar behavior like now.
- it will become more difficult to script down
your configuration.
yes - but it would me allow finetuning
regards
klaus
I was paying some second thoughts to some discussions we had some
time ago, about embedding some automation for some very standard
behaviours, in order to reduce the scripting complexity.....
I will attack this issue during the next week IRC meeting.
Regards,
Bogdan
Klaus Darilion wrote:
Bogdan-Andrei Iancu schrieb:
> Hi Klaus,
>
> I did some test last year with nathelper sending pings over TCP and
> it proofed to be non-functional. If the TCP connection is closed
> (from client side), the timer process will actually hang trying to
> open a TCP connection via NAT....
This brings me to an INO very useful feature request I mentioned
some time ago: For certain kind of scenarios it would be useful to
tell openser to "not open a new TCP connection if there is no
existing TCP connection" - e.g. by having a flag somewhere.
Use cases: natpinging, requests forwarded to TCP clients behind NAT
(e.g. after lookup), ....
regards
klaus
>
> Regards,
> Bogdan
>
> Klaus Darilion wrote:
>> Iñaki Baz Castillo schrieb:
>>
>>> Hi, I register a X-Lite (TCP client) and a Twinkle (UDP client)
>>> behind NAT. I dissable STUN, ICE, keepalive, "discover external
>>> address", etc... in both.
>>>
>>> They send a REGISTER to my OpenSer with public IP so I enable
>>> OPTIONS pinging ifor both (I confirm that "location" table has
>>> the same cflags for the you entries and so, all is correct.
>>>
>>> But I just see a periodical SIP OPTIONS by UDP for Twinkle. Are
>>> they exist in case of TCP?
>>>
>>
>> Looks like this is a limitation of the natpinging. I would think
>> it should work with TCP/TLS too (useful to handle clients which
>> close the TCP connection after some time).
>>
>> klaus
>>
>> _______________________________________________
>> Users mailing list
>> Users(a)lists.openser.org
>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>
>
19 Feb
19 Feb
8:26 a.m.
Hi Juha,
Yes - right - this why I'm thinking on an automatic, integrated
behaviour - I think 99,9% of the users do not want to get into this low
level details, but they still face them.
Regards,
Bogdan
Juha Heinanen wrote:
Klaus Darilion writes:
But your idea could also be extended. Do not try
to make new TCP
connections if branch is loaded by registrar module and NAT flag is
set.
this makes sense too, since such a connection attempt will not succeed.
-- juha
20 Feb
20 Feb
6:15 a.m.
IIRC in ser's trunk TCP code is lot of new OS specific handling - thus
reviewing might be useful
klaus
Bogdan-Andrei Iancu schrieb:
Hi Juha,
Yes - right - this why I'm thinking on an automatic, integrated
behaviour - I think 99,9% of the users do not want to get into this low
level details, but they still face them.
Regards,
Bogdan
Juha Heinanen wrote:
Klaus Darilion writes:
But your idea could also be extended. Do not try
to make new TCP >
connections if branch is loaded by registrar module and NAT
flag is
set.
this makes sense too, since such a connection attempt will not succeed.
-- juha
15 Feb
15 Feb
2:43 p.m.
Bogdan-Andrei Iancu writes:
I was paying some second thoughts to some discussions
we had some time
ago, about embedding some automation for some very standard behaviours,
in order to reduce the scripting complexity.....
I will attack this issue during the next week IRC meeting.
one thing that was considered earlier, was turn on tcp keepalive option
in those OSes (e.g. linux) that support it. it would solve NAT keepalive
issue for those UAs that don't support CRLF keepalive defined in
outbound.
for AUs closing the connection, the best cure is to not use them.
-- juha
18 Feb
18 Feb
6:11 a.m.
Hi Juha,
This will be definitely a better solution as it will be more efficient
from load point of view - the question is how portable (general
supported) is the TCP keepalive setting - this will need some investigation.
Regards,
Bogdan
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
I was paying some second thoughts to some
discussions we had some time
ago, about embedding some automation for some very standard behaviours,
in order to reduce the scripting complexity.....
I will attack this issue during the next week IRC meeting.
one thing that was considered earlier, was turn on tcp keepalive option
in those OSes (e.g. linux) that support it. it would solve NAT keepalive
issue for those UAs that don't support CRLF keepalive defined in
outbound.
for AUs closing the connection, the best cure is to not use them.
-- juha
3:25 p.m.
Bogdan-Andrei Iancu writes:
This will be definitely a better solution as it will
be more efficient
from load point of view - the question is how portable (general
supported) is the TCP keepalive setting - this will need some
investigation.
TCP keepalives are not supported by all all OSes. it should not prevent
using it in those that do.
-- juha
19 Feb
19 Feb
8:28 a.m.
Hi Juha,
I was digging in Stevens, for there were no restriction for setsockopt()
with SO_KEEPALIVE - do you have other info on this topic?
Regards,
Bogdan
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
This will be definitely a better solution as it
will be more efficient
from load point of view - the question is how portable (general
supported) is the TCP keepalive setting - this will need some
investigation.
TCP keepalives are not supported by all all OSes. it should not prevent
using it in those that do.
-- juha
20 Feb
20 Feb
4:04 a.m.
Bogdan-Andrei Iancu writes:
I was digging in Stevens, for there were no
restriction for setsockopt()
with SO_KEEPALIVE - do you have other info on this topic?
bogdan,
i don't remember exactly anymore, but when i was looking into this a
year or so ago, i remember reading somewhere that tcp keepalive option
is not an official part of tcp protocol and that it is not implemented
by all OSes.
-- juha
6087
days inactive
6093
days old
17 comments
5 participants
participants (5)
-
Bogdan-Andrei Iancu -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion