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) On the "what's new site" in the avps and selects article I found another method which performs similar task: lookup_user("$tu","@ruri")
What is the difference between those to methods?? Are they part of the SER core? previously in ser 0.9.x I have it done by, first loading the avp by avp_db_load() and then in case of call forwarding by making avp_pushto("$ruri","something") or rewriteuri() and then t_relay(). What is now a preferred way to realized similar functions. I mean can I utilize those methods like load_attrs or lookup_user() and then substitute the ruri without avp_pushto or rewriteuri??
best tomasz
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)
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.
If this call was successful (e.g. it is your known subscriber) you can continue and call load_attrs which will load the user attributes.
should be used (for example): if (!lookup_user("$tu","@ruri")) { t_reply("404", "Unknown user"); drop; }
if (!load_attrs("$tu", "$t.uid")) { # might happen, that there are no attrs }
if ($t.call_forward) { ... your code here }
Check the ser.cfg from CVS, it is using this approach of handling attributes.
What is the difference between those to methods?? Are they part of the SER core?
Pay attention to the caller/callee attributes (e.g. from/to track (the letter before the dot in the avp name))
No, uri_db module.
previously in ser 0.9.x I have it done by, first loading the avp by avp_db_load() and then in case of call forwarding by making avp_pushto("$ruri","something") or rewriteuri() and then t_relay(). What is now a preferred way to realized similar functions. I mean can I utilize those methods like load_attrs or lookup_user() and then substitute the ruri without avp_pushto or rewriteuri??
Yes, it was intended to replace functions from the avp_db module.
Michal
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 and then this uid avp will be accessible through $tu.uid or $t.uid?? If yes then does it load any other attributes?? Are the data loaded from the user_attrs table?? Is there a documentation for this functions: lookup-user and load_attrs because I have doubts what for the first "$tu" value stands for?
If this call was successful (e.g. it is your known subscriber) you can continue and call load_attrs which will load the user attributes.
should be used (for example): if (!lookup_user("$tu","@ruri")) { t_reply("404", "Unknown user"); drop; }
if (!load_attrs("$tu", "$t.uid")) { # might happen, that there are no attrs }
if ($t.call_forward) { ... your code here }
Check the ser.cfg from CVS, it is using this approach of handling attributes.
What is the difference between those to methods?? Are they part of the SER core?
Pay attention to the caller/callee attributes (e.g. from/to track (the letter before the dot in the avp name))
No, uri_db module.
previously in ser 0.9.x I have it done by, first loading the avp by avp_db_load() and then in case of call forwarding by making avp_pushto("$ruri","something") or rewriteuri() and then t_relay(). What is now a preferred way to realized similar functions. I mean can I utilize those methods like load_attrs or lookup_user() and then substitute the ruri without avp_pushto or rewriteuri??
Yes, it was intended to replace functions from the avp_db module.
Michal
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
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
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?
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?
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
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