make dispatcher more flexible - (was: [asterisk-dev] [Code Review] SIP: authenticate OPTIONS requests just like we would an INVITE)
Hi!
Recently Asterisk implemented authentication of incoming OPTIONS request. This means, that OPTIONS might be challenged - responding with 401/407.
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.
regards klaus
-------- Original-Nachricht -------- Betreff: Re: [asterisk-dev] [Code Review] SIP: authenticate OPTIONS requests just like we would an INVITE Datum: Fri, 3 Sep 2010 13:07:18 -0500 (CDT) Von: David Vossel dvossel@digium.com Antwort an: Asterisk Developers Mailing List asterisk-dev@lists.digium.com An: Asterisk Developers Mailing List asterisk-dev@lists.digium.com
----- Original Message -----
From: "Klaus Darilion" klaus.mailinglists@pernau.at To: "Asterisk Developers Mailing List" asterisk-dev@lists.digium.com Cc: "Olle E. Johansson" oej@edvina.net Sent: Wednesday, September 1, 2010 12:53:41 PM Subject: Re: [asterisk-dev] [Code Review] SIP: authenticate OPTIONS requests just like we would an INVITE
looks like 401 will be an error, only 200, 501, 403 and 405 will be accepted. So we have to add 401 for Asterisk? ;-)
Yes, it appears the 401 response will have to be added there. Do you have commit access to this project? How can we get that done?
David Vossel Digium, Inc. | Software Developer, Open Source Software 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com & www.asterisk.org The_Boy_Wonder in #asterisk-dev
2010/9/6 Klaus Darilion klaus.mailinglists@pernau.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).
On 9/6/10 11:20 AM, Iñaki Baz Castillo wrote:
2010/9/6 Klaus Darilionklaus.mailinglists@pernau.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
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@gmail.com:
On 9/6/10 11:20 AM, Iñaki Baz Castillo wrote:
2010/9/6 Klaus Darilionklaus.mailinglists@pernau.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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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@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@gmail.com:
On 9/6/10 11:20 AM, Iñaki Baz Castillo wrote:
2010/9/6 Klaus Darilionklaus.mailinglists@pernau.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@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
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@gmail.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@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@gmail.com:
On 9/6/10 11:20 AM, Iñaki Baz Castillo wrote:
2010/9/6 Klaus Darilionklaus.mailinglists@pernau.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@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
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 Mierlamiconda@gmail.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 Bocklists@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 Mierlamiconda@gmail.com:
On 9/6/10 11:20 AM, Iñaki Baz Castillo wrote:
2010/9/6 Klaus Darilionklaus.mailinglists@pernau.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@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
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@gmail.com:
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 Mierlamiconda@gmail.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 Bocklists@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 Mierlamiconda@gmail.com:
On 9/6/10 11:20 AM, Iñaki Baz Castillo wrote:
2010/9/6 Klaus Darilionklaus.mailinglists@pernau.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@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
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@bock.info:
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@gmail.com:
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 Mierlamiconda@gmail.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 Bocklists@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 Mierlamiconda@gmail.com:
On 9/6/10 11:20 AM, Iñaki Baz Castillo wrote: > > 2010/9/6 Klaus Darilionklaus.mailinglists@pernau.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@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
Hi Carsten,
I see some changes regarding attrs and priority fields in the patch: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blobdiff;f=modul...
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 Bocklists@bock.info:
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 Mierlamiconda@gmail.com:
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 Mierlamiconda@gmail.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 Bocklists@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 Mierlamiconda@gmail.com: > On 9/6/10 11:20 AM, Iñaki Baz Castillo wrote: >> 2010/9/6 Klaus Darilionklaus.mailinglists@pernau.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@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
Hi Daniel,
yes, correct, i forgot to mention: I have noticed a bug, when loading the dispatcher-list from file. The attrs where not initialized, so they had in some cases invalid values, when not set. The proxy would not start due to an invalid value in the dispatcher-list file. I changed the initialization of variables; the priority was initialized twice (that's why i removed that line).
Carsten
2010/9/28 Daniel-Constantin Mierla miconda@gmail.com:
Hi Carsten,
I see some changes regarding attrs and priority fields in the patch: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blobdiff;f=modul...
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 Bocklists@bock.info:
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 Mierlamiconda@gmail.com:
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 Mierlamiconda@gmail.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 Bocklists@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 Mierlamiconda@gmail.com: >> >> On 9/6/10 11:20 AM, Iñaki Baz Castillo wrote: >>> >>> 2010/9/6 Klaus Darilionklaus.mailinglists@pernau.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@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
-- Daniel-Constantin Mierla http://www.asipto.com
Hi,
i just commited my enhancement to the master. I replaced the original implementation from my branch for something more useful. You may now set some valid reply codes the following way:
modparam("dispatcher", "ds_ping_reply_codes", "class=2;code=403;code=488")
In order to set all codes of class 2 as valid (200-299) and the codes 403 and 488. These values may be set at runtime using the cfg-framework of the proxy, e.g. if you notice that a gateway is replying with something else to your options requests.
Kind regards, Carsten
2010/9/28 Carsten Bock lists@bock.info:
Hi Daniel,
yes, correct, i forgot to mention: I have noticed a bug, when loading the dispatcher-list from file. The attrs where not initialized, so they had in some cases invalid values, when not set. The proxy would not start due to an invalid value in the dispatcher-list file. I changed the initialization of variables; the priority was initialized twice (that's why i removed that line).
Carsten
2010/9/28 Daniel-Constantin Mierla miconda@gmail.com:
Hi Carsten,
I see some changes regarding attrs and priority fields in the patch: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blobdiff;f=modul...
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 Bocklists@bock.info:
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 Mierlamiconda@gmail.com:
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 Mierlamiconda@gmail.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 Bocklists@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 Mierlamiconda@gmail.com: >>> >>> On 9/6/10 11:20 AM, Iñaki Baz Castillo wrote: >>>> >>>> 2010/9/6 Klaus Darilionklaus.mailinglists@pernau.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@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
-- 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
Hello,
On 9/29/10 6:21 PM, Carsten Bock wrote:
Hi,
i just commited my enhancement to the master. I replaced the original implementation from my branch for something more useful. You may now set some valid reply codes the following way:
modparam("dispatcher", "ds_ping_reply_codes", "class=2;code=403;code=488")
thank you!
Daniel
In order to set all codes of class 2 as valid (200-299) and the codes 403 and 488. These values may be set at runtime using the cfg-framework of the proxy, e.g. if you notice that a gateway is replying with something else to your options requests.
Kind regards, Carsten
2010/9/28 Carsten Bocklists@bock.info:
Hi Daniel,
yes, correct, i forgot to mention: I have noticed a bug, when loading the dispatcher-list from file. The attrs where not initialized, so they had in some cases invalid values, when not set. The proxy would not start due to an invalid value in the dispatcher-list file. I changed the initialization of variables; the priority was initialized twice (that's why i removed that line).
Carsten
2010/9/28 Daniel-Constantin Mierlamiconda@gmail.com:
Hi Carsten,
I see some changes regarding attrs and priority fields in the patch: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blobdiff;f=modul...
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 Bocklists@bock.info:
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 Mierlamiconda@gmail.com:
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 Mierlamiconda@gmail.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 Bocklists@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 Mierlamiconda@gmail.com: >>>> On 9/6/10 11:20 AM, Iñaki Baz Castillo wrote: >>>>> 2010/9/6 Klaus Darilionklaus.mailinglists@pernau.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@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
-- 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
-
Carsten Bock -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion