[SR-Users] Dispatcher 8 algorithm based on priority strange works
Daniel-Constantin Mierla
miconda at gmail.com
Wed Jan 14 11:20:08 CET 2015
Give the output of 'kamailio -v', because you are running master.
There were some commits to the part about activating dispatcher
gateways, with several commits. Might be some intermediate state.
Cheers,
Daniel
On 14/01/15 10:43, Yuriy Gorlichenko wrote:
> 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
> <mailto: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
>> <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();
>>
>> we use 4.3 master branch kamailio
>>
>>
>> _______________________________________________
>> 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/00c9d27b/attachment.html>
More information about the sr-users
mailing list