Input on my loadbalancer configuration

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Input on my loadbalancer configuration

Geoffrey Mina
Was wondering if any of the good people out there would be willing to comment on my configuration. The goal here is to simply provide inbound load balancing services from my service provider to a farm of 10 asterisk servers. I was hoping to get around this without "tm.so", but i couldn't figure it out. I am trying to build a system which will eventually support 2000 concurrent inbound sessions. Here is what I have come up with.

This works in the bubble of my testing/proof of concept world, but I am sure I am missing some important aspects.

Thanks for anyones time!


###### Global Parameters #####
debug=9
log_stderror=no
log_facility=LOG_LOCAL0
fork=yes
children=8
disable_tcp=yes
listen=eth0:5060
port=5060

##### Debug Enabled #####
fork=no
log_stderror=yes

##### Module Loading and Param Setting #####
mpath="/usr/local/lib64/opensips/modules/"
loadmodule "sl.so"
loadmodule "db_mysql.so"
loadmodule "tm.so"
loadmodule "maxfwd.so"
loadmodule "rr.so"

## Enable SipTrace module for debugging SIP transactions ##
loadmodule "siptrace.so"
modparam("siptrace","db_url","mysql://[removed]:[removed]@localhost/opensips")
modparam("siptrace","table","sip_trace")
modparam("siptrace","trace_on",1)
modparam("siptrace","trace_flag",13)

## Enable Dispatcher module ##
loadmodule "dispatcher.so"
#modparam("dispatcher","ds_ping_method","INFO")
#modparam("dispatcher","ds_ping_from","sip:[hidden email]")
#modparam("dispatcher","ds_ping_interval",10)
#modparam("dispatcher","ds_probing_mode",1)

##### Routing Logic #####
route{
setflag(13);
sip_trace();

if(!mf_process_maxfwd_header("10")){
sl_send_reply("483","Too Many Hops");
drop();
}

if(method=="INVITE"){
ds_select_dst("1","4");
t_on_failure("1");
t_relay();
exit();
}else{
t_relay();
exit();
}
}

failure_route[1]{
if(t_check_status("408")){
ds_mark_dst();
}

ds_next_dst();
t_on_failure("1");
t_relay();
}
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Input on my loadbalancer configuration

Geoffrey Mina
Please disregard that last configuration.  I have gone through and
enhanced the config based on some more studying.  If anyone would care
to comment on the current configuration I would really appreciate it.
It all works as designed, I am really just looking for any 'gotchas'
which I haven't accounted for... as well as anything I am doing which
is very inefficient or otherwise bad practice.

Thanks!
Geoff

<pre>


###### Global Parameters #####
debug=3
log_stderror=no
log_facility=LOG_LOCAL0
fork=yes
children=8
disable_tcp=yes
listen=eth0:5060
port=5060


#fork=no
#log_stderror=yes

##### Module Loading and Param Setting #####
mpath="/usr/local/lib64/opensips/modules/"
loadmodule "sl.so"
loadmodule "db_mysql.so"
loadmodule "tm.so"
loadmodule "maxfwd.so"
loadmodule "uri.so"
loadmodule "textops.so"

## Enable RR ##
loadmodule "rr.so"
modparam("rr", "enable_full_lr",0)
modparam("rr", "append_fromtag",1)
modparam("rr", "enable_double_rr",1)
modparam("rr", "add_username",0)

## Enable Logging ##
loadmodule "xlog.so"
modparam("xlog", "buf_size",4096)
modparam("xlog", "force_color",0)

## Enable SipTrace module for debugging SIP transactions ##
loadmodule "siptrace.so"
modparam("siptrace","db_url","mysql://appservers:appservers@localhost/opensips")
modparam("siptrace","table","sip_trace")
modparam("siptrace","trace_on",1)
modparam("siptrace","trace_flag",13)

## Enable Dispatcher module ##
loadmodule "dispatcher.so"
#modparam("dispatcher","ds_ping_method","INFO")
#modparam("dispatcher","ds_ping_from","sip:[hidden email]")
#modparam("dispatcher","ds_ping_interval",10)
#modparam("dispatcher","ds_probing_mode",1)


###########################################################################
## Request route 'main'
###########################################################################
route{
    xlog("L_INFO", "New request - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
    setflag(13);
    sip_trace();

    if(msg:len > max_len){
        xlog("L_INFO", "Message too big\n");
        sl_send_reply("513", "Message Too Big");
        exit;
    }

    if (!mf_process_maxfwd_header("70")){
        xlog("L_INFO", "Too many hops\n");
        sl_send_reply("483", "Too Many Hops");
        exit;
    }

    if(!is_method("REGISTER")){
        xlog("L_INFO", "Recording Route info\n");
        record_route();
    }


    if(is_method("INVITE"){
        xlog("L_INFO", "Method is an INVITE, fetching next from dispatcher\n");
        route(1);
    }else if(loose_route()){
        xlog("L_INFO", "Loose route has returned true, attempting routing.\n");

        if(!has_totag()){
            xlog("L_INFO", "Initial loose-route rejected\n");
            sl_send_reply("403","Initial Loose-Routing Rejected.");
            exit;
        }

        route(2);
    }else{
        if(is_method("CANCEL") || is_method("ACK")){
            xlog("L_INFO", "We have an ACK or CANCEL");
            route(3);
        }
    }
}



########################################################################
## Handles relay of INVITE messages
## with round-robin load balancing
########################################################################
route[1]{
    ds_select_dst("1","4");
    t_on_reply("1");
    t_on_failure("1");
    t_relay();
}



########################################################################
## Handles relay of all non INVITE messages
########################################################################
route[2]{
    xlog("L_INFO", "Setting up reply handler  and relaying request\n");
    t_on_reply("1");
    if(!t_relay()){
        sl_reply_error();
    }
}


########################################################################
## Handles relay of CANCEL or ACK messages
########################################################################
route[3]{
    t_on_reply("1");
    if(t_check_trans()){
        if(!t_relay()){
            xlog("L_INFO","Error relaying message route[3]\n");
            sl_reply_error();
        }
    }else{
        xlog("L_INFO","Dropping mis-routed request from route[3]\n");

    }
    exit;
}



#######################################################################
## Simply logs responses
#######################################################################
onreply_route[1]{
    xlog("L_INFO", "Reply - S=$rs D=$rr F=$fu T=$tu IP=$si ID=$ci\n");
    exit;
}



#######################################################################
## Handles failure of INVITE forwarding
#######################################################################
failure_route[1]{
    xlog("L_INFO","Failure route, trying agai\n");

    if(t_check_status("408")){
        xlog("L_INFO","Got a 408 Timeout, flagging dest as invalid\n");
        ds_mark_dst();
    }

    route(1);
}




On Sun, Nov 9, 2008 at 2:45 PM, <[hidden email]> wrote:
>
> Was wondering if any of the good people out there would be willing to comment on my configuration. The goal here is to simply provide inbound load balancing services from my service provider to a farm of 10 asterisk servers. I was hoping to get around this without "tm.so", but i couldn't figure it out. I am trying to build a system which will eventually support 2000 concurrent inbound sessions. Here is what I have come up with.
>
> This works in the bubble of my testing/proof of concept world, but I am sure I am missing some important aspects.
>
> Thanks for anyones time!
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Input on my loadbalancer configuration

Bogdan-Andrei Iancu
In reply to this post by Geoffrey Mina
Hi,

Two remarks:

1) the path taken by a request will be taken (in the opposite direction)
by all the replies of that request - that is SIP :) . So, if your INVITE
went through the dispatcher, all its replies (180, 200) will go via
dispatcher

2) for sequential requests (ACK, re-INVITEs, BYEs) you can make them
skip the dispatcher by NOT doing record-routing on the dispatcher for
the original INVITE

1') regarding my comment from 1) - you may play with the send() function
- this is a stateless function for sending a request out but without
adding any VIA in the request. So the hop doing send() will be invisible
for the replies also (the replies will bypass this hop as there is no
VIA for it) - but I warn you that this is against RFC3261 and also it
might generate problems at network level (a SIP point expects to have
the same IP:port peer during a transaction)

Regards,
Bogdan



[hidden email] wrote:

> Was wondering if any of the good people out there would be willing to
> comment on my configuration. The goal here is to simply provide
> inbound load balancing services from my service provider to a farm of
> 10 asterisk servers. I was hoping to get around this without "tm.so",
> but i couldn't figure it out. I am trying to build a system which will
> eventually support 2000 concurrent inbound sessions. Here is what I
> have come up with.
>
> This works in the bubble of my testing/proof of concept world, but I
> am sure I am missing some important aspects.
>
> Thanks for anyones time!
>
>
> ###### Global Parameters #####
> debug=9
> log_stderror=no
> log_facility=LOG_LOCAL0
> fork=yes
> children=8
> disable_tcp=yes
> listen=eth0:5060
> port=5060
>
> ##### Debug Enabled #####
> fork=no
> log_stderror=yes
>
> ##### Module Loading and Param Setting #####
> mpath="/usr/local/lib64/opensips/modules/"
> loadmodule "sl.so"
> loadmodule "db_mysql.so"
> loadmodule "tm.so"
> loadmodule "maxfwd.so"
> loadmodule "rr.so"
>
> ## Enable SipTrace module for debugging SIP transactions ##
> loadmodule "siptrace.so"
> modparam("siptrace","db_url","mysql://[removed]:[removed]@localhost/opensips")
> modparam("siptrace","table","sip_trace")
> modparam("siptrace","trace_on",1)
> modparam("siptrace","trace_flag",13)
>
> ## Enable Dispatcher module ##
> loadmodule "dispatcher.so"
> #modparam("dispatcher","ds_ping_method","INFO")
> #modparam("dispatcher","ds_ping_from","sip:[hidden email]")
> #modparam("dispatcher","ds_ping_interval",10)
> #modparam("dispatcher","ds_probing_mode",1)
>
> ##### Routing Logic #####
> route{
> setflag(13);
> sip_trace();
>
> if(!mf_process_maxfwd_header("10")){
> sl_send_reply("483","Too Many Hops");
> drop();
> }
>
> if(method=="INVITE"){
> ds_select_dst("1","4");
> t_on_failure("1");
> t_relay();
> exit();
> }else{
> t_relay();
> exit();
> }
> }
>
> failure_route[1]{
> if(t_check_status("408")){
> ds_mark_dst();
> }
>
> ds_next_dst();
> t_on_failure("1");
> t_relay();
> }
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Input on my loadbalancer configuration

Geoffrey Mina
In reply to this post by Geoffrey Mina
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.

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().

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.

Thanks!
Geoff

################ BEGIN LOG SNIPPET ########################

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]

Recording Route info

Method is an INVITE, fetching next from dispatcher

Reply - S=100 D=Trying F=sip:[REMOVED] T=sip:+15552021000@10.2.14.100 IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]

Reply - S=200 D=OK F=sip:[REMOVED] T=sip:+15552021000@10.2.14.100 IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]

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]

Recording Route info

Loose route has returned true, attempting routing.

Setting up reply handler and relaying request

New request - M=BYE RURI=sip:+15552021000@10.2.252.181 F=sip:[hidden email] T=sip:+15552021000@10.2.14.100 IP=10.2.252.190 ID=[hidden email]

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@10.2.14.100 IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Input on my loadbalancer configuration

Jeff Pyle
In reply to this post by Bogdan-Andrei Iancu
What if instead of routing the INVITE, Opensips returned a 302 to the
originator, redirecting them to the Asterisk server(s) of choice for
that call?


- Jeff



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Bogdan-Andrei
Iancu
Sent: Tuesday, November 11, 2008 5:30 AM
To: [hidden email]
Cc: [hidden email]
Subject: Re: [OpenSIPS-Users] Input on my loadbalancer configuration

Hi,

Two remarks:

1) the path taken by a request will be taken (in the opposite direction)
by all the replies of that request - that is SIP :) . So, if your INVITE
went through the dispatcher, all its replies (180, 200) will go via
dispatcher

2) for sequential requests (ACK, re-INVITEs, BYEs) you can make them
skip the dispatcher by NOT doing record-routing on the dispatcher for
the original INVITE

1') regarding my comment from 1) - you may play with the send() function
- this is a stateless function for sending a request out but without
adding any VIA in the request. So the hop doing send() will be invisible
for the replies also (the replies will bypass this hop as there is no
VIA for it) - but I warn you that this is against RFC3261 and also it
might generate problems at network level (a SIP point expects to have
the same IP:port peer during a transaction)

Regards,
Bogdan



[hidden email] wrote:
> Was wondering if any of the good people out there would be willing to
> comment on my configuration. The goal here is to simply provide
> inbound load balancing services from my service provider to a farm of
> 10 asterisk servers. I was hoping to get around this without "tm.so",
> but i couldn't figure it out. I am trying to build a system which will

> eventually support 2000 concurrent inbound sessions. Here is what I
> have come up with.
>
> This works in the bubble of my testing/proof of concept world, but I
> am sure I am missing some important aspects.
>
> Thanks for anyones time!
>
>
> ###### Global Parameters #####
> debug=9
> log_stderror=no
> log_facility=LOG_LOCAL0
> fork=yes
> children=8
> disable_tcp=yes
> listen=eth0:5060
> port=5060
>
> ##### Debug Enabled #####
> fork=no
> log_stderror=yes
>
> ##### Module Loading and Param Setting #####
> mpath="/usr/local/lib64/opensips/modules/"
> loadmodule "sl.so"
> loadmodule "db_mysql.so"
> loadmodule "tm.so"
> loadmodule "maxfwd.so"
> loadmodule "rr.so"
>
> ## Enable SipTrace module for debugging SIP transactions ## loadmodule

> "siptrace.so"
> modparam("siptrace","db_url","mysql://[removed]:[removed]@localhost/op
> ensips")
> modparam("siptrace","table","sip_trace")
> modparam("siptrace","trace_on",1)
> modparam("siptrace","trace_flag",13)
>
> ## Enable Dispatcher module ##
> loadmodule "dispatcher.so"
> #modparam("dispatcher","ds_ping_method","INFO")
> #modparam("dispatcher","ds_ping_from","sip:[hidden email]
> ")
> #modparam("dispatcher","ds_ping_interval",10)
> #modparam("dispatcher","ds_probing_mode",1)
>
> ##### Routing Logic #####
> route{
> setflag(13);
> sip_trace();
>
> if(!mf_process_maxfwd_header("10")){
> sl_send_reply("483","Too Many Hops");
> drop();
> }
>
> if(method=="INVITE"){
> ds_select_dst("1","4");
> t_on_failure("1");
> t_relay();
> exit();
> }else{
> t_relay();
> exit();
> }
> }
>
> failure_route[1]{
> if(t_check_status("408")){
> ds_mark_dst();
> }
>
> ds_next_dst();
> t_on_failure("1");
> t_relay();
> }
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Input on my loadbalancer configuration

Geoffrey Mina
well.. that would just be too simple!!  How would I integrate sending
a 302 with the dispatcher module?

thanks for the out-of-the-box idea!

-Geoff

On Tue, Nov 11, 2008 at 9:13 AM, Jeff Pyle <[hidden email]> wrote:

> What if instead of routing the INVITE, Opensips returned a 302 to the
> originator, redirecting them to the Asterisk server(s) of choice for
> that call?
>
>
> - Jeff
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Bogdan-Andrei
> Iancu
> Sent: Tuesday, November 11, 2008 5:30 AM
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: [OpenSIPS-Users] Input on my loadbalancer configuration
>
> Hi,
>
> Two remarks:
>
> 1) the path taken by a request will be taken (in the opposite direction)
> by all the replies of that request - that is SIP :) . So, if your INVITE
> went through the dispatcher, all its replies (180, 200) will go via
> dispatcher
>
> 2) for sequential requests (ACK, re-INVITEs, BYEs) you can make them
> skip the dispatcher by NOT doing record-routing on the dispatcher for
> the original INVITE
>
> 1') regarding my comment from 1) - you may play with the send() function
> - this is a stateless function for sending a request out but without
> adding any VIA in the request. So the hop doing send() will be invisible
> for the replies also (the replies will bypass this hop as there is no
> VIA for it) - but I warn you that this is against RFC3261 and also it
> might generate problems at network level (a SIP point expects to have
> the same IP:port peer during a transaction)
>
> Regards,
> Bogdan
>
>
>
> [hidden email] wrote:
>> Was wondering if any of the good people out there would be willing to
>> comment on my configuration. The goal here is to simply provide
>> inbound load balancing services from my service provider to a farm of
>> 10 asterisk servers. I was hoping to get around this without "tm.so",
>> but i couldn't figure it out. I am trying to build a system which will
>
>> eventually support 2000 concurrent inbound sessions. Here is what I
>> have come up with.
>>
>> This works in the bubble of my testing/proof of concept world, but I
>> am sure I am missing some important aspects.
>>
>> Thanks for anyones time!
>>
>>
>> ###### Global Parameters #####
>> debug=9
>> log_stderror=no
>> log_facility=LOG_LOCAL0
>> fork=yes
>> children=8
>> disable_tcp=yes
>> listen=eth0:5060
>> port=5060
>>
>> ##### Debug Enabled #####
>> fork=no
>> log_stderror=yes
>>
>> ##### Module Loading and Param Setting #####
>> mpath="/usr/local/lib64/opensips/modules/"
>> loadmodule "sl.so"
>> loadmodule "db_mysql.so"
>> loadmodule "tm.so"
>> loadmodule "maxfwd.so"
>> loadmodule "rr.so"
>>
>> ## Enable SipTrace module for debugging SIP transactions ## loadmodule
>
>> "siptrace.so"
>> modparam("siptrace","db_url","mysql://[removed]:[removed]@localhost/op
>> ensips")
>> modparam("siptrace","table","sip_trace")
>> modparam("siptrace","trace_on",1)
>> modparam("siptrace","trace_flag",13)
>>
>> ## Enable Dispatcher module ##
>> loadmodule "dispatcher.so"
>> #modparam("dispatcher","ds_ping_method","INFO")
>> #modparam("dispatcher","ds_ping_from","sip:[hidden email]
>> ")
>> #modparam("dispatcher","ds_ping_interval",10)
>> #modparam("dispatcher","ds_probing_mode",1)
>>
>> ##### Routing Logic #####
>> route{
>> setflag(13);
>> sip_trace();
>>
>> if(!mf_process_maxfwd_header("10")){
>> sl_send_reply("483","Too Many Hops");
>> drop();
>> }
>>
>> if(method=="INVITE"){
>> ds_select_dst("1","4");
>> t_on_failure("1");
>> t_relay();
>> exit();
>> }else{
>> t_relay();
>> exit();
>> }
>> }
>>
>> failure_route[1]{
>> if(t_check_status("408")){
>> ds_mark_dst();
>> }
>>
>> ds_next_dst();
>> t_on_failure("1");
>> t_relay();
>> }
>> ----------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Input on my loadbalancer configuration

Jeff Pyle
Figures you would ask that.  Ha!  I'm not sure.  I'm quite new to
Opensips, and haven't made it to the dispatcher module yet.

Anyone?          Buehler?



- Jeff
 

-----Original Message-----
From: Geoffrey Mina [mailto:[hidden email]]
Sent: Tuesday, November 11, 2008 9:36 AM
To: Jeff Pyle
Cc: [hidden email]
Subject: Re: [OpenSIPS-Users] Input on my loadbalancer configuration

well.. that would just be too simple!!  How would I integrate sending a
302 with the dispatcher module?

thanks for the out-of-the-box idea!

-Geoff

On Tue, Nov 11, 2008 at 9:13 AM, Jeff Pyle <[hidden email]>
wrote:
> What if instead of routing the INVITE, Opensips returned a 302 to the
> originator, redirecting them to the Asterisk server(s) of choice for
> that call?
>
>
> - Jeff

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Input on my loadbalancer configuration

Bogdan-Andrei Iancu
Well, after the new RURI was set with dispatcher, do
sl_send_reply("301","redirected");
Automatically, the RURI will be placed as contact in 3xx reply.

Regards,
Bogdan

Jeff Pyle wrote:

> Figures you would ask that.  Ha!  I'm not sure.  I'm quite new to
> Opensips, and haven't made it to the dispatcher module yet.
>
> Anyone?          Buehler?
>
>
>
> - Jeff
>  
>
> -----Original Message-----
> From: Geoffrey Mina [mailto:[hidden email]]
> Sent: Tuesday, November 11, 2008 9:36 AM
> To: Jeff Pyle
> Cc: [hidden email]
> Subject: Re: [OpenSIPS-Users] Input on my loadbalancer configuration
>
> well.. that would just be too simple!!  How would I integrate sending a
> 302 with the dispatcher module?
>
> thanks for the out-of-the-box idea!
>
> -Geoff
>
> On Tue, Nov 11, 2008 at 9:13 AM, Jeff Pyle <[hidden email]>
> wrote:
>  
>> What if instead of routing the INVITE, Opensips returned a 302 to the
>> originator, redirecting them to the Asterisk server(s) of choice for
>> that call?
>>
>>
>> - Jeff
>>    
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Input on my loadbalancer configuration

Geoffrey Mina
In reply to this post by Geoffrey Mina
I invoked the dispatcher, but it doesn't appear anything was set. My flow is currently:


ds_select_dst("1","4");
sl_send_reply("301","redirected");



INVITE sip:+15552021000@10.2.14.100 SIP/2.0
Via: SIP/2.0/UDP 10.2.252.190:5060;branch=z9hG4bK62554e20;rport
From: "Geoff" <sip:[hidden email]>;tag=as1d87dcd5
To: <sip:+15552021000@10.2.14.100>
Contact: <sip:6789050671@10.2.252.190>
Call-ID: [hidden email]
CSeq: 102 INVITE
User-Agent: G-Tel v1.0
Max-Forwards: 70
Date: Tue, 11 Nov 2008 15:03:34 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 240

SIP/2.0 301 redirected
Via: SIP/2.0/UDP 10.2.252.190:5060;branch=z9hG4bK62554e20;rport=5060
From: "Geoff" <sip:[hidden email]>;tag=as1d87dcd5
To: <sip:+15552021000@10.2.14.100>;tag=b7b83ebb8b164c9706593e1cbef4dcee.af60
Call-ID: [hidden email]
CSeq: 102 INVITE
Server: OpenSIPS (1.4.2-notls (x86_64/linux))
Content-Length: 0



On Nov 11, 2008 9:59am, Bogdan-Andrei Iancu <[hidden email]> wrote:

> Well, after the new RURI was set with dispatcher, do sl_send_reply("301","redirected");
>
>
> Automatically, the RURI will be placed as contact in 3xx reply.
>
>
>
>
>
> Regards,
>
>
> Bogdan
>
>
>
>
>
> Jeff Pyle wrote:
>
>
>
>
> Figures you would ask that.  Ha!  I'm not sure.  I'm quite new to
>
>
> Opensips, and haven't made it to the dispatcher module yet.
>
>
>
>
>
> Anyone?          Buehler?
>
>
>
>
>
>
>
>
>
>
>
> - Jeff
>
>
>  
>
>
> -----Original Message-----
>
>
> From: Geoffrey Mina [mailto:[hidden email]] Sent: Tuesday, November 11, 2008 9:36 AM
>
>
> To: Jeff Pyle
>
>
> Cc: [hidden email]
>
>
> Subject: Re: [OpenSIPS-Users] Input on my loadbalancer configuration
>
>
>
>
>
> well.. that would just be too simple!!  How would I integrate sending a
>
>
> 302 with the dispatcher module?
>
>
>
>
>
> thanks for the out-of-the-box idea!
>
>
>
>
>
> -Geoff
>
>
>
>
>
> On Tue, Nov 11, 2008 at 9:13 AM, Jeff Pyle [hidden email]>
>
>
> wrote:
>
>
>  
>
>
>
>
> What if instead of routing the INVITE, Opensips returned a 302 to the originator, redirecting them to the Asterisk server(s) of choice for that call?
>
>
>
>
>
>
>
>
> - Jeff
>
>
>    
>
>
>
>
>
>
>
> _______________________________________________
>
>
> Users mailing list
>
>
> [hidden email]
>
>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
>  
>
>
>
>
>
>
>
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Input on my loadbalancer configuration

Bogdan-Andrei Iancu
Use

t_reply() instead of sl_send_reply() and ds_select_domain() instead of
ds_select_dst():

ds_select_domain("1","4");
t_reply("301","redirected");

Let me know if this works.

Regards,
Bogdan

[hidden email] wrote:

> I invoked the dispatcher, but it doesn't appear anything was set. My
> flow is currently:
>
>
> ds_select_dst("1","4");
> sl_send_reply("301","redirected");
>
>
>
> INVITE sip:+15552021000@10.2.14.100 SIP/2.0
> Via: SIP/2.0/UDP 10.2.252.190:5060;branch=z9hG4bK62554e20;rport
> From: "Geoff" <sip:[hidden email]>;tag=as1d87dcd5
> To: <sip:+15552021000@10.2.14.100>
> Contact: <sip:6789050671@10.2.252.190>
> Call-ID: [hidden email]
> CSeq: 102 INVITE
> User-Agent: G-Tel v1.0
> Max-Forwards: 70
> Date: Tue, 11 Nov 2008 15:03:34 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> Supported: replaces
> Content-Type: application/sdp
> Content-Length: 240
>
> SIP/2.0 301 redirected
> Via: SIP/2.0/UDP 10.2.252.190:5060;branch=z9hG4bK62554e20;rport=5060
> From: "Geoff" <sip:[hidden email]>;tag=as1d87dcd5
> To:
> <sip:+15552021000@10.2.14.100>;tag=b7b83ebb8b164c9706593e1cbef4dcee.af60
> Call-ID: [hidden email]
> CSeq: 102 INVITE
> Server: OpenSIPS (1.4.2-notls (x86_64/linux))
> Content-Length: 0
>
>
>
> On Nov 11, 2008 9:59am, Bogdan-Andrei Iancu <[hidden email]>
> wrote:
> > Well, after the new RURI was set with dispatcher, do
> sl_send_reply("301","redirected");
> >
> >
> > Automatically, the RURI will be placed as contact in 3xx reply.
> >
> >
> >
> >
> >
> > Regards,
> >
> >
> > Bogdan
> >
> >
> >
> >
> >
> > Jeff Pyle wrote:
> >
> >
> >
> >
> > Figures you would ask that.  Ha!  I'm not sure.  I'm quite new to
> >
> >
> > Opensips, and haven't made it to the dispatcher module yet.
> >
> >
> >
> >
> >
> > Anyone?          Buehler?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > - Jeff
> >
> >
> >  
> >
> >
> > -----Original Message-----
> >
> >
> > From: Geoffrey Mina [mailto:[hidden email]] Sent: Tuesday,
> November 11, 2008 9:36 AM
> >
> >
> > To: Jeff Pyle
> >
> >
> > Cc: [hidden email]
> >
> >
> > Subject: Re: [OpenSIPS-Users] Input on my loadbalancer configuration
> >
> >
> >
> >
> >
> > well.. that would just be too simple!!  How would I integrate sending a
> >
> >
> > 302 with the dispatcher module?
> >
> >
> >
> >
> >
> > thanks for the out-of-the-box idea!
> >
> >
> >
> >
> >
> > -Geoff
> >
> >
> >
> >
> >
> > On Tue, Nov 11, 2008 at 9:13 AM, Jeff Pyle [hidden email]>
> >
> >
> > wrote:
> >
> >
> >  
> >
> >
> >
> >
> > What if instead of routing the INVITE, Opensips returned a 302 to
> the originator, redirecting them to the Asterisk server(s) of choice
> for that call?
> >
> >
> >
> >
> >
> >
> >
> >
> > - Jeff
> >
> >
> >    
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> >
> >
> > Users mailing list
> >
> >
> > [hidden email]
> >
> >
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> >
> >
> >
> >  
> >
> >
> >
> >
> >
> >
> >
> >


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Input on my loadbalancer configuration

Bogdan-Andrei Iancu
In reply to this post by Geoffrey Mina
Hi Geoff,

[hidden email] 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@10.2.14.100
> F=sip:[REMOVED] T=sip:+15552021000@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@10.2.14.100
> IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
>
> Reply - S=200 D=OK F=sip:[REMOVED] T=sip:+15552021000@10.2.14.100
> IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
>
> 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]
>
> Recording Route info
>
> Loose route has returned true, attempting routing.
>
> Setting up reply handler and relaying request
>
> New request - M=BYE RURI=sip:+15552021000@10.2.252.181
> F=sip:[hidden email] T=sip:+15552021000@10.2.14.100
> IP=10.2.252.190 ID=[hidden email]
>
> 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@10.2.14.100
> IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Input on my loadbalancer configuration

Geoffrey Mina
In reply to this post by Geoffrey Mina
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 <[hidden email]> wrote:

> Hi Geoff,
>
>
>
>
>
> [hidden email] 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@10.2.14.100 F=sip:[REMOVED] T=sip:+15552021000@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@10.2.14.100 IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
>
>
>
>
>
> Reply - S=200 D=OK F=sip:[REMOVED] T=sip:+15552021000@10.2.14.100 IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
>
>
>
>
>
> 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]
>
>
>
>
>
> Recording Route info
>
>
>
>
>
> Loose route has returned true, attempting routing.
>
>
>
>
>
> Setting up reply handler and relaying request
>
>
>
>
>
> New request - M=BYE RURI=sip:+15552021000@10.2.252.181 F=sip:[hidden email] T=sip:+15552021000@10.2.14.100 IP=10.2.252.190 ID=[hidden email]
>
>
>
>
>
> 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@10.2.14.100 IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
>
>
>
>
>
>
>
>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 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


[hidden email] 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 <[hidden email]>
> wrote:
> > Hi Geoff,
> >
> >
> >
> >
> >
> > [hidden email] 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@10.2.14.100
> F=sip:[REMOVED] T=sip:+15552021000@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@10.2.14.100 IP=10.2.252.181
> ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
> >
> >
> >
> >
> >
> > Reply - S=200 D=OK F=sip:[REMOVED] T=sip:+15552021000@10.2.14.100
> IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
> >
> >
> >
> >
> >
> > 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]
> >
> >
> >
> >
> >
> > Recording Route info
> >
> >
> >
> >
> >
> > Loose route has returned true, attempting routing.
> >
> >
> >
> >
> >
> > Setting up reply handler and relaying request
> >
> >
> >
> >
> >
> > New request - M=BYE RURI=sip:+15552021000@10.2.252.181
> F=sip:[hidden email] T=sip:+15552021000@10.2.14.100
> IP=10.2.252.190 ID=[hidden email]
> >
> >
> >
> >
> >
> > 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@10.2.14.100
> IP=10.2.252.181 ID=5fe66b3e04cbdd991217a4426afa42f8@[REMOVED]
> >
> >
> >
> >
> >
> >
> >
> >


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users