It boils down to the following: For the 'OPTIONS with manipulated via' idea to work, we need to make sure that: a) SER-1 and SER-2 keeps separate location for UACs because symmetric NATs will give you IP:port1 and IP:port2 as NAT ports b) The only way to establish a NAT binding in a symmetric NAT is for the UAC to send a UDP packet to both SER-1 and SER-2, and each SER needs to store this info c) NAT bindings need to be kept open, but each SER can do this for its "own" UACs using nathelper or mediaproxy's ping functionality
- So, if UAC-1 registers with SER-1, SER-1 should send an OPTIONS message to UAC-1 with SER-2 in Via (as noted earlier, if UAC-1 responds to received IP:port, this will not work, but let's assume we can control this). - SER-2 should receive a replication from SER-1 and store the user and location - SER-2 should recognize the OPTIONS message as a location update to the registration and change UAC-1's location in its own database with the received IP:port from UAC-1's message. This should be encapsulated like this: if(method=="OK" && search("detect that this is a location update")) { if(!registered("location")) { reply("Fake!!"); } else { save_noreply("location"); } }
- Of course, the registration on SER-1 must include sending the faked via OPTIONS message to UAC-1. - And, as Juha pointed out, the databases are now out of sync and a server that goes down cannot get the database from another. But unless it is possible to match interface IP with the location for each UAC (so that multiple interface IP/location pairs can be stored), I cannot see a way to get around this.
Anything I have forgotten?
I have been in dialog with the maintainer of IPVS (LVS load scheduler) with regards to a call-id scheduler (similar to F5/Cisco). So far it seems promising, but somebody must implement a UDP scheduler with payload parsing. g-)
Juha Heinanen wrote:
Andreas Granig writes:
If so, it theoretically should work with transparent NAT handling on two SERs too, if both SERs know the external IP/port of UAC-1.
yes, but symmetric nat would not forward packets to uac from the ip address of the other ser even if it sends them to the external ip/port of the uac.
-- juha
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers