[OpenSIPS-Devel] [OpenSIPS-Users] [RFC] NAT pinging

[Bogdan-Andrei Iancu]

Hi Jesus,

Jesus Rodriguez wrote:
> Hi Bogdan,
>
>> I was evaluating an implementation for NAT pinging also via TCP
>> connection, but I just diging in the current pinging "logic" I found
>> some issues that needs to be sorted out first.
>>
>> So, let's start from the presumption you do NAT pinging only for NAT
>> traversal cases :).
>>
>> The issues I found are:
>>
>>
>> A) contact info versus network info
>>
>> When considering a REGISTER request, you have two sets of information: I
>> - registered contact ; II - network info (source IP/port, proto, local
>> socket where the request was received on).
>> When comes to determine the destination for pinging, right now, the
>> logic uses the network info (as more or less NAT at network level).
>> But, according to RFC 3261, the REGISTER request may carry whatever
>> contact, like a REGISTER via UDP may register a contact for TCP (or
>> vice-versa). In case of NAT, this will not work at all (as we assume
>> that the source of REGISTER and registered contact point to the same
>> network location).
>>
>> So, the question is:  if NAT detected and such a protocol mismatch is
>> detected, should a registrar refuse the registration (as it will be
>> anyhow unusable) ?
>
>
> Maybe this could be a configurable policy via modparam for regristrar 
> module. If the script writer does not want to take care of these 
> "strange" cases, registrar module can refuse these  requests 
> automatically... but in some cases you may want/need to accept these 
> requests, so a configurable behavior would be great.
>
yes, this is an option, but the problem with adding too many cfg options 
for a module is that the module will become difficult to use and 
understand. But, of course, even with a large set of params, we can have 
them set to some default values (that covers most of the cases) and let 
only for the "geeks" to actual pleasure of playing with the low level 
parameters.
>
>
>> B) PATH extension
>>
>> First of all if PATH is used and simply UDP ping is used, nathelper
>> pings the source of the REGISTER (where it came from).
>> Question: does this make sense? as anyhow the INVITEs will be sent to
>> the top PATH uri....
>>
>> Now, when using PATH, the source of the REGISTER and the pinged
>> destination (the top most PATH uri) may be different things (case - last
>> hop for the REGISTER request didn't add path); from TCP point of view,
>> if we do not allow opening *new* tcp connection for ping purposes, it
>> will be impossible to do the ping (as there is no guarantee to have an
>> already opened tcp connection to the destination pointed by the top most
>> PATH uri)....
>
>
> But, anyway, you can not open new TCP connections to the UA behind 
> NAT... the already opened connection where the REGISTER arrived should 
> be kept alive.
yes, this is the idea - if you decide to do ping via TCP, you do it only 
if you have an existing TCP connection. Otherwise you just don't do it.

And here is the problem with PATH headers - you may have the REGISTER 
coming from server C, but the top PATH uri (where to send traffic) is 
server B (server C didn't do PATH insertion). In this case you have a 
kind of asymmetric communication, so you cannot reuse the TCP connection 
for the REGISTER.

Salutari,
Bogdan