18 Feb
2008
18 Feb
'08
1:22 p.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
>>
>