2 May
2005
2 May
'05
5:57 p.m.
Greger V. Teigre writes:
I like the idea of using OPTIONS. If you find a
way to solve that, it
may 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