6 Jun
2018
6 Jun
'18
8:53 a.m.
Hello,
I am starting a discussion here about my plans to do a bit of
refactoring to dispatcher module and gather some feedback if people
think of other improvements.
1) First is about moving from using avps to xavps. It should simplify at
least the config in terms of modparams, but also makes it more coherent
in storing the details of destination record for serial forking.
Practically, from a bunch of avp parameters, there will be one to set
the root xavp name, and the old "avps" will be fields inside the xavp.
2) The second is about the attributes field. I am considering to add the
option to load additional attributes from dedicated columns when using
database. So besides the attrs column, one can specify via a mod param
additional columns to be loaded and added to attributes, like:
modparam("dispatcher", "xattrs", "weight,socket,maxload")
The attributes string will be the value of "attrs" column concatenated
with "weight=val1;socket=val2;maxload=val3" (the valX being the
corresponding values in those columns).
This should make easier the management of the database records. For the
option with a text file, no changes will be done.
3) Anything else that one thinks would be good to add to dispatcher?
Cheers,
Daniel
PS. I wrote to both sr-dev and sr-users, to get the attention of the two
communities. However, you can reply only to sr-users (larger community)
if you are not on sr-dev, because this discussion is about features of
the module, not technical aspects of coding.
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
6 Jun
6 Jun
11:40 a.m.
Hi Daniel,
love the idea!
just to be sure i understand...,
current params declaration
modparam("dispatcher", "dst_avp", "$avp(ds_dst)")
modparam("dispatcher", "attrs_avp", "$avp(ds_attrs)")
new params declaration
modparam("dispatcher", "dst_xavp", "$xavp(ds_dst)")
##modparam("dispatcher", "attrs_avp", "$avp(ds_attrs)")
instead of using $avp(ds_dst) to get the uri we would use $xavp(ds_dst=>uri) ?
instead of parsing the $avp(ds_attrs) to get the required param we would use
$xavp(ds_dst=>my_extra_column) ?
Best
________________________________
From: sr-users <sr-users-bounces(a)lists.kamailio.org> on behalf of Daniel-Constantin
Mierla <miconda(a)gmail.com>
Sent: Wednesday, June 6, 2018 7:53:24 AM
To: Kamailio (SER) - Devel Mailing List; Kamailio (SER) - Users Mailing List
Subject: [SR-Users] RFC: dispatcher refactoring to use xavp and options for attributes
Hello,
I am starting a discussion here about my plans to do a bit of
refactoring to dispatcher module and gather some feedback if people
think of other improvements.
1) First is about moving from using avps to xavps. It should simplify at
least the config in terms of modparams, but also makes it more coherent
in storing the details of destination record for serial forking.
Practically, from a bunch of avp parameters, there will be one to set
the root xavp name, and the old "avps" will be fields inside the xavp.
2) The second is about the attributes field. I am considering to add the
option to load additional attributes from dedicated columns when using
database. So besides the attrs column, one can specify via a mod param
additional columns to be loaded and added to attributes, like:
modparam("dispatcher", "xattrs", "weight,socket,maxload")
The attributes string will be the value of "attrs" column concatenated
with "weight=val1;socket=val2;maxload=val3" (the valX being the
corresponding values in those columns).
This should make easier the management of the database records. For the
option with a text file, no changes will be done.
3) Anything else that one thinks would be good to add to dispatcher?
Cheers,
Daniel
PS. I wrote to both sr-dev and sr-users, to get the attention of the two
communities. However, you can reply only to sr-users (larger community)
if you are not on sr-dev, because this discussion is about features of
the module, not technical aspects of coding.
--
Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com>
www.twitter.com/miconda<http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>
Kamailio World Conference -- www.kamailioworld.com<http://www.kamailioworld.com>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
6:27 p.m.
New subject: RFC: dispatcher refactoring to use xavp and options for attributes
Hello,
something like that, maybe the parameter value will be only the name of
the xavp, similar to xavp_cfg for registrar.
For attrs and extra columns, I was thinking of concatenating all of them
in 'attrs' field and have also separate those with a specific meaning
(like socket, weight, ...) -- this is more or less what is now with
avps, one having all in avp_attrs param and then some with dedicated avps.
Having all of them in a single string is useful when one wants to add
them to headers, etc. Parsing can be done with {param} transformation.
However, having them on a dedicated xavp sub-field, can be added in the
future.
Cheers,
Daniel
On 06.06.18 11:40, Luis Azedo wrote:
Hi Daniel,
love the idea!
just to be sure i understand...,
current params declaration
modparam("dispatcher", "dst_avp", "$avp(ds_dst)")
modparam("dispatcher", "attrs_avp", "$avp(ds_attrs)")
new params declaration
modparam("dispatcher", "dst_xavp", "$xavp(ds_dst)")
##modparam("dispatcher", "attrs_avp", "$avp(ds_attrs)")
instead of using $avp(ds_dst) to get the uri we would
use $xavp(ds_dst=>uri) ?
instead of parsing the $avp(ds_attrs) to get the required param we
would use $xavp(ds_dst=>my_extra_column) ?
Best
------------------------------------------------------------------------
*From:* sr-users <sr-users-bounces(a)lists.kamailio.org> on behalf of
Daniel-Constantin Mierla <miconda(a)gmail.com>
*Sent:* Wednesday, June 6, 2018 7:53:24 AM
*To:* Kamailio (SER) - Devel Mailing List; Kamailio (SER) - Users
Mailing List
*Subject:* [SR-Users] RFC: dispatcher refactoring to use xavp and
options for attributes
Hello,
I am starting a discussion here about my plans to do a bit of
refactoring to dispatcher module and gather some feedback if people
think of other improvements.
1) First is about moving from using avps to xavps. It should simplify at
least the config in terms of modparams, but also makes it more coherent
in storing the details of destination record for serial forking.
Practically, from a bunch of avp parameters, there will be one to set
the root xavp name, and the old "avps" will be fields inside the xavp.
2) The second is about the attributes field. I am considering to add the
option to load additional attributes from dedicated columns when using
database. So besides the attrs column, one can specify via a mod param
additional columns to be loaded and added to attributes, like:
modparam("dispatcher", "xattrs", "weight,socket,maxload")
The attributes string will be the value of "attrs" column concatenated
with "weight=val1;socket=val2;maxload=val3" (the valX being the
corresponding values in those columns).
This should make easier the management of the database records. For the
option with a text file, no changes will be done.
3) Anything else that one thinks would be good to add to dispatcher?
Cheers,
Daniel
PS. I wrote to both sr-dev and sr-users, to get the attention of the two
communities. However, you can reply only to sr-users (larger community)
if you are not on sr-dev, because this discussion is about features of
the module, not technical aspects of coding.
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio World Conference -- www.kamailioworld.com
<http://www.kamailioworld.com>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
2178
days inactive
2178
days old
2 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Luis Azedo