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

[Jesus Rodriguez]

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.



> 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.


Saludos
JesusR.

------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr at voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------