19 Jan
2006
19 Jan
'06
1:13 p.m.
Hi Bogdan,
First we have to make a clear distinction between whom
the
AVP belong to (an identification in order to find it 0
this is more an abstract aspect) and where the AVP is kept:
- identification: there are currently two ways of
identifying an avp
- either as belonging to a user (user and domain), either via an uid
(unique ID). What is the meaning of the uid, it's a matter of
interpretation for the user - it may be a domain ID, a dialog ID
...whatever... I thing this identification mechanism gives
full liberty.
Actually identifying ans AVP based on user@domain is a
special case of a UID, where the UID is the a sip uri (this
just an simplification for one of the most used case).
The unique ID is the first requirement, so far everything OK.
- where the AVP id kept - currently they are kept
into
transactions.
So they are accessible only their transaction is currently is
progress and their lifetime is the same as the transaction's
one.
I see. Unfortunately, there are many cases when it is required
to have AVPs available for the duration of a dialog or, even
more severe, for the duration of a user registration.
The only way how we can store and retrieve this information
right now is to store the corresponding AVPs into the DBS
table.
And here is the REAL problem: We can not use call-dependent
data (e.g., the call-id) as a NAME to store and retrieve
data. I.e., with the current avp_db_load and avp_db_store
interfaces we are not able to retrieve call-dependent information
from the DBS.
Now...about improvements.....For identifications....I would say it
covers all cases..no idea what can be added - any suggestions
are welcome.
You're right, as long as the AVP is required only during the
transaction.
regarding the AVP location..this is a different story
- I was
thinkings about adding new support: AVP per script (the AVP
belong to the script - kind of script variables and may be used
for temporary ops)
and global AVP ( present in all the time, in all places - no
restrictions; may be used to control the overall behaviour of
the proxy).
The global AVP seems interesting (e.g. for storing Registration-
lifetime AVPs), I do not see the immediate use for script-scoped
variables but might miss something.
And maybe
(again...maybe) in the future AVP per dialog (they belong to
a dialog).
THIS is exactly what can solve our problem. Our call-id-based
name for the persistently-stored AVP is just a work-around for
not having dialog-scoped AVPs available.
So, thinking about a short-term solution for globally-scoped
AVPs one question: is there a specific reason why the AVP module
disallows/does not implement the use of transaction-specific
AVP _VALUES_ as key/name of the database-stored AVP?
Like written in my initial mail, I'd like to be able to do
something like:
avp_db_store("s:myTmpHeaderName","s:myTmpHeaderValue");
or
avp_db_store("$hdr(call-id)","s:myTmpHeaderValue");
Afai understand your writing, the AVP concept allows
any unique identifier to be used as name for database-
stored AVPs.
I'm considering here just avp_db_load and avp_db_store!
Is there any specific reason why the above-mentioned
usage for AVP names is not implemented?
To summarize: Our extensions and our use of OpenSER might
be slightly proprietary and different from what other users
do, but we realized the need to have AVPs at other scope
than transaction, too.
Specifically, the following lifetimes are currently needed
for our AVPs (I guess, there are other developers, too,
that will come into the same situation):
1. AVP lifetime dialog
2. AVP lifetime registration (or per-contact, or global
scope with ability to use
call variables as name)
Hope I manage to bring some light ;)
Definitely, but it raised again some new questions.
Thanks again for your help,
regards
--Joachim