[Users] Call-specific AVP DBS storage for OpenSER

[Joachim Fabini]

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 at 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