[SR-Users] Dispatcher 8 algorithm based on priority strange works

[Yuriy Gorlichenko]

About servers - I see at asterisk successfull option requests from kamailio
and 200 reply o this requests. This meants as I understand, that servers
know about each other.

Now about behaivor:
Todays morning I try to down server with highest priority. Kam successfully
takes server with low priority an calls works through it. After that I try
to up server with highest rpiority. Then I take a call ans it goes through
server with lowes priority. I goes down server with lowest priority. Take
call. Call goes through highest priority server.
After it all I up server with low priority and then calls goes through it
(!!!) not as yesterday when call staing at highest priority server. It is
not normal as I think. and strange...

I can give you ssh to our servers to see this. if it needed. or some more
info but tomorrow morning. At this time servers busy with testion other
functions.


2015-01-14 12:31 GMT+03:00 Daniel-Constantin Mierla <miconda at gmail.com>:

>
> On 13/01/15 16:52, Yuriy Gorlichenko wrote:
>
> Daniel.  I added 8 algorithm to our server and it works with 2 asterisk
> 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.
>
>
> Perhaps it is a mistake in the part 'until this server not goes down'? Can
> you explain again the observed behaviour? Also, wrote in a previous email
> to a thread that seems to expose same issue, check the state of dispatcher
> addresses in memory via mi or rpc commands.
>
> Cheers,
> Daniel
>
>
> here id my config for dispatcher
>
> 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();
>
> we use 4.3 master branch kamailio
>
>
> _______________________________________________
> 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/20150114/86fc79ac/attachment.html>