[OpenSIPS-Users] dispatcher module + load balancing + round robin

technocrat voip techievoip at gmail.com
Mon Aug 18 12:08:32 CEST 2008


Thanks for the response.

I think i got the required action.

following is the DBG messages

Aug 18 14:53:10 [23018] DBG:dispatcher:ds_select_dst: set [2]
Aug 18 14:53:10 [23018] DBG:dispatcher:ds_select_dst: alg hash [0]
Aug 18 14:53:10 [23018] DBG:dispatcher:ds_select_dst: selected [4-2/0]
<sip:*.*.*.137:5080>
.
.
.
Aug 18 14:53:11 [23018] DBG:dispatcher:ds_select_dst: set [2]
Aug 18 14:53:11 [23018] DBG:dispatcher:ds_select_dst: alg hash [1]
Aug 18 14:53:11 [23018] DBG:dispatcher:ds_select_dst: selected [4-2/1]
<sip:*.*.*.59:5080>
.
.
.
.
Aug 18 14:53:12 [23018] DBG:dispatcher:ds_select_dst: set [2]
Aug 18 14:53:12 [23018] DBG:dispatcher:ds_select_dst: alg hash [0]
Aug 18 14:53:12 [23018] DBG:dispatcher:ds_select_dst: selected [4-2/0]
<sip:*.*.*.137:5080>
..
.
.
.
.
.
Aug 18 14:53:14 [23018] DBG:dispatcher:ds_select_dst: set [2]
Aug 18 14:53:14 [23018] DBG:dispatcher:ds_select_dst: alg hash [1]
Aug 18 14:53:14 [23018] DBG:dispatcher:ds_select_dst: selected [4-2/1]
<sip:*.*.*.59:5080>
.
.
.
.
.
.
Aug 18 14:53:18 [23018] DBG:dispatcher:ds_select_dst: set [2]
Aug 18 14:53:18 [23018] DBG:dispatcher:ds_select_dst: alg hash [0]
Aug 18 14:53:18 [23018] DBG:dispatcher:ds_select_dst: selected [4-2/0]
<sip:*.*.*.137:5080>
.
.
.
.
Aug 18 14:53:26 [23018] DBG:dispatcher:ds_select_dst: set [2]
Aug 18 14:53:26 [23018] DBG:dispatcher:ds_select_dst: alg hash [1]
Aug 18 14:53:26 [23018] DBG:dispatcher:ds_select_dst: selected [4-2/1]
<sip:*.*.*.59:5080>
.
.
.


Few concerns / doubts are.

1) If i use  the "0" (hash on callid) instead of "4" (round robin) , does
this mean that there is no gaurenty that all the messages of one UA will be
going to same server.

2) If i use the "0" does this also take care of load balancing. In round
robin i observed it is like 1:1 forwarding to the servers , what would be in
the "0" case ?

3) In general what would be the best option to use with the dispatcher in
load balancing for the half a million users.


thanks ..
On Mon, Aug 18, 2008 at 1:56 PM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:

> Hi David,
>
> This should not be an issue - normally you should do dispatching only on
> the original requests and use record_route/loose_route for the
> sequential requests (with no dispatching). CANCEL are automatically
> routed to the same destination as INVITE by TM, so again, you do not
> need to do dispatching on them.
>
> Regards
> Bogdan
>
> David Villasmil wrote:
> > Hello,
> >
> >      You can't simply do a round-robin on all messages, you must do it
> > with hash on call id. At least in my experience. That's because if you
> > send an invite to server 1 and receive a CANCEL and your simply doing
> > rr it is not guarateed to go to the same server you sent the original
> > INVITE to.... But if you use hash over call-id you can be sure all
> > subsequent messages are delivered to the correct server.
> >
> >
> > David
> >
> > On Sun, Aug 17, 2008 at 8:12 PM, Bogdan-Andrei Iancu
> > <bogdan at voice-system.ro> wrote:
> >
> >> Hi there,
> >>
> >> do you get any error into the logs?
> >>
> >> have you tried to use a different algorithm like 0 (hash over the
> >> callid) - second param, to see if there is any difference?
> >>
> >> Regards,
> >> Bogdan
> >>
> >> technocrat voip wrote:
> >>
> >>> I am have openser installed and my expectation with the below
> >>> configuration is open ser will forward the request it gets to the
> >>> other servers ( dispatch.cfg ) in round robin fashion .
> >>>
> >>> I mean first will goto the first serer and second to the second server
> >>> and third again to first server like that..
> >>>
> >>> My configs are like below
> >>>
> >>> openser.cfg
> >>>
> >>>
> >>> children=4
> >>>
> >>> /* uncomment the following lines to enable debugging */
> >>> debug=9
> >>> fork=no
> >>> log_stderror=yes
> >>> port=5060
> >>>
> >>> /* uncomment and configure the following line if you want openser to
> >>>    bind on a specific interface/port/proto (default bind on all
> >>> available) */
> >>> listen=udp:xxx.xxx.xxx.204:5060
> >>>
> >>>
> >>> ####### Modules Section ########
> >>>
> >>> #set module path
> >>> mpath="/usr/local/lib/openser/modules/"
> >>>
> >>> /* uncomment next line for MySQL DB support */
> >>> #loadmodule "mysql.so"
> >>> loadmodule "sl.so"
> >>> loadmodule "tm.so"
> >>> loadmodule "rr.so"
> >>> loadmodule "maxfwd.so"
> >>> loadmodule "usrloc.so"
> >>> loadmodule "registrar.so"
> >>> loadmodule "textops.so"
> >>> loadmodule "mi_fifo.so"
> >>> loadmodule "uri_db.so"
> >>> loadmodule "uri.so"
> >>> loadmodule "xlog.so"
> >>> loadmodule "acc.so"
> >>> loadmodule "dispatcher.so"
> >>> # ----------------- setting module-specific parameters ---------------
> >>>
> >>> # ----- mi_fifo params -----
> >>> modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
> >>>
> >>> # ----- rr params -----
> >>> # add value to ;lr param to cope with most of the UAs
> >>> modparam("rr", "enable_full_lr", 1)
> >>> # do not append from tag to the RR (no need for this script)
> >>> modparam("rr", "append_fromtag", 0)
> >>> # ----- rr params -----
> >>> modparam("registrar", "method_filtering", 1)
> >>> # ----- uri_db params -----
> >>> /* by default we disable the DB support in the module as we do not need
> it
> >>>    in this configuration */
> >>> modparam("uri_db", "use_uri_table", 0)
> >>> modparam("uri_db", "db_url", "")
> >>> # ----- usrloc params -----
> >>> modparam("usrloc", "db_mode",   0)
> >>> /* uncomment the following lines if you want to enable DB persistency
> >>>    for location entries */
> >>> #modparam("usrloc", "db_mode",   2)
> >>> #modparam("usrloc", "db_url",
> >>> #    "mysql://openser:openserrw@localhost/openser")
> >>>
> >>>
> >>> # ----- auth_db params -----
> >>> /* uncomment the following lines if you want to enable the DB based
> >>>    authentication */
> >>>
> >>> #------ dispatcher params -----
> >>>
> modparam("dispatcher","list_file","/usr/local/etc/openser/dispatcher.cfg")
> >>>
> >>>
> >>> ####### Routing Logic ########
> >>>
> >>>
> >>> # main request routing logic
> >>>
> >>> route{
> >>>
> >>>     log(1,"This is the another log message \n");
> >>>     xlog("L_INFO", "SIP Request: method [$rm] from [$fu] to [$tu]\n");
> >>>
> >>>
> >>>     if (!mf_process_maxfwd_header("10")) {
> >>>         sl_send_reply("483","Too Many Hops");
> >>>         exit;
> >>>     }
> >>>
> >>>     ds_select_dst("2","4");
> >>>
> >>>     forward();
> >>> }
> >>>
> >>>
> >>> dispatcher.cfg
> >>>
> >>> # $Id: dispatcher.list 3662 2008-02-07 13:06:00Z miconda $
> >>> # dispatcher destination sets
> >>> #
> >>>
> >>> # line format
> >>> # setit(integer) destination(sip uri) flags (integer, optional)
> >>>
> >>> # proxies
> >>> 2 sip:xx.xx.xxx.137:5080
> >>> 2 sip:xxx.xxx.xx.59:5080
> >>>
> >>>
> >>> continously it goes to 59 only it never goes to 137 ..
> >>>
> >>> Any help in this would be appreciated.
> >>>
> >>>
> >>>
> >>>
> >>> Please
> >>>
> ------------------------------------------------------------------------
> >>>
> >>> _______________________________________________
> >>> Users mailing list
> >>> Users at lists.opensips.org
> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>>
> >>>
> >> _______________________________________________
> >> Users mailing list
> >> Users at lists.opensips.org
> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>
> >>
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20080818/e20dcfb9/attachment.htm 


More information about the Users mailing list