4 Jun
2008
4 Jun
'08
10:36 p.m.
Steven C. Blair wrote:
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.
For accessing the SIP elements, there is the select operator.
examples:
@from.uri.host
@to.tag
for a full list of those, check interactive doc:
http://www.iptel.org/ser/doc/search
unselect all but "S" for selects.
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.
load then AVPs from DB as in the OOB config file (load_attrs("$tu",
"$t.uid"); load_attrs("$fu", "$f.uid");) and use them as in
the example
before (e.g. $fu.foo)
-jiri
I'll try to get my aplication working now that I have a little more information.
Thanks,Steve
________________________________________
From: Jiri Kuthan [jiri(a)iptel.org]
Sent: Wednesday, June 04, 2008 9:05 PM
To: Steven C. Blair
Cc: Martin Hoffmann; serusers(a)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: !(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
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers