[Serusers] ser 0.10 doucmentation

[Steven C. Blair]

Thanks Jiri. For my application I typically want to compare the R-URI, To user and/or From user to see if the call should be forwarded or not. In addition I need to check the look in the db for an attribute and value pair using the user portion of the r-uri, to or from address as the key.

I'll try to get my aplication working now that I have a little more information.

Thanks,Steve

________________________________________
From: Jiri Kuthan [jiri at iptel.org]
Sent: Wednesday, June 04, 2008 9:05 PM
To: Steven C. Blair
Cc: Martin Hoffmann; serusers at iptel.org
Subject: Re: [Serusers] ser 0.10 doucmentation

> There are several classes of attributes though. This is an extension to
> the old model where attributes where prefixed with "caller_" or
> "callee_" depending on who they were for. This prefix is now "$t." or
> "$f." for "to" and "from". Addtionally, you can have attributes for the
> URI, user, domain, and globally. If you want to address those, the
> prefix gets a second letter t, u, d, g respectively. Thus, "$tu.foo" is
> the variable to for the from user.
>
> [scb] Is URI the same as $ruri in SER0.9.x?

$ruri is unchanged, it stands for the request uri.
example from oob: !@ruri.user  means "if there is no user part in
request uri".

Generally the 1e5-feet perspective is that SER produces a result (i.e.
routing
action typically) based on combination of SIP message elements and user
profiles.
SIP message elements are represented by selects, user profiles by AVPs.
Most AVPs are loaded from the database, even though you may have more of
those.

>
> [scb] Please explain how "$tu.foo" is the variable to for the from user. I do not understand.

well, that's the database thing: it is an AVP named "foo". (presumably
with value "bar" :-))
because in ser processing, a request processing decision may depend both
on caller's
and callee's profile, you need to differentiate. (e.g., call-forwarding
is driven by
recepient's profile, anynomyzation by caller's ... but the script needs
to know).

Thus, if this was a recepient service (such as call-forwarding) you need to
state that by use of the "t" prefix. "$tu.foo" thus means "value of callee's
attribute named 'foo'". The value is loaded from database (from user_attrs
table).

The "u" letter specifically says "user attribute". You could also refer
to domain attributes and global ones, most interesting are the
user-specific ones. If you omit this specification, SER will try to find
the "most specific" attribute, i.e. a user-one if present. If not
present, SER defaults to domain-specific attrributes, in lack of those
to global.


-jiri