Hi Carsten,
I see some changes regarding attrs and priority fields in the patch:
While attrs init seems to be moved up, i couldn't spot where priority went.
Were there any issues?
Cheers,
Daniel
On 9/28/10 2:12 PM, Carsten Bock wrote:
Hi Daniel,
i have just updated the dispatcher module regarding your comment
(although a little different, i parse the values upon change).
Also i've made the probing_threshhold configurable.
I will do some more tests and then push my changes into master (they
are currently in my dispatcher-branch).
Carsten
2010/9/24 Carsten Bock<lists(a)bock.info>fo>:
> Hi Daniel,
>
> i definitely should take a look at it, at least just out of curiosity ;-)
> I will try to find some time next week to adapt it.
>
> Carsten
>
> 2010/9/22 Daniel-Constantin Mierla<miconda(a)gmail.com>om>:
>> Hi Carsten,
>>
>> I was thinking to an approach that uses the new cfg parameter framework
>> (you
>> can see modules_k/registrar for some example with several parameters
>> already
>> migrated to this), since that allows to set the value at runtime without
>> restart, also, if I am not wrong, you can load its value at start up
>> from db
>> with cfg_db module.
>>
>> The idea is to keep the list of reply codes as string, comma separated
>> list,
>> like "401,404,407", then use strstr(replycodelist, code) to match the
>> code
>> inside it. Might be slightly slower that parsing at startup and
>> comparing as
>> integer, but:
>> - you get reload without restart
>> - you can manage the value in db
>>
>> Anyhow, most of the cases would be 200 reply, therefore handled before
>> checking the extra list. In the future we can look to improve by
>> detecting
>> the change at runtime and parsing, but I think doesn't bring much
>> difference.
>>
>> What do you think? If people think is better approach, I can take care
>> if
>> none else volunteers.
>>
>> Cheers,
>> Daniel
>>
>> On 9/22/10 12:57 PM, Carsten Bock wrote:
>>> Hi,
>>>
>>> i have just commited my changes into a branch (carstenbock/dispatcher).
>>> Please check, if these changes meet your requirements.
>>>
>>> Carsten
>>>
>>>
>>> 2010/9/14 Daniel-Constantin Mierla<miconda(a)gmail.com>om>:
>>>> Hi Carsten,
>>>>
>>>> go ahead if you have time, I had no time for it when I fixed call load
>>>> algorithm, being still left in the to-do list.
>>>>
>>>> Thanks,
>>>> Daniel
>>>>
>>>> On Tue, Sep 14, 2010 at 3:31 PM, Carsten Bock<lists(a)bock.info>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> has anyone started on this issue? If not, i will implement this
>>>>> feature in the following days...
>>>>>
>>>>> Carsten
>>>>>
>>>>> 2010/9/6 Daniel-Constantin Mierla<miconda(a)gmail.com>om>:
>>>>>> On 9/6/10 11:20 AM, Iñaki Baz Castillo wrote:
>>>>>>> 2010/9/6 Klaus Darilion<klaus.mailinglists(a)pernau.at>at>:
>>>>>>>> Currently, the respone codes which are accept by
dispatcher module
>>>>>>>> as
>>>>>>>> SUCCESS are hard coded. Maybe there should be a
configuration
>>>>>>>> option
>>>>>>>> to
>>>>>>>> configure SUCCESS response code.
>>>>>>> As LCR had (prior to 3.0).
>>>>>> yes, that can be changed from hardcoded to param, it would give
more
>>>>>> flexibility. If none does it, I can look into it when I get to
>>>>>> testing
>>>>>> of
>>>>>> new features in dispatcher these days.
>>>>>>
>>>>>> Cheers,
>>>>>> Daniel
>>>>>>
>>>>>> --
>>>>>> Daniel-Constantin Mierla
>>>>>>
http://www.asipto.com
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> sr-dev mailing list
>>>>>> sr-dev(a)lists.sip-router.org
>>>>>>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>>>>
>>>>> --
>>>>> Carsten Bock
>>>>> Schomburgstr. 80
>>>>> 22767 Hamburg
>>>>> Germany
>>>>>
>>>>> Mobile +49 179 2021244
>>>>> Home +49 40 34927217
>>>>> Fax +49 40 34927218
>>>>> mailto:carsten@bock.info
>>>> --
>>>> Daniel-Constantin Mierla
>>>>
http://www.asipto.com
>>>>
>> --
>> Daniel-Constantin Mierla
>>
http://www.asipto.com
>>
>>
>
> --
> Carsten Bock
> Schomburgstr. 80
> 22767 Hamburg
> Germany
>
> Mobile +49 179 2021244
> Home +49 40 34927217
> Fax +49 40 34927218
> mailto:carsten@bock.info
>