Hi Daniel
Thank you very much for looking into it.
I don't see us setting a value to the avp. We aren't even using the avp at
present:
#!ifdef WITH_DISPATCHER_LOAD_AWARE
modparam("dispatcher", "dstid_avp", "$avp(dsdstid)")
modparam("dispatcher", "ds_hash_size", 8)
#!endif
We have the directive for WITH_DISPATCHER_LOAD_AWARE off at the moment.
After reading this email I went through my code to find all the places that
we reference the dispatcher.
I was planning on copy and pasting the code blocks to you but in the
process I found the issue in a spot I wasn't expecting.
route[WITHINDLG] {
xlog("L_DEBUG", "route WITHINDLG: will -- DLG triggered, request method:
$rm \n");
#!ifdef WITH_DISPATCHER
if(is_method("BYE|CANCEL")) {
xlog("L_DEBUG","route WITHINDLG: cancel or bye detected, request method:
$rm \n");
*ds_load_update*();
#dlg_get ("$ci","$ft","$tt");
#dlg_bye ("all");
}
#!endif
Running the ds_load_update seems like it was triggering the error.
I changed this block to this:
route[WITHINDLG] {
xlog("L_DEBUG", "route WITHINDLG: will -- DLG triggered, request method:
$rm \n");
#!ifdef WITH_DISPATCHER
if(is_method("BYE|CANCEL")) {
xlog("L_DEBUG","route WITHINDLG: cancel or bye detected, request method:
$rm \n");
#!ifdef WITH_DISPATCHER_LOAD_AWARE
xlog("L_DEBUG","route WITHINDLG: running ds_load_update, request method:
$rm \n");
ds_load_update();
#dlg_get ("$ci","$ft","$tt");
#dlg_bye ("all");
#!endif
}
#!endif
And now I don't see the error any more.
If the error shouldn't have been showing up I am happy to send you more of
the config to look at it if it's useful.
Thanks again very much for your help figuring out the issue.
I hope you have a great holidays.
Will Ferrer
Switchsoft Inc
On Mon, Dec 22, 2014 at 1:51 PM, Daniel-Constantin Mierla <mico...@gmail.com
> wrote:
> Hello,
>
> got the time to look more at the code. The value for dstid_avp is added
> only for algorithm 10 (call load). It is not about the name of the avp, but
> the value of the avp. Do you set this avp in routing blocks? If this avp
> has a value, it assumes to be a call load distribution and the error
> message is printed.
>
> Cheers,
> Daniel
>
>
> On 10/12/14 23:00, Will Ferrer wrote:
>
> Hi Daniel
>
> Sounds great. Thanks again for everything and happy holidays.
>
> All the best
>
> Will
>
> On Wed, Dec 10, 2014 at 3:28 AM, Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> Hello,
>>
>> I will look into it as soon as possible - again, it is harmless overall,
>> but shouldn't be a log message if it is not an issue there.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 10/12/14 02:14, Will Ferrer wrote:
>>
>> Hi Daniel
>>
>> I seem to see be having the issue with out with out defining
>> the dstid_avp. I guess it's a non issue but was wondering if there was a
>> way to make it go away.
>>
>> Thanks again for the assistance.
>>
>> Will
>>
>> On Tue, Dec 9, 2014 at 4:06 PM, Will Ferrer <will.fer...@switchsoft.com>
>> wrote:
>>
>>> Hi Daniel
>>>
>>> Thanks for the write back.
>>>
>>> We are using the dstid_avp but we are not using alg 10 for call load
>>> distribution.
>>>
>>> We have dstid_avp set because the distribution alg is a directive we
>>> set for the deployment via the local.cfg. We leave the avp for it on incase
>>> we switch the deployment to alg 10.
>>>
>>> I think that is probably the cause of the issue. Sound about right?
>>>
>>> Thanks again for your assistance.
>>>
>>> All the best.
>>>
>>> Will Ferrer
>>>
>>> On Tue, Dec 9, 2014 at 4:49 AM, Daniel-Constantin Mierla <
>>> mico...@gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> do you use call load dispatching algorithm or have the dstid attribute
>>>> set?
>>>>
>>>> The log is harmless itself if not using the call load dispatching
>>>> algorithm.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>> On 05/12/14 02:03, Will Ferrer wrote:
>>>>
>>>> Hi All
>>>>
>>>> We recently discovered that our dispatcher boxes have this error
>>>> constantly at the end of our calls.
>>>>
>>>> ERROR: dispatcher [dispatch.c:1402]: ds_load_remove(): cannot find
>>>> load for (<callid goes here>)
>>>>
>>>> We aren't seeing any issues arising from it that we can notice but
>>>> wanted to see if any one knew what it meant and what it might cause.
>>>>
>>>> Thanks much in advance.
>>>>
>>>> All the best
>>>>
>>>> Will Ferrer
>>>>
>>>> Switchsoft Inc
>>>>
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>>>> listsr-us...@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@lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>
>>
>> --
>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
>> http://www.linkedin.com/in/miconda
>>
>>
>
> --
> 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@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
