Hi, 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) ? 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).... Any comments on this will be appreciated. Thanks and regards, Bogdan _______________________________________________ Devel mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
