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

Bogdan-Andrei Iancu bogdan at voice-system.ro
Mon Aug 18 13:24:22 CEST 2008


Hi there,

technocrat voip wrote:
> Thanks for the response.
>
> I think i got the required action.
>
> following is the DBG messages
>
> [....]
>
>
> 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.
hash on callid guarantees that all requests for a dialog will go to the 
same destination (callid is constant across dialog)
>
> 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 ?
yes, it will do dispatching across all the available destinations from 
the class.
>
> 3) In general what would be the best option to use with the dispatcher 
> in load balancing for the half a million users.
depends of what you want to balance and if the peers behind are or not 
identical.

Regards,
Bogdan
>
>
> thanks ..
> On Mon, Aug 18, 2008 at 1:56 PM, Bogdan-Andrei Iancu 
> <bogdan at voice-system.ro <mailto: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 <mailto: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 <mailto:Users at lists.opensips.org>
>     >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>     >>>
>     >>>
>     >> _______________________________________________
>     >> Users mailing list
>     >> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>     >>
>     >>
>     >
>     > _______________________________________________
>     > Users mailing list
>     > Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>     >
>     >
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>




More information about the Users mailing list