[SR-Users] dispatcher [dispatch.c:1416]: ds_load_remove(): cannot find load for (from asterisk call-id)

TEG AMJG tegamjg at gmail.com
Tue Apr 5 01:27:20 CEST 2016


Hi again

There is something that i am starting to realize and i think is the source
of the problem. Since i am not sure, I think someone can clarify this to me.

As i said the problem rises when i do a 2 call leg conversation. In which,
since Asterisk is a B2BUA and creates another channel (which ends up being
another dialog), there is a point where Asterisk initiates the SIP flow.

Sip Client 1 -----------> Kamailio ----------> Asterisk (dialog 1)
Asterisk -------------> Kamailio -------------> Sip Client 2 (dialog 2)

Now, since both Asterisk takes part of the destination addresses which the
dispatcher modules are managing at the moment, there is no way (from what i
know) that the ds_load_update() actually records that call load.

I am pretty sure that there is some way to manage this better, and since i
am new to Kamailio, I think you guys can help me out easily

Thank you very much for your time



2016-04-04 18:35 GMT-03:00 TEG AMJG <tegamjg at gmail.com>:

> Hi Alberto, thanks for your reply
>
> yeah, i am using ds_select_dst("0","10") in this case because i use
> setid=0 in the dispatcher table as you can see in this route block
>
> route[TOASTERISK] {
> #!ifdef WITH_LOADBALANCE
>         xlog("L_INFO","UBICAR: Forwarding non-registrar requests to
> Asterisk \n");
>          if(!ds_select_dst("0", "10")) {
>                 sl_send_reply("500", "Service Unavailable");
>                 xlog("L_ERROR","UBICAR: No destinations available for $rd
> \n");
>                 exit;
>         }
>         xlog("L_ERROR","UBICAR: AVP $avp(dsdstid)\n");
>         xlog("L_INFO","UBICAR: Dispatching to Asterisk Box $du\n");
>         t_set_fr(0,10000);
>         t_on_failure("MANAGE_FAILURE");
>         route(RELAY);
>         exit;
> #!endif
> }
>
> Also both Asterisk are responding to ping probes done by Kamailio, they
> are actually responding 404 but are still kept alive thanks to this param:
>
> modparam("dispatcher", "ds_ping_reply_codes", "class=2;code=480;code=404")
>
> and the command kamctl dispatcher dump shows them with flags=AP
>
> URI:: sip:192.168.10.191:5060 flags=AP priority=0
> attrs=duid=PBX2;my=pbx2;maxload=200
> URI:: sip:192.168.10.190:5060 flags=AP priority=0
> attrs=duid=PBX1;my=pbx1;maxload=200
>
> Also, i would like to know if there is a way to print some kind of table
> to see how kamailio are keeping these call loads recorded. I have been
> looking for it but i cannot find any way of doing it
>
> Again, thank you very much for your reply
>
>
> 2016-04-04 14:23 GMT-03:00 Alberto Sagredo <alberto.sagredo at avanzada7.com>
> :
>
>> Hi
>>
>> Are you using ds_select_dst("1", "10"); somewhere ?
>>
>> You have to check Asterisk is responding to OPTIONS as dispatcher
>> considered UP when 200 OK from Asterisk or SIP Gateway is received.. and
>> not if not received.
>>
>> I have used dispatcher but not with 10 option on algo...
>>
>> BR
>>
>>
>>
>>
>> 2016-04-04 8:07 GMT+02:00 TEG AMJG <tegamjg at gmail.com>:
>>
>>> Hi
>>>
>>> I am new to Kamailio and i am just trying to setup a kamailio (v4.2.3)
>>> dispatcher to distribute calls to 2 asterisk using the call load
>>> distribution algorithm (alg 10). I started to test and see how all it is
>>> working and in the logs appears that the call load record it cannot be
>>> found.
>>>
>>> - ERROR: dispatcher [dispatch.c:1416]: ds_load_remove(): cannot find
>>> load for (call id generated by asterisk)
>>>
>>> I am getting this error  trying a 2 call leg conversation when asterisk
>>> is creating the BYE message destinated to the callee after receiving a BYE
>>> message from the caller, and the BYE message by Asterisk reach Kamailio to
>>> then apply the ds_load_update function
>>>
>>> From what i understand about ds_load_update it is that it sets the load
>>> to an specific destination if Kamailio receives a 2xx reply of an INVITE
>>> message, and removes it if Kamailio receives a BYE message based from the
>>> Call-id received in that message, where it is actually failing in my
>>> implementation at the moment
>>>
>>> Here are the blocks of code of the dispatcher parameters and where the
>>> function ds_load_update() is being used:
>>> #!ifdef WITH_LOADBALANCE
>>>
>>> #Parameters using Dispatcher from DB
>>> # ----------
>>> modparam("dispatcher", "db_url", DBURL)
>>> modparam("dispatcher", "table_name", "dispatcher")
>>> # ----------
>>>
>>> #Enabling failover mechanism
>>> # -----------
>>> modparam("dispatcher", "flags", 2)
>>> # -----------
>>>
>>> #Setting dispatcher parameters in AVP
>>> # -----------
>>> modparam("dispatcher", "dst_avp", "$avp(AVP_DST)")
>>> modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)")
>>> modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)")
>>> modparam("dispatcher", "dstid_avp", "$avp(dsdstid)")
>>> # -----------
>>>
>>> #Setting dispatcher result in PV variables
>>> # -----------
>>> modparam("dispatcher", "attrs_pvname", "$var(attrs)")
>>> # -----------
>>>
>>>
>>> #Enabling dispatcher algorithm according to call loads
>>> # -----------
>>> modparam("dispatcher", "ds_hash_size",8)
>>> modparam("dispatcher", "ds_hash_expire", 3600)
>>> modparam("dispatcher", "ds_hash_initexpire", 60)
>>> # -----------
>>>
>>> # Setting parameters for probing dispatcher destinations
>>> # -----------
>>> modparam("dispatcher", "ds_ping_interval", 20)
>>> modparam("dispatcher", "ds_ping_from", "sip:kamailio1@<Kamailio IP>")
>>> modparam("dispatcher", "ds_probing_mode", 1)
>>> modparam("dispatcher", "ds_probing_threshhold", 2)
>>> modparam("dispatcher", "ds_ping_reply_codes",
>>> "class=2;code=480;code=404")
>>> # -----------
>>>
>>> ...
>>> route[WITHINDLG] {
>>>  if (has_totag()) {
>>>   # sequential request withing a dialog should
>>>   # take the path determined by record-routing
>>>
>>> #!ifdef WITH_LOADBALANCE
>>>         if(is_method("BYE|CANCEL")){
>>>                 xlog("L_ERROR","UBICAR BYE ds_load_update
>>>  requesturi=$ru from=$fu method=$rm callid=$ci to=$tu reply=$mt rrcode=$rr
>>> rcode=$rs\n");
>>>                 ds_load_update();
>>>         }
>>> #!endif
>>> ...
>>> }
>>>
>>> ...
>>>
>>> onreply_route[MANAGE_REPLY] {
>>> #!ifdef WITH_LOADBALANCE
>>> if(is_method("INVITE")) {
>>>         if(status=~"2[0-9][0-9]") {
>>>                 xlog("L_ERROR","UBICAR setting ds_load_update
>>>  requesturi=$ru from=$fu method=$rm callid=$ci to=$tu reply=$mt rrcode=$rr
>>> rcode=$rs");
>>>                 ds_load_update();
>>>         }else if(status=~"[3-7][0-9][0-9]") {
>>>                 ds_load_unset();
>>>         }
>>> }
>>> #!endif
>>>
>>> if(status=~"[12][0-9][0-9]"){
>>>         route(NATMANAGE);
>>>  }
>>> }
>>>
>>>
>>> This is what i am getting from logs after the 2 call legs conversation
>>> completes:
>>>
>>> kam1 /usr/sbin/kamailio[4082]: ERROR: <script>: UBICAR: FROMASTERISK
>>> 70175143146f92975a5bff8876435911 at 192.168.10.194
>>>
>>> kam1 /usr/sbin/kamailio[4082]: ERROR: <script>: UBICAR setting
>>> ds_load_update  requesturi=<null> from=sip:103 at 192.168.10.194
>>> method=INVITE callid=28d0f6e71625c9e87baec07f46167863 at 192.168.10.194 to=
>>> sip:104 at 192.168.10.194 reply=2 rrcode=OK rcode=200
>>>
>>> kam1 /usr/sbin/kamailio[4083]: ERROR: <script>: UBICAR setting
>>> ds_load_update  requesturi=<null> from=sip:103 at 192.168.10.194:5060
>>> method=INVITE callid=1-3692 at 192.168.20.2 to=sip:104 at 192.168.10.194:5060
>>> reply=2 rrcode=OK rcode=200
>>>
>>> kam1 /usr/sbin/kamailio[4084]: ERROR: <script>: UBICAR BYE
>>> ds_load_update  requesturi=sip:104 at 192.168.10.190:5060 from=
>>> sip:103 at 192.168.30.1:5060 method=BYE callid=1-3692 at 192.168.20.2 to=
>>> sip:104 at 192.168.30.1:5060 reply=1 rrcode=<null> rcode=<null>
>>>
>>> kam1 /usr/sbin/kamailio[4085]: ERROR: <script>: UBICAR BYE
>>> ds_load_update  requesturi=sip:104 at 192.168.30.2:22523;transport=UDP
>>> from=sip:103 at 192.168.10.194 method=BYE callid=
>>> 28d0f6e71625c9e87baec07f46167863 at 192.168.10.194 to=
>>> sip:104 at 192.168.10.194 reply=1 rrcode=<null> rcode=<null>
>>>
>>> kam1 /usr/sbin/kamailio[4085]: ERROR: dispatcher [dispatch.c:1416]:
>>> ds_load_remove(): cannot find load for (
>>> 28d0f6e71625c9e87baec07f46167863 at 192.168.10.194)
>>>
>>> Kamailio IP: 192.168.10.194
>>>
>>> Asterisk IP:
>>>
>>>
>>> +----+-------+-------------------------+-------+----------+-------------------------------+-------------+
>>> | id | setid | destination             | flags | priority | attrs
>>>                   | description |
>>>
>>> +----+-------+-------------------------+-------+----------+-------------------------------+-------------+
>>> |  1 |     0 | sip:192.168.10.190:5060 |     2 |        0 |
>>> duid=PBX1;my=pbx1;maxload=200 | pbx1        |
>>> |  2 |     0 | sip:192.168.10.191:5060 |     2 |        0 |
>>> duid=PBX2;my=pbx2;maxload=200 | pbx2        |
>>>
>>> +----+-------+-------------------------+-------+----------+-------------------------------+-------------+
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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
>>
>>
>
>
> --
> -
> Saludos a todos
>



-- 
-
Saludos a todos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160404/9b417b58/attachment.html>


More information about the sr-users mailing list