28 Sep
2010
28 Sep
'10
3:12 p.m.
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>:
--
Carsten Bock
Schomburgstr. 80
22767 Hamburg
Germany
Mobile +49 179 2021244
Home +49 40 34927217
Fax +49 40 34927218
mailto:carsten@bock.info
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:
--
Carsten Bock
Schomburgstr. 80
22767 Hamburg
Germany
Mobile +49 179 2021244
Home +49 40 34927217
Fax +49 40 34927218
mailto:carsten@bock.info
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>:
--
Daniel-Constantin Mierla
http://www.asipto.com
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