[SR-Users] Dispatcher Failover algorithm

Daniel-Constantin Mierla miconda at gmail.com
Wed Jan 14 10:12:10 CET 2015


Can you check the state of the gateway via kamctl dispatcher list?

Cheers,
Daniel

On 13/01/15 11:51, Yuriy Gorlichenko wrote:
> Daniel.  I added 8 algorithm to our server and it works with 2 servers
> now but it works strange because:
> While works server with priority 1 - all ok. When this server goes
> down dispatcher choose next server with lowes priority. But when
> server with highest priority waking up dispatcher use server with
> lowes priority until this server not goes down.
>
> 2015-01-12 15:18 GMT+03:00 Yuriy Gorlichenko <ovoshlook at gmail.com
> <mailto:ovoshlook at gmail.com>>:
>
>     Daniel. Hello. I see changes at documentation about algorithms at
>     4.3 documentation for dispatcher. Now I see than 8 algo use
>     priority. Not I set this algorithm to my servers but priority
>     still not worked.
>
>     my dispatcher settings Are
>
>
>     modparam("dispatcher", "db_url",DBURL)
>     modparam("dispatcher", "table_name", "dispatcher")
>     modparam("dispatcher", "setid_col", "setid")
>     modparam("dispatcher", "priority_col", "priority")
>     modparam("dispatcher", "destination_col", "destination")
>     modparam("dispatcher", "force_dst", 1)
>     modparam("dispatcher", "flags", 3)
>     modparam("dispatcher", "dst_avp", "$avp(i:271)")
>     modparam("dispatcher", "grp_avp", "$avp(i:272)")
>     modparam("dispatcher", "cnt_avp", "$avp(i:273)")
>     modparam("dispatcher", "ds_ping_from", "sip:kamailio1 at 10.0.1.12
>     <mailto:sip%3Akamailio1 at 10.0.1.12>")
>     modparam("dispatcher", "ds_ping_interval",15)
>     modparam("dispatcher", "ds_probing_mode", 1)
>     modparam("dispatcher", "ds_ping_reply_codes",
>     "class=2;code=403;code=404;code=484;class=3")
>     modparam("tm", "reparse_on_dns_failover", 0)
>
>
>
>     (!ds_select_dst("$var(setid)", "8")){
>
>     sl_send_reply("500", "Service Unavailable");
>                 xlog("L_INFO","{$rm} from [$fU@$si:$sp] But NO
>     destinations available for $rd \n");
>     t_on_failure("DISPATCHER_ROLLOVER");
>
>     }
>
>     if (!t_relay()) {
>     sl_reply_error();
>
>
>     2015-01-10 2:31 GMT+03:00 Yuriy Gorlichenko <ovoshlook at gmail.com
>     <mailto:ovoshlook at gmail.com>>:
>
>         Priority bassed? I've read about all algorithms of disatcher
>         and can not find that anone use priority... 
>
>          *
>
>             “0” - hash over callid
>
>          *
>
>             “1” - hash over from URI.
>
>          *
>
>             “2” - hash over to URI.
>
>          *
>
>             “3” - hash over request-URI.
>
>          *
>
>             “4” - round-robin (next destination).
>
>          *
>
>             “5” - hash over authorization-username
>             (Proxy-Authorization or "normal" authorization). If no
>             username is found, round robin is used.
>
>          *
>
>             “6” - random (using rand()).
>
>          *
>
>             “7” - hash over the content of PVs string. Note: This
>             works only when the parameter hash_pvar is set.
>
>          *
>
>             “8” - use first destination (good for failover).
>
>          *
>
>             “9” - use weight based load distribution. You have to set
>             the attribute 'weight' per each address in destination set.
>
>          *
>
>             “10” - use call load distribution. You have to set the
>             attribute 'duid' (as an unique string id) per each address
>             in destination set. Also, you must set parameters
>             'dstid_avp' and 'ds_hash_size'.
>
>             The algorithm can be used even with stateless proxy mode,
>             there is no SIP dialog tracking depending on other
>             modules, just an internal lightweight call tracking by
>             Call-Id, thus is fast and suitable even for embedded systems.
>
>             The first destination selected by this algorithm is the
>             one that has the least number of calls associated. The
>             rest of the destination list is taken in order of the
>             entries in set - anyhow, until a re-route to next
>             destination happens, the load on each address can change.
>
>             This algorithm can be used only for dispatching INVITE
>             requests as it is the only SIP method creating a SIP call.
>
>          *
>
>             “X” - if the algorithm is not implemented, the first entry
>             in set is chosen.
>
>
>         2015-01-09 20:23 GMT+03:00 Daniel-Constantin Mierla
>         <miconda at gmail.com <mailto:miconda at gmail.com>>:
>
>             You probably look for priority based routing -- see the
>             readme of dispatcher module.
>
>             Cheers,
>             Daniel
>
>
>             On 09/01/15 17:52, Yuriy Gorlichenko wrote:
>>             I as wrote before - we find dispatcher algorithm than can
>>             do mechanism something like this:
>>             Try call to fist server with max priority or weight. OIf
>>             this server unavailible then call second server with less
>>             weight and etc.
>>
>>             Does anyone know what ling of algorithm we can use for this?
>>
>>
>>             _______________________________________________
>>             SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>             sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
>>             http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>             -- 
>             Daniel-Constantin Mierla
>             http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda
>
>
>             _______________________________________________
>             SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
>             mailing list
>             sr-users at lists.sip-router.org
>             <mailto:sr-users at lists.sip-router.org>
>             http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150114/22040481/attachment.html>


More information about the sr-users mailing list