[OpenSIPS-Users] Input on my loadbalancer configuration

[Bogdan-Andrei Iancu]

Hi Geoff,

OpenSIPs is by default only transaction stateful, so it does matter how 
many concurrent calls you have. What matter is the setup and tire-down 
capacity (like how many calls per second can be established and 
terminated). In pure relay mode, you can go up to 10K calls per second 
(as setup). Of course you will get less because you have some extra 
logic (like dispatching, etc).

Regards,
Bogdan


geoffreymina at gmail.com wrote:
> Bogdan (and list),
> Again, thank you very much for taking the time to answer my questions. 
> It is people like you that enable the open source community to thrive 
> and grow. I really appreciate your efforts.
>
> I have gone through and made your suggested changes and things seem to 
> be working quite well for what I am trying to accomplish.
>
> My last and final question to the group (for now ;)... how do you 
> determine the dimensions of an OpenSIPS deployment? I am going to be 
> running two of these systems with automatic failover. They will be 
> running on Dell 1950 with 8 cores of CPU (2.0Ghz) and 8G or RAM on 
> CentOS x_86/64. OpenSIPS is the only extra process running on the 
> systems. Will this configuration handle 1,000 concurrent calls, 10,000 
> concurrent calls, etc? Will my limits be in Call Setups Per Second? 
> How does one go about estimating the capacity of OpenSIPS?
>
>
>
> Thanks,
> Geoff
>
> On Nov 13, 2008 5:02am, Bogdan-Andrei Iancu <bogdan at voice-system.ro> 
> wrote:
> > Hi Geoff,
> >
> >
> >
> >
> >
> > geoffreymina at gmail.com wrote:
> >
> >
> >
> >
> > Thank you very much for taking the time to look over my 
> configuration. I just want to make sure of something. I replied to my 
> own original message with a greatly enhanced configuration. I realized 
> the first was missing a huge amount of logic after studying up on 
> OpenSIPS for 2 days. Were you commenting on the original message, or 
> the second message? Based on my testing, i experienced slightly 
> different results than you described.
> >
> >
> >
> >
> > My comments were generally speaking (for a LB topic) and not 
> strictly in regards to a particular script.
> >
> >
> >
> >
> >
> >
> >
> > What I am seeing (based on the second config) is that only the 
> initial INVITE falls into the route(1) block, which is the way I 
> intended it. This means only the INVITE requests are routed via the 
> ds_select_dst() call to the dispatcher. All subsequent messages fall 
> into my loose_route() check and are simply relayed via t_relay().
> >
> >
> >
> >
> > yes, because you still so record_route() - if you remove this, you 
> will process only the initial INVITEs - the ACK, BYEs will not even 
> pass thorugh your server.
> >
> >
> >
> >
> >
> >
> >
> > I included a little snippet of the logging I do via the xlog calls. 
> One thing that confuses me is that based on my configuration and my 
> logs, I never explicitly relay the TRYING or OK messages. I set up my 
> onreply_route[1], but all I do is log that I got the reply. I did this 
> because regardless of what I do here, the UAC which requested the 
> INVITE gets the TRYING and OK messages properly. Is there something in 
> the tm.so that implicitly handles these, or am I missing some big 
> picture element here.
> >
> >
> >
> >
> > replies are automatically routed back on the reverted path of the 
> request - you do not need to route them explicitly.
> >
> >
> >
> >
> >
> > Regards,
> >
> >
> > Bogdan
> >
> >
> >
> >
> >
> >
> >
> > Thanks!
> >
> >
> > Geoff
> >
> >
> >
> >
> >
> > ################ BEGIN LOG SNIPPET ########################
> >
> >
> >
> >
> >
> > New request - M=INVITE RURI=sip:+15552021000 at 10.2.14.100 
> F=sip:[REMOVED] T=sip:+15552021000 at 10.2.14.100 IP=10.2.252.190 
> ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
> >
> >
> >
> >
> >
> > Recording Route info
> >
> >
> >
> >
> >
> > Method is an INVITE, fetching next from dispatcher
> >
> >
> >
> >
> >
> > Reply - S=100 D=Trying F=sip:[REMOVED] 
> T=sip:+15552021000 at 10.2.14.100 IP=10.2.252.181 
> ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
> >
> >
> >
> >
> >
> > Reply - S=200 D=OK F=sip:[REMOVED] T=sip:+15552021000 at 10.2.14.100 
> IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
> >
> >
> >
> >
> >
> > New request - M=ACK RURI=sip:+15552021000 at 10.2.252.181 
> F=sip:[REMOVED] T=sip:+15552021000 at 10.2.14.100 IP=10.2.252.190 
> ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
> >
> >
> >
> >
> >
> > Recording Route info
> >
> >
> >
> >
> >
> > Loose route has returned true, attempting routing.
> >
> >
> >
> >
> >
> > Setting up reply handler and relaying request
> >
> >
> >
> >
> >
> > New request - M=BYE RURI=sip:+15552021000 at 10.2.252.181 
> F=sip:6789050671 at connectfirst.com T=sip:+15552021000 at 10.2.14.100 
> IP=10.2.252.190 ID=5fe66b3e04cbdd991217a4426afa42f8 at connectfirst.com
> >
> >
> >
> >
> >
> > Recording Route info
> >
> >
> >
> >
> >
> > Loose route has returned true, attempting routing.
> >
> >
> >
> >
> >
> > Setting up reply handler and relaying request
> >
> >
> >
> >
> >
> > Reply - S=200 D=OK F=sip:[REMOVED] T=sip:+15552021000 at 10.2.14.100 
> IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
> >
> >
> >
> >
> >
> >
> >
> >