Typically load balancing in SIP is done on call-id but some implementations have used multiple SIP header fields in the past. There are several SIP aware load balancer implementations you can look at. Hash will definitely not work in your case.
Also another interesting aspect is what you mention about REGISTER and INVITE going to the same node. Since both these are separate transactions - they will not have same call-id field, you may want to look for Request-URI in INVITE and To-URI in REGISTER for diverting calls to the right node internally. Although this can be done, this could have issues of uneven load balancing. The correct design approach in my opinion is for you to have a database-sync mechanism among your nodes rather than diverting traffic based on user profiles. The load balancing can then be done based on call-id in a traditional manner with no issues. Do you mind if I ask what SIP application expects 2/3 million hits in an hour? Shashi --- The Rev <[EMAIL PROTECTED]> wrote: > Hi, > > Thanx for the help. Unfortuantely the problem a little bit complicated. I'm > designing a kind of box which is more like a B2BUA. When somebody register > the box downloads the profile of subscriber which contains subscription > information/ user settings for call forwarding, usename password etc. > > This box should have high performance (2-3 million INVITE/hour). THis is why > it has distributed architecture internaly which means that it contains > several comuter "node". Each node is a registrar and a B2BUA. The aim is > that the user sees this as one box. > > When the user sends a register we should find a node and all the other > register and invite should be sent to that node. One solution if the > register is always sent to a ditributor and the ditributor selects a node > and register is forwarded to the goven node. But invite should be sent to > the given box directly to avoid the bottleneck in the distributor. > > There are several solutions like: > - hasing IP address user (unfortunatly IP can be changed) > - hashing Request URI -> if one node dies all a new one is inserted the > others should be restarted > - using Service-ROute header which was forced by 3gpp due to the same reason > as above > etc, > > Unfortunatly most of the user agents has only one configurable "server" > parameter which covers both the registrar and outbound proxy :-( and no > differentiation can be made. > > DNS cannot be used because it would be possible that the REGISTER and > INVITEs go to different node. > > br > Andrew > > > >From: [EMAIL PROTECTED] > >To: "The Rev" <[EMAIL PROTECTED]> > >CC: [EMAIL PROTECTED], > >[EMAIL PROTECTED] > >Subject: Re: [Sip-implementors] How to force the UA during registration to > > send the INVITE to a different addres > >Date: Mon, 17 May 2004 06:31:25 +1000 > > > >Andrew, > > I may be missing something and am not clear in the way you have > >described this; > > > >"To be able to do some controlled load balancing I would like to force the > >UA > >in the 200OK during registration to send the INVITE to a differrent IP > >address". > > > > > > I think you are asking about sending outgoing INVITEs from a UA to > >a > >different address than that used for registrations and then at multiple > >address for load balancing. The Registrar and Proxy are two logical roles > >that can be performed on different physical boxes, a UA will use any of > >the ways for discovering a registrar in 3261 and may have a different > >address configured for it's outgoing proxy. I do not think you want to > >return a contact address that is just 'different' to the one used in the > >initial INVITE, but want to return multiple contacts both able to process > >the INVITE and perhaps keep state information across them - otherwise it > >wouldn't be load balancing but like a redirection. > > > > Using a DNS entry for the outgoing proxy and in the returned > >contact field to INVITEs to the Proxy is sufficient to do this, you can > >ensure that the DNS method of return for the record is cyclic for load > >balancing puposes - although considerations need to be given for this if > >they span WAN sites etc, you may not want half your outgoing INVITEs to > >cross the country for processing. A DNS entry for an outgoing Proxy > >address (round robin / cyclic returned) will give you load balancing for > >outgoing requests, if the state information is held across the two Proxies > >then the same address can be returned in the contact field to provide in > >dialog failover. > > > > Let us know if this is not in the ball park. > > > >Regards, > > > >Wayne Davies > > > > > > > > > > > >"The Rev" <[EMAIL PROTECTED]> > >Sent by: [EMAIL PROTECTED] > >14/05/2004 05:36 PM > > > > > > To: [EMAIL PROTECTED] > > cc: > > Subject: [Sip-implementors] How to force the UA during > >registration to send the > >INVITE to a different addres > > > > > >HI, > > > >I'm designing a distributed registrar and sip proxy where the load > >balancing > >is a major issue. > >To be able to do some controlled load balancing I would like to force the > >UA > >in the 200OK during registration to send the INVITE to a differrent IP > >address. How can I do this? As I know for this purpose the Service-ROute > >was > >introduced but I doubt that I will find a commercial UA which supports it. > > > >br > >Andrew > > > >_________________________________________________________________ > >Protect your PC - get McAfee.com VirusScan Online > >http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > > >_______________________________________________ > >Sip-implementors mailing list > >[EMAIL PROTECTED] > >http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > > > > >****************************************************************************** > > - NOTICE FROM DIMENSION DATA AUSTRALIA > >This message is confidential, and may contain proprietary or legally > >privileged information. If you have received this email in error, please > >notify the sender and delete it immediately. > > > >Internet communications are not secure. You should scan this message and > >any attachments for viruses. Under no circumstances do we accept liability > >for any loss or damage which may result from your receipt of this message > >or any attachments. > >****************************************************************************** > > > > _________________________________________________________________ > FREE pop-up blocking with the new MSN Toolbar � get it now! > http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ===== ---- Shashi's DID YOU KNOW: Please participate in the "Gifts program" of CRY and teach your child the art of sharing when they are young. http://www.sjce.net/cryrdu/projects/birthday/index.html ---- __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
