[OpenSIPS-Users] Input on my loadbalancer configuration

[Bogdan-Andrei Iancu]

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]