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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers