[SR-Users] Dispatcher Failover algorithm

[Yuriy Gorlichenko]

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

> 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")
> 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>:
>
>> 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>:
>>
>>>  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 listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>> --
>>> Daniel-Constantin Mierlahttp://twitter.com/#!/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
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150113/9fb00b2d/attachment.html>