Hello,
I was wondering if it is necessary for a SIP packet from a specific call to always go through the same server?
For instance, if you have a load balancer distributing requests over a few servers, it is possible that an INVITE ends up on 1 server while the following INVITE with the credentials ends up on another, would this be a problem (ie, break the authorization) or should you use a SIP aware loadbalancer for this (who looks at the callid for example)? Assuming the ser servers are setup to use the same userdatabase (and t_replicate to eachother) the picture would be something like this:
| -------------- |loadbalancer| -------------- | | -------------------- | | | ------- ------- ------- | | | | | | | ser1| | ser2| | ser3| | | | | | | ------- ------- -------
If you setup the servers with the same IP as the load balancer and stop them from replying to ARP requests for that IP, replying back thru a NAT should not be a problem.
Just thinking out loud, I could use SER for the load balancing and t_relay the packets, however that would require some tampering with the VIA records (and I should use a reply to via in that case to the original IP the SIP request came from, eg not the load balancer) this way outgoing SIP traffic would not have to go thru the ser loadbalancer again to get out, hmm, it might even be possible to use a route-record header to get the packets back at the correct server...
Kind regards,
E. Versaevel
Hi Erik!
Another easy way for loadblancing ist the usage of SRV records for the SIP domain.
And there are a lot of other problems: - caching of the contacts of the registered clients (use t_replicate) - NAT traversal: doesn't work that easy with multiple proxies with multiple IP addresses. - ...
search in the mailinglist archive - there are already several threads on this topic.
regards, klaus
E. Versaevel wrote:
Hello,
I was wondering if it is necessary for a SIP packet from a specific call to always go through the same server?
For instance, if you have a load balancer distributing requests over a few servers, it is possible that an INVITE ends up on 1 server while the following INVITE with the credentials ends up on another, would this be a problem (ie, break the authorization) or should you use a SIP aware loadbalancer for this (who looks at the callid for example)? Assuming the ser servers are setup to use the same userdatabase (and t_replicate to eachother) the picture would be something like this:
| -------------- |loadbalancer| -------------- | | -------------------- | | |
| | | | | | | ser1| | ser2| | ser3| | | | | | |
If you setup the servers with the same IP as the load balancer and stop them from replying to ARP requests for that IP, replying back thru a NAT should not be a problem.
Just thinking out loud, I could use SER for the load balancing and t_relay the packets, however that would require some tampering with the VIA records (and I should use a reply to via in that case to the original IP the SIP request came from, eg not the load balancer) this way outgoing SIP traffic would not have to go thru the ser loadbalancer again to get out, hmm, it might even be possible to use a route-record header to get the packets back at the correct server...
Kind regards,
E. Versaevel
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi,
Klaus Darilion wrote:
- caching of the contacts of the registered clients (use t_replicate)
How do you solve the problem if one SER goes down and thus can't receive replicated contacts from the other SER? Especially if you use the delayed writeback mechanism of usrloc for performance reasons or if you use dedicated databases for each SER for high availability reasons?
Andy
To bad not every UA supports _SRV lookups, so round robin is not exactly what I'm looking for. NAT Traversal is a bit of a problem with multiple IP addresses, however, if you use direct routing (and have all the boxes in the cluster reply from the same IP) there shouldn't be a problem.
Spreading the contacts can be done with t_replicate (and flushing the database often enough) so that if a ser hosts goes down the contacts are already in the database, which is loaded at a restart.
This could actually work I think, I may have a test environment available today so I might test this :)
Kind regards,
E. Versaevel
-----Oorspronkelijk bericht----- Van: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Verzonden: woensdag 1 december 2004 21:32 Aan: E. Versaevel CC: serusers@lists.iptel.org Onderwerp: Re: [Serusers] Loadbalancing / high availability
Hi Erik!
Another easy way for loadblancing ist the usage of SRV records for the SIP domain.
And there are a lot of other problems: - caching of the contacts of the registered clients (use t_replicate) - NAT traversal: doesn't work that easy with multiple proxies with multiple IP addresses. - ...
search in the mailinglist archive - there are already several threads on this topic.
regards, klaus
E. Versaevel wrote:
Hello,
I was wondering if it is necessary for a SIP packet from a specific call
to
always go through the same server?
For instance, if you have a load balancer distributing requests over a few servers, it is possible that an INVITE ends up on 1 server while the following INVITE with the credentials ends up on another, would this be a problem (ie, break the authorization) or should you use a SIP aware loadbalancer for this (who looks at the callid for example)? Assuming the ser servers are setup to use the same userdatabase (and t_replicate to eachother) the picture would be something like this:
| -------------- |loadbalancer| -------------- | | -------------------- | | |
| | | | | | | ser1| | ser2| | ser3| | | | | | |
If you setup the servers with the same IP as the load balancer and stop
them
from replying to ARP requests for that IP, replying back thru a NAT should not be a problem.
Just thinking out loud, I could use SER for the load balancing and t_relay the packets, however that would require some tampering with the VIA
records
(and I should use a reply to via in that case to the original IP the SIP request came from, eg not the load balancer) this way outgoing SIP traffic would not have to go thru the ser loadbalancer again to get out, hmm, it might even be possible to use a route-record header to get the packets
back
at the correct server...
Kind regards,
E. Versaevel
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Andreas Granig -
E. Versaevel -
Klaus Darilion