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 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
El Friday 15 February 2008 11:01:02 Klaus Darilion escribió:
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).
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 schrieb:
El Friday 15 February 2008 11:01:02 Klaus Darilion escribió:
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).
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."
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 ....:-)
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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
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
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
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
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
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
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
-
Bogdan-Andrei Iancu -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion