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-)