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