Greger V. Teigre writes:
I like the idea of using OPTIONS. If you find a way to solve that, itmay very well become a best practice. However, you need to make sure the NAT binding is open before you send the INVITE from SER-2, so you either have to continously send OPTIONS to all your clients or you have to make sure that SER-1 sends the OPTIONS right before you send the INVITE from SER-2, which brings you full circle: you're reliant on SER-1...
assuming that somehow nat binding has been opened from the sip ua to ser-2, ser-2 will automatically keep that binding open by sending the small udp packets like it does for all clients behind nat. so you don't need to keep on sending options or relying on ser-1 once ser-2 has got access to the sip ua.
but may the options hack will not work at all even if we could hack the via header, because options reply from the sip ua to ser-2 would not necessarily come from the same source port as the register request to ser-1. my understanding is that in case of symmetric nats, each src ip/dst ip pair gets mapped by the nat to different source ports.
so ser-2 should somehow know to listed for the options reply even if it didn't send the options request and then change the destination port in its memory based location table for that sip ua. this hack would be mother of all hacks.
Maybe an extension to nathelper would be the way to go? Maxim added support for sending different types of SIP messages instead of an empty UDP. An extension to nathelper could take a flat file with IPs of your other servers and send a series of OPTIONS messages instead of one. I have no idea how this will impact the load on the server though.
sending the options request could be done one way or another, but see above.
-- juha