Hello,
one of the most hidden parts of openser to the config is the branch processing.
Behind a branch is following structure: struct branch { char uri[MAX_URI_SIZE]; unsigned int len;
/* Real destination of the request */ char dst_uri[MAX_URI_SIZE]; unsigned int dst_uri_len;
/* Path vector of the request */ char path[MAX_PATH_SIZE]; unsigned int path_len;
int q; /* Preference of the contact among contact within the array */ struct socket_info* force_send_socket; unsigned int flags; };
I am thinking in offering a fine access to this structure in configuration file, so the admin can control much closer the branch processing. By using while and and index, checks of the attributes in branches could be done. By doing it in main route, one can reduce the overload of stateful processing, by dropping a branch before going to transaction, for example.
I am looking at something similar for user location records. Such a record has many attributes, and from config is no way to access them without doing a lookup and changing r-uri/branches.
There could be many benefits, for example: - being able to detect if a user calls from a registered phone or not - detecting how many contacts a user has at a moment - ability to check and, eventually, drop processing before doing changes to branches and so on...
The access will be provided via pseudo-variables, perhaps the location records will be fetched in variables upon calling a function that gets an AoR as parameter.
I have seen on mailing lists discussions about needs that will be solved by this new feature. Any comments?
Cheers, Daniel
Daniel-Constantin Mierla writes:
I have seen on mailing lists discussions about needs that will be solved by this new feature. Any comments?
daniel,
so far i have not seen a need to access branches in config script. lcr module functions have been enough for me. of course i don't have anything against that kind of access if someone else needs it.
-- juha
On 08/19/08 21:07, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I have seen on mailing lists discussions about needs that will be solved by this new feature. Any comments?
daniel,
so far i have not seen a need to access branches in config script. lcr module functions have been enough for me. of course i don't have anything against that kind of access if someone else needs it.
the main benefit I see is ability to drop branches before creating the transaction, controlling as well the other attributes of a branch (like q value, path)...
Cheers, Daniel
-- juha
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I have seen on mailing lists discussions about needs that will be solved by this new feature. Any comments?
daniel,
so far i have not seen a need to access branches in config script. lcr module functions have been enough for me. of course i don't have anything against that kind of access if someone else needs it.
I need it!
On 08/21/08 09:16, Alex Balashov wrote:
Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I have seen on mailing lists discussions about needs that will be
solved > by this new feature. Any comments?
daniel,
so far i have not seen a need to access branches in config script. lcr module functions have been enough for me. of course i don't have anything against that kind of access if someone else needs it.
I need it!
somehow related, analyzing the list of pseudo-variables exported by core, there are some that don't seem to be that often used (maybe it is just me), so I am thinking in creating a new module to migrate from core some variables.
I am thinking to keep in core - avps - headers - var - R-URI, From URI and To URI and destination URI related variables - auth tokens (username, realm)
If you think about others that should be in core, please add here. The new branch related PV will be in the new module. The target is release the core as much as possible, keeping there what is very often used.
As module name, pvcore is an idea -- pseudo-variables related to core (as there are PV exported by other modules as well, strictly related to that particular modules).
Cheers, Daniel
On Thursday 21 August 2008, Daniel-Constantin Mierla wrote:
I am thinking to keep in core
- avps
- headers
- var
- R-URI, From URI and To URI and destination URI related variables
- auth tokens (username, realm)
Hi Daniel,
this initial list looks good so far. But why we not move all PVs into the module, as Juha suggested? Ok, this would be a little more work for the users, in changing their configuration, but do you see any technical or maintainance reasons?
If you think about others that should be in core, please add here. The new branch related PV will be in the new module. The target is release the core as much as possible, keeping there what is very often used.
As module name, pvcore is an idea -- pseudo-variables related to core (as there are PV exported by other modules as well, strictly related to that particular modules).
pvcore is not bad, perhaps we can even shorten this to "pv"?
Cheers,
Henning
Hello,
On 08/22/08 14:48, Henning Westerholt wrote:
On Thursday 21 August 2008, Daniel-Constantin Mierla wrote:
I am thinking to keep in core
- avps
- headers
- var
- R-URI, From URI and To URI and destination URI related variables
- auth tokens (username, realm)
Hi Daniel,
this initial list looks good so far. But why we not move all PVs into the module, as Juha suggested? Ok, this would be a little more work for the users, in changing their configuration, but do you see any technical or maintainance reasons?
there are no reasons, technical or maintenance, that would stop having all in module(s). It is even better as core will be lighter, I was thinking just to user commodity.
Cheers, Daniel
If you think about others that should be in core, please add here. The new branch related PV will be in the new module. The target is release the core as much as possible, keeping there what is very often used.
As module name, pvcore is an idea -- pseudo-variables related to core (as there are PV exported by other modules as well, strictly related to that particular modules).
pvcore is not bad, perhaps we can even shorten this to "pv"?
Cheers,
Henning
Henning Westerholt writes:
I am thinking to keep in core
- avps
- headers
- var
- R-URI, From URI and To URI and destination URI related variables
- auth tokens (username, realm)
as an example of difficulty of making the selection, From URI is not more important than, for example, P-Preferred-Identity or P-Assured-Identity header, since you have to look all of them in order to find out the real "from uri".
to me only Request-URI would stand as the most important, but still i would prefer a clean (all or noting), rather than an ad hoc, selection.
-- juha
-
Alex Balashov -
Daniel-Constantin Mierla -
Henning Westerholt -
jh＠tutpro.com