[Serusers] NAT with multiple SERs

[Greger V. Teigre]

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