Why does NAT keepalive only work for UDP?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Why does NAT keepalive only work for UDP?

Iñaki Baz Castillo
Hi, I wonder why SIP keepalive method (sending a NOTIFY/OPTIONS perdiodically)
just works for UDP, this is: why the request is not sent via TCP?

For example: new nat_traversal module is very flexible, allow mantaining the
NAT open even if the caller is not registered, but the fact is that if the
client uses TCP (*and it's not registered*), then "nat_keepalive()" method
does nothing.

We have "tcp_persistent_flag" in registrar module, but this is just valid for
REGISTER (so what about all the features and flexibility of "nat_traversal"
module?), and also note that many devices close, by themself, the TCP
connection after 64*T1 = 32 seconds, even if the server didn't close it.

So again, I wonder why OPTIONS/NOTIFY is not sent via TCP while this would be
the *unique* way to mantain a TCP connection open when NAT exists.

BTW I would like to know how "tcp_persistent_flag" is supposed to work. I read
in the documentation:
  "the module, via the “save()” functions will set the lifetime of the TCP
   connection to the contact expire value. By doing this, the TCP connection
   will stay on as long as the contact is valid."

So I understand that the server doesn't close the connection before
registration expires, but how can the client know it? why would a client
mantain the TCP connection open until "expires" time? why to expect it?
For example, Twinkle closes the TCP connection by itself after 32 seconds.

PD: I know the PingPong TCP keepalive method, but it has nothing to do with
the above, and also, it only works for *registered* clients.

Thanks a lot.

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Why does NAT keepalive only work for UDP?

Klaus Darilion


Iñaki Baz Castillo schrieb:

> Hi, I wonder why SIP keepalive method (sending a NOTIFY/OPTIONS perdiodically)
> just works for UDP, this is: why the request is not sent via TCP?
>
> For example: new nat_traversal module is very flexible, allow mantaining the
> NAT open even if the caller is not registered, but the fact is that if the
> client uses TCP (*and it's not registered*), then "nat_keepalive()" method
> does nothing.
>
> We have "tcp_persistent_flag" in registrar module, but this is just valid for
> REGISTER (so what about all the features and flexibility of "nat_traversal"
> module?), and also note that many devices close, by themself, the TCP
> connection after 64*T1 = 32 seconds, even if the server didn't close it.
>
> So again, I wonder why OPTIONS/NOTIFY is not sent via TCP while this would be
> the *unique* way to mantain a TCP connection open when NAT exists.
>
> BTW I would like to know how "tcp_persistent_flag" is supposed to work. I read
> in the documentation:
>   "the module, via the “save()” functions will set the lifetime of the TCP
>    connection to the contact expire value. By doing this, the TCP connection
>    will stay on as long as the contact is valid."
>
> So I understand that the server doesn't close the connection before
> registration expires, but how can the client know it? why would a client
> mantain the TCP connection open until "expires" time? why to expect it?

Because it is the only way the receive messages if the client is behind
NAT. Have you ever called a hotline? Never hang up because they wont
call you back - the same with SIP. If you are behind NAT there is no way
for the server to make a TCP connection to the client. So, if the client
is behind NAT and tears down the TCP connection it is a damn stupid client.

> For example, Twinkle closes the TCP connection by itself after 32 seconds.

Report it.

regards
klaus



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Why does NAT keepalive only work for UDP?

Dan Pascu
In reply to this post by Iñaki Baz Castillo

Man, you have a lot of questions today... :P

On Wednesday 12 November 2008, Iñaki Baz Castillo wrote:
> Hi, I wonder why SIP keepalive method (sending a NOTIFY/OPTIONS
> perdiodically) just works for UDP, this is: why the request is not sent
> via TCP?

Mainly I guess it's because nobody did implement it, as none had a need
for it yet? Add to that that the TCP stack is handled differently (inside
opensips) and it's a complex beast which is not easy to tap into as it is
with UDP. Also, I guess historical reasons was also a factor as it was
meant as an improved replacement for the (UDP only) solutions in the
nathelper and mediaproxy modules (which it is). While being improved it
doesn't imply it has to be perfect, so if you need TCP support, you are
wellcome to implement it and share it with us ;)

--
Dan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Why does NAT keepalive only work for UDP?

Iñaki Baz Castillo
In reply to this post by Klaus Darilion
2008/11/12 Klaus Darilion <[hidden email]>:

>> So I understand that the server doesn't close the connection before
>> registration expires, but how can the client know it? why would a client
>> mantain the TCP connection open until "expires" time? why to expect it?
>
> Because it is the only way the receive messages if the client is behind NAT.

Yes, but where is specified (I mean before outbound draft) that the
caller must mantain the TCP connection open?
Yes, it makes sense but...


> If you are behind NAT there is no way for the
> server to make a TCP connection to the client. So, if the client is behind
> NAT and tears down the TCP connection it is a damn stupid client.

Sure, but anyway, why the server/proxy couldn't send periodical
NOTIFY/OPTIONS to mantain NAT open (in case the clients doesn't it)?
Well, if we think in UDP, a client could also send periodical
NOTIFY/OPTIONS to the server to mantain the "connection" open (but
it's not very usual), why a client should care about it just in case
of using TCP?


Regards.


--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Why does NAT keepalive only work for UDP?

Klaus Darilion
In reply to this post by Dan Pascu


Dan Pascu schrieb:

> Man, you have a lot of questions today... :P
>
> On Wednesday 12 November 2008, Iñaki Baz Castillo wrote:
>> Hi, I wonder why SIP keepalive method (sending a NOTIFY/OPTIONS
>> perdiodically) just works for UDP, this is: why the request is not sent
>> via TCP?
>
> Mainly I guess it's because nobody did implement it, as none had a need
> for it yet? Add to that that the TCP stack is handled differently (inside
> opensips) and it's a complex beast which is not easy to tap into as it is
> with UDP. Also, I guess historical reasons was also a factor as it was
> meant as an improved replacement for the (UDP only) solutions in the
> nathelper and mediaproxy modules (which it is). While being improved it
> doesn't imply it has to be perfect, so if you need TCP support, you are
> wellcome to implement it and share it with us ;)

and make it non-blocking ;-)


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Why does NAT keepalive only work for UDP?

Klaus Darilion
In reply to this post by Iñaki Baz Castillo


Iñaki Baz Castillo schrieb:

> 2008/11/12 Klaus Darilion <[hidden email]>:
>
>>> So I understand that the server doesn't close the connection before
>>> registration expires, but how can the client know it? why would a client
>>> mantain the TCP connection open until "expires" time? why to expect it?
>> Because it is the only way the receive messages if the client is behind NAT.
>
> Yes, but where is specified (I mean before outbound draft) that the
> caller must mantain the TCP connection open?
> Yes, it makes sense but...

Where is specified that you should not jump on the street if a truck is
coming? :-)

Yes, you are right this is not specified in core SIP RFCs - but it is
the only way so the specification is not needed at all.

>> If you are behind NAT there is no way for the
>> server to make a TCP connection to the client. So, if the client is behind
>> NAT and tears down the TCP connection it is a damn stupid client.
>
> Sure, but anyway, why the server/proxy couldn't send periodical
> NOTIFY/OPTIONS to mantain NAT open (in case the clients doesn't it)?

Yes, it can, and it would be a workaround if client does not send CLRF
or support  PING/PONG.

> Well, if we think in UDP, a client could also send periodical
> NOTIFY/OPTIONS to the server to mantain the "connection" open (but
> it's not very usual), why a client should care about it just in case
> of using TCP?

Smart clients send CRLF anyway, regardless of the protocol. You could
also trigger short reREGISTERs intervals for TCP clients.

klaus

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Why does NAT keepalive only work for UDP?

Bogdan-Andrei Iancu
Hi Klaus,

Klaus Darilion wrote:

> Iñaki Baz Castillo schrieb:
>  
>> Well, if we think in UDP, a client could also send periodical
>> NOTIFY/OPTIONS to the server to mantain the "connection" open (but
>> it's not very usual), why a client should care about it just in case
>> of using TCP?
>>    
>
> Smart clients send CRLF anyway, regardless of the protocol. You could
> also trigger short reREGISTERs intervals for TCP clients.
>
>  
IMO, abusing REGISTER just for the nat traversal purposes is the worst
you can do for your system. Registration is a very "expensive" service -
you need authentication, security checks and finally DB impact. And you
will add all this burn on your system just to keep a NAT open. Why not
using dedicated mechanism, very light ones, that will have small impact
on your system (like SIP ping is just about sending and receiving
messages, no other costly ops involved)

Regards,
Bogdan


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Why does NAT keepalive only work for UDP?

Bogdan-Andrei Iancu
In reply to this post by Klaus Darilion
Klaus Darilion wrote:

> Dan Pascu schrieb:
>  
>> Man, you have a lot of questions today... :P
>>
>> On Wednesday 12 November 2008, Iñaki Baz Castillo wrote:
>>    
>>> Hi, I wonder why SIP keepalive method (sending a NOTIFY/OPTIONS
>>> perdiodically) just works for UDP, this is: why the request is not sent
>>> via TCP?
>>>      
>> Mainly I guess it's because nobody did implement it, as none had a need
>> for it yet? Add to that that the TCP stack is handled differently (inside
>> opensips) and it's a complex beast which is not easy to tap into as it is
>> with UDP. Also, I guess historical reasons was also a factor as it was
>> meant as an improved replacement for the (UDP only) solutions in the
>> nathelper and mediaproxy modules (which it is). While being improved it
>> doesn't imply it has to be perfect, so if you need TCP support, you are
>> wellcome to implement it and share it with us ;)
>>    
>
> and make it non-blocking ;-)
>  

Well, this is not difficult to do :) - because you do TCP connection
re-usage and avoid opening and searching for TCP conns.

I think the question is not from technical point of view, but more a
logical one. Like known issues not to do TCP ping; does TCP ping may
help after all? how TCP ping and TCP keepalive work?

Regards,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Why does NAT keepalive only work for UDP?

Iñaki Baz Castillo
In reply to this post by Bogdan-Andrei Iancu
El Lunes, 15 de Diciembre de 2008, Bogdan-Andrei Iancu escribió:
> IMO, abusing REGISTER just for the nat traversal purposes is the worst
> you can do for your system. Registration is a very "expensive" service -
> you need authentication, security checks and finally DB impact. And you
> will add all this burn on your system just to keep a NAT open. Why not
> using dedicated mechanism, very light ones, that will have small impact
> on your system (like SIP ping is just about sending and receiving
> messages, no other costly ops involved)

Agree. For example Linksys phones can send a NOTIFY ("Event: keep-alive")
periodically tomantain NAT open, in UDP or TCP.

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Why does NAT keepalive only work for UDP?

Klaus Darilion
In reply to this post by Bogdan-Andrei Iancu


Bogdan-Andrei Iancu wrote:

> Klaus Darilion wrote:
>> Dan Pascu schrieb:
>>  
>>> Man, you have a lot of questions today... :P
>>>
>>> On Wednesday 12 November 2008, Iñaki Baz Castillo wrote:
>>>    
>>>> Hi, I wonder why SIP keepalive method (sending a NOTIFY/OPTIONS
>>>> perdiodically) just works for UDP, this is: why the request is not sent
>>>> via TCP?
>>>>      
>>> Mainly I guess it's because nobody did implement it, as none had a
>>> need for it yet? Add to that that the TCP stack is handled
>>> differently (inside opensips) and it's a complex beast which is not
>>> easy to tap into as it is with UDP. Also, I guess historical reasons
>>> was also a factor as it was meant as an improved replacement for the
>>> (UDP only) solutions in the nathelper and mediaproxy modules (which
>>> it is). While being improved it doesn't imply it has to be perfect,
>>> so if you need TCP support, you are wellcome to implement it and
>>> share it with us ;)
>>>    
>>
>> and make it non-blocking ;-)
>>  
>
> Well, this is not difficult to do :) - because you do TCP connection
> re-usage and avoid opening and searching for TCP conns.

I thought also TCP sending is synchronous.

regards
klaus

>
> I think the question is not from technical point of view, but more a
> logical one. Like known issues not to do TCP ping; does TCP ping may
> help after all? how TCP ping and TCP keepalive work?
>
> Regards,
> Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Why does NAT keepalive only work for UDP?

Iñaki Baz Castillo
In reply to this post by Bogdan-Andrei Iancu
El Lunes, 15 de Diciembre de 2008, Bogdan-Andrei Iancu escribió:
> I think the question is not from technical point of view, but more a
> logical one. Like known issues not to do TCP ping; does TCP ping may
> help after all? how TCP ping and TCP keepalive work?

For me there is no different with UDP:

UDP)
- Alice sends a UDP registration.
- Alice is pinged via UDP with OPTIONS/NOTIFY from OpenSips using the existing
UDP """connection""".
- If the ping doesn't arrive in a predefined interval then alice is
considered "unreachable" and the ping is not sent anymore (not sure if
OpenSips implements it, maybe the nat_traversal module does it?).

TCP)
- Alice sends a TCP registration, so there si a TCP connection with alice.
- Alice is pinged via TCP with OPTIONS/NOTIFY from OpenSips using that
connection.
- If the ping fails due to TCP error (or TCP timeout) then alice is
considered "unreachable" and the ping is not sent anymore.


At the end, I see no difference between two cases (perhaps TCP is more complex
due to connections pool and so, but the concept is similar). Also, if
OpenSIPS receives a notification from the transport layer telling that a TCP
connection has been ended, then it could in that moment destroy any existing
pinging process over that connection. Is not feasible?

Regards.


--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users