[OpenSIPS-Users] dispatcher module + load balancing + round robin
technocrat voip
techievoip at gmail.com
Tue Aug 19 10:42:27 CEST 2008
Do we have any option for the dispatcher function,where i can give more that
one startergy ( parameter). Like "0" for hash on callid and "4" for round
robin.
thanks
On Mon, Aug 18, 2008 at 4:54 PM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:
> 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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20080819/0022d835/attachment-0001.htm
More information about the Users
mailing list