5 Jun
2008
5 Jun
'08
4:05 a.m.
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: !(a)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