On separate occasions.   The brocade load balancers have the option to be 
"sticky" - ie all follow on requests go to the same sbc.

For the brocades they were placed topology wise in front of the SBCs so that 
all requests and replies cross the load balancer.  You can do this by having 
the load balancer be the default gateway for the SBC's.     It was pretty 
simple at least for the brocade configuration.  Note that RTP traffic was not 
load balanced of course.

I will see if I can find my notes on the kamailio config.    Used the dispatch 
module if I remember correctly.  I will try and find them as its been awhile.

Joseph




From: Sykes, Aaron [mailto:[email protected]]
Sent: Tuesday, April 19, 2016 6:00 PM
To: Joseph Jackson; [email protected]
Subject: RE: Load balancing SIP

Did you use these devices for this purpose on separate occasions or in unison?  
 How many SBCs were being used in the distribution?  Can you elaborate on the 
basic topology?

Aaron

From: Joseph Jackson [mailto:[email protected]]
Sent: Tuesday, April 19, 2016 2:34 PM
To: Sykes, Aaron <[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>
Subject: RE: Load balancing SIP

Ive done it with Brocade and Kamailio.



From: VoiceOps [mailto:[email protected]] On Behalf Of Sykes, Aaron
Sent: Tuesday, April 19, 2016 4:32 PM
To: [email protected]<mailto:[email protected]>
Subject: [VoiceOps] Load balancing SIP

Has anyone had any success load balancing SIP?  More specifically distributing 
SIP registrations across a number of access SBCs and maintaining persistence 
based on source IP.  By maintaining source IP persistence subsequent calls 
would go to the SBC to which they are registered.  In this case each of several 
SBCs cache registrations  for a single SIP registrar.     Has anyone used F5 or 
Kamailio for this..or some other SIP proxy or load balancer?

Thank You,
Aaron



________________________________
This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, notify the sender immediately by return email and delete the message 
and any attachments from your system.
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops

Reply via email to