2 May
2005
2 May
'05
3:18 p.m.
Andreas Granig wrote:
Greger V. Teigre wrote:
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...
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. 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-)