[Serusers] ser 0.10.99 - call forwarding issue

[Michal Matyska]

On Wed, 2007-01-31 at 14:27 +0100, tzieleniewski wrote:
> > On Wed, 2007-01-31 at 13:37 +0100, tzieleniewski wrote:
> > > Thanks for Your answer some more question below:)
> > > 
> > > > 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 
> > Yes
> > 
> > > 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
> > 
> 
> So in case of user track the uid column is checked and in case of uri track username column?

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)


> > 
> > 
> > > 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:
> >
> 
> 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.


> > 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
> >