Rolf, The DNS round-robin approach has some serious issues. Let me explain. I did a project that required load balancing among 60 sip servers from one SER front end. Each server was designed with a balance point of about 100 calls per server. The fullly loaded capacity was thousands of simultaneous calls running through the SER. By design, a few of the remote SIP gateways had lower call-capacity.. A couple of years ago when first deployed, I put a flat round-robin list of remote sip IPs into the edge-access SER. Worked quite well. Except that when we had wide variations in call duration times, the actual loads on the gateway was skewed. Some gateways were carrying 200+ calls while others were carrying only 75 calls when they had the same call capacity. The load balance skew was due to flat list (either random or round-robin). I needed actual capacity and current load information on a per-gateway basis. Because Asterisk was used for the remote sip servers, it was fairly easy to poll each gateway on a recurring cycle to determine how many calls were active. We also knew the exact capacities for all of the gateways. The fun work came when we integrated an intelligent feed-back loop into SER. The key statements that is used in ser.cfg are as follows: $remote_gwip = "xx.yy.xx.nn" ; # Set attr to next IP in list of IPs $attr2uri( "$remote_gwip" , "domain"); if (!trelay()) { sl_reply_error(); } These statements & techniques are well known from several public SER.cfg examples. At first, a simple random hash on the orignation/destination numbers was used to select the gateways in IF-THEN-ELSE code logic. This spread the load nicely over a small number of IPs. For the next version, we used a simple DOMAIN attribute to contain the list of IPs and and capacity for a larger number of IPs. Later, a separate MYSQL updates and query() was used to manage the capacity-sensitive list of IPs and the current-load feedback information. So far, all of this work is private. I am now writing yet another SER module to put all of this inside the SER in order to keep all the load related feed-back information in shared memory for highest performance and to run without any DB at all in SER. When I get it completed, I plan to submit a version of the module as a candidate for the SER Out-Of-Box sub-project. I hope this gives you more ideal on how to get load balancing with a per-server feed-back information loop. Regards, ..mike.. At 07:38 AM 4/22/2008, Rolf Unger wrote: