[Serusers] NAT with multiple SERs

[Greger V. Teigre]

This is exactly the same problem discussed in another thread on load 
balancing and scalability.   Klaus Darilion described a scanario for load 
balancing using ser.  However, we run into the same NAT issues as you have 
discussed in this thread:
http://lists.iptel.org/pipermail/serusers/2005-April/018240.html

One option is to make sure that NAT bindings are open. This will be a hack 
no matter what you do as long as the client does not support using SRV with 
equal weigths as *concurrent*  servers, i.e. the client registers with 
both/all servers. I believe this is not the intention of the spec.

The other option is to always use the SER server where the client registered 
for INVITEs to that client.  Klaus suggested Contact manipulation and 
implementation of the Path header to accomplish this.  The problem is 
(surprise) that such implementation can also be characterized as hacks.  In 
the above thread, I suggested using the following algorithm to simulate Path 
in a registration server (I don't know if it will work...):
<Quote>
record_route();
if(method=="REGISTER") {
    if(src_ip==server1) {
        save("location_server1");  # Does save reply to Contact or to
srcip:port?
    } else if(src_ip==server2) {
        save("location_server2");
    }
    break;
}
if(INVITE for one of our clients) {
    if(lookup("location_server1")){
        t_relay_to_udp("outbound proxy1");
    } else
    if(lookup("location_server")){
        t_relay_to_udp("outbound proxy2");
    } else {
        sl_reply("404", "User not found");
        break;
    }
}

Thus, faking Path by using src_ip and storing the location in different 
tables.
I'm not sure how save() is implemented (where it replies).
</Quote>

Of course, you will still have dependency on a single server for all users 
registered on that server. Thus, you must use a Linux HA type setup (or what 
I would prefer: Let each public IP delivered by _sip SRV by the virtual IP 
of an LVS-based cluster as discussed in the above thread).

Comments?
g-)



Jan Janak wrote:
> This is a hack, but:
>
> You can redirect the REGISTER request to the 2nd server. SER-1
> receives a REGISTER and processes it with save_noreply(). It then
> redirects the REGISTER method to the 2nd server using
> sl_send_reply("301", "Moved Permamently"); The 2nd server will detect
> that the REGISTER has been redirected and will generate 200 OK (a
> parameter in the request-uri could be used for the detection).
>
> If you set the expires to a short value (using max_expires parameter
> of registrar module) than the user agent can keep NAT bindins open to
> both servers.
>
> Note:
>
> 1) The user agent has to support REGISTER/3xx (not all of them do)
> 2) I did not test this.
> 3) It really is a hack.
>
>  Jan.
>
> On 02-05-2005 13:07, Andreas Granig wrote:
>> Juha Heinanen wrote:
>>>  the other option might be to make ser-1 to send an options request
>>>  to uac-1 using ser-2's address in contact.
>>>
>>> should have been "in via header".
>>
>> How would you do this best?
>>
>> Since the source address and the source port have to match SER-1's
>> address, IMHO you can't just use an external script to perform this
>> directly without SER-1, because you can't bind to SER-1's address.
>>
>> If you inject the OPTIONS into SER-1 via FIFO or sipsak/sipp, the
>> request goes thru, but SER-1 adds it's address as topmost Via, so the
>> response always comes back to SER-1 first. Is it possible to suppress
>> the insertion of the own Via-Header?
>>
>> Or even better: is there a way to send the OPTIONS from inside the
>> SER-Config without calling or using external scripts? Don't think so
>> (beside writing a module)...
>>
>> Suggestions?
>>
>> Andy
>>
>> _______________________________________________
>> Serusers mailing list
>> serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers