Bogdan (and list),
<br />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.
<br />
<br />I have gone through and made your suggested changes and things seem to be working quite well for what I am trying to accomplish.
<br />
<br />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?
<br />
<br />
<br />
<br />Thanks,
<br />Geoff
<br />
<br />On Nov 13, 2008 5:02am, Bogdan-Andrei Iancu <bogdan@voice-system.ro> wrote:
<br />> Hi Geoff,
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> geoffreymina@gmail.com wrote:
<br />>
<br />>
<br />>
<br />>
<br />> 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.
<br />>
<br />>
<br />>
<br />>
<br />> My comments were generally speaking (for a LB topic) and not strictly in regards to a particular script.
<br />>
<br />>
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> 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().
<br />>
<br />>
<br />>
<br />>
<br />> 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.
<br />>
<br />>
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> 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.
<br />>
<br />>
<br />>
<br />>
<br />> replies are automatically routed back on the reverted path of the request - you do not need to route them explicitly.
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> Regards,
<br />>
<br />>
<br />> Bogdan
<br />>
<br />>
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> Thanks!
<br />>
<br />>
<br />> Geoff
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> ################ BEGIN LOG SNIPPET ########################
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> New request - M=INVITE RURI=sip:+15552021000@10.2.14.100 F=sip:[REMOVED] T=sip:+15552021000@10.2.14.100 IP=10.2.252.190 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> Recording Route info
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> Method is an INVITE, fetching next from dispatcher
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> Reply - S=100 D=Trying F=sip:[REMOVED] T=sip:+15552021000@10.2.14.100 IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> Reply - S=200 D=OK F=sip:[REMOVED] T=sip:+15552021000@10.2.14.100 IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> New request - M=ACK RURI=sip:+15552021000@10.2.252.181 F=sip:[REMOVED] T=sip:+15552021000@10.2.14.100 IP=10.2.252.190 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> Recording Route info
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> Loose route has returned true, attempting routing.
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> Setting up reply handler and relaying request
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> New request - M=BYE RURI=sip:+15552021000@10.2.252.181 F=sip:6789050671@connectfirst.com T=sip:+15552021000@10.2.14.100 IP=10.2.252.190 ID=5fe66b3e04cbdd991217a4426afa42f8@connectfirst.com
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> Recording Route info
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> Loose route has returned true, attempting routing.
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> Setting up reply handler and relaying request
<br />>
<br />>
<br />>
<br />>
<br />>
<br />> Reply - S=200 D=OK F=sip:[REMOVED] T=sip:+15552021000@10.2.14.100 IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
<br />>
<br />>
<br />>
<br />>
<br />>
<br />>
<br />>
<br />>