[Serusers] NAT with multiple SERs

Greger V. Teigre greger at teigre.com
Mon May 2 15:18:50 CEST 2005


Andreas Granig wrote:
> Greger V. Teigre wrote:
>> 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.
>
> I've already thought about rewriting the Contact-Header with the
> address of the currently processing SER before replicating it, to
> force all calls via the same SER. But this solution will work around
> the redundancy won by using SRV, so it would be useless to use SRV
> anyway.

Yes, I agree. IP-based services are often loosely coupled, making it easier 
to create redundancy and scalability. The NAT-problem makes a tight 
coupling...

> And I also want to avoid load balancers, heartbeat and other standby
> solutions.

:-) well, I don't like standby solutions either, but I like some of the 
characteristics of load balancing.  If you have two data centers (using SRV 
to load balance/make redundancy on the client side), and each data center is 
a small LVS cluster, it is very easy to add servers to increase capacity. 
Anyway, it's just two different ways of achieving the same thing.  However, 
SRV is not supported in all clients, so no matter where you turn there's a 
downside...
    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...
    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.

g-) 




More information about the sr-users mailing list