On 12/08/2011 06:47 AM, Worley, Dale R (Dale) wrote: >> From: Joegen Baclor [[email protected]] >> >> I am implementing an RLS service that shares load via DNS/SRV records. >> Let us say I have 2 RLS servers sharing the load equally for 200 >> subscribers. In an ideal setting, each would service 100 subscribers >> each. In the moment one goes down, subscribers from the other server >> spills over to the other server. So at one point all 200 subscribers >> are now subscribed to a single server. When the node that went down >> previously goes up, I like to be able to bring back load sharing between >> the two nodes. There seems to be no obvious mechanism to do this in >> SIP. I would appreciate some insights and suggestions. > There are at least two approaches. One approach is to have the RLS > servers split the load on a request-by-request basis, so that they are > jointly the notifyer UA for the subscriptions. This requires that > they share all of the subscription state. When a server sends the 200 > to a subscription-initiating SUBSCRIBE, it inserts a Record-Route > containing a DNS name that resolves to both servers. Thus, each > SUBSCRIBE within the dialogs goes randomly to either of the servers, > and the server that receives the SUBSCRIBE replicates the updated > subscription state to the other server. For any NOTIFY to be > generated, the servers have to decide which of them is to send it, and > update their mutually-held subscription state to record that fact. > This would be rather high-overhead to implement. > > Another approach is to have both servers serve the same data, but any > single subscription is terminated on only one server as notifying UA. > If one server goes down, when a UA whose subscription is notified by > that server decides to re-SUBSCRIBE, it discovers the server is down. > The UA reestablishes a new subscription, which goes to the other > server. When the down server comes up again, the load is unbalanced. > The overloaded server could force some subscriptions to be > reestablished by sending "NOTIFY/Subscription-State: terminated". But > I don't think there's any point in doing that -- of necessity, either > server must be able to handle the full load without degrading the > system. > > Dale >
Thanks Dale. I think you do have a good handle on this being the author of RLS in sipX. I am actually contemplating on option 1 and simply have a static algorithm in the proxy to somehow control the balancing based on realtime load of each RLS server. I am indeed tempted to resort to simply use the 3265's Notify with state "terminated" and hope that the UAC is compliant and re-establish the dialog but having to rely on "UAC's" compliance almost always guaranty an interoperability issue. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
