1 Feb
2007
1 Feb
'07
8:38 p.m.
On Wed, 2007-01-31 at 14:27 +0100, tzieleniewski wrote:
loading from user_attrs uses uid as a key
loading from uri_attrs uses scheme username and did as a key
both are (well, uri_attrs should be) checking the flags column to have
set bits DB_LOAD_SER and DB_IS_TO / DB_IS_FROM for the TO / FROM track.
So you can divide the attributes for originating and terminating
processing.
did for uri_attrs it is looked as part of the function call (using
domain table) or _default (if not found, e.g. tel uri or simple setup
without domain provisioning)
what is the result when we use one parameter, does it cause that uid is
"placed" in the general class so it can be accessed by "$uid"?? And
those 3 possible parameters to look for the uid wich corresponds to those values in the
sip message?
which table is searched by methode lookup_user,
is it the same like in the load_attrs?
No, using From it uses From header and puts result into FROM / USER.
Using To uses value of To header, using Request-URI uses request-uri
(what surprise :-) and puts attr into TO / USER.
GENERAL class is handled by the gflags module (both 32 single bits and
named attributes as e.g. system wide default values). Both from/to
tracks in general class share the same list.
DOMAIN class is handled by domain module, it is read-only from the
script.
On Wed,
2007-01-31 at 13:37 +0100, tzieleniewski wrote:
So in case of user track the uid column is checked and in case of uri track username
column? Thanks for Your answer some more question
below:)
Yes
On Wed, 2007-01-31 at 12:32 +0100, tzieleniewski
wrote:
> hi!
>
> I am trying to set up the call forwarding feature and I have some question bout the
idea how to realize this.
>
> My Idea was to do it with the usage of avp's.
> First thing I do is the check if there is a call_forward parameter set in the
database in user_attrs table.
> I do this by invoking load_attrs("$fu", "$f.uid");
> and then I do the check if ($tu.call_forward)
Sorry here my copy/paste error,
wrong line I was considering load_attrs("$tu","$f.uid")
This will NOT work for sure as you load attributes for the caller
(FROM/USER based on the FROM uid attr) and then check the callees
preferences (TO/USER call_forward attribute).
It is not clear whether you have already $f.uid set (using either
lookup_user or authenticate function call).
> On the "what's new site" in the avps and selects article I found
another method which performs similar task:
lookup_user("$tu","@ruri")
lookup_user just creates AVP named uid with the value found in database.
so it
simply
Just make sure if I understood right:
So lookup_user loads from the database (check if exists) a uid value from record
corresponding to "@ruri" select value and then this uid avp will be accessible through
$tu.uid or $t.uid??
Yes
If yes then does it load any other attributes??
No, load_attrs must be called from the script.
Are the data loaded from the user_attrs table??
first parameter of load_attrs specifies the class and track
$tu - TO/USER
$tr - TO/URI
$fu - FROM/USER
$fr - FROM/URI
it also denotes whether user_attrs (key is uid) or uri_attrs (key is
uri) tables will be used and to which AVP class/track.
second parameter is either uid or the uri
Is there a documentation for this functions:
lookup-user and load_attrs because I have doubts what for the first "$tu" value
stands for?
lookup_user might be used with one parameter (string "From", "To",
"request-uri") or two parameters:
> first is the TRACK(/CLASS - should always use
user)
> second is the uri which it lookups
>
> so you can easily use P-Asserted-Identity instead of From header.
>
>
>
> Unfortunatelly the documentation is missing or too old (generally, new
> features especially).
>
> Michal
>