[Devel] Re: [Users] Call-specific AVP DBS storage for OpenSER

[Bogdan-Andrei Iancu]

Hi,

JF wrote:

>Hi,
>  
>
>>    - 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.
>>    
>>
>
>But if an AVP is stored in DB, it lives beyond the transaction
>lifetime and it never gets deleted unless avp_db_delete() is called
>for it from the script, right?
>  
>
I see the DB as an external storage media. It's a special type of 
location - a bulk storage.

>Isn't this a kind of global AVP?
>  
>
Indeed, you can load or delete from DB whenever you want, but sounds 
like global C variables via DB :D. It's not something that should be done,

>Also, if dialog IDs are used for AVP identification (UUID), these AVPs
>can be considered "Call-specific".
>  
>
yes, but the main and most important idea is to keep the AVP into memory 
(as variables) and avoid DB operations.

>A dialog tracking module would be able to provide this identification
>and also guarantee that AVPs are deleted from DB when dialogs are
>terminated (provided record routing is active). What do you think?
>  
>
if you have a dialog tracking module, why should you keep the AVP s into 
memory attached to the dialog structure? it;s is more simpler and efficient?

regards,
Bogdan

>JF
>
>On 1/18/06, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
>  
>
>>Hi Joachim,
>>
>>Here are some thoughts regarding this issue:
>>
>>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).
>>
>>    - 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.
>>
>>Now...about improvements.....For identifications....I would say it
>>covers all cases..no idea what can be added - any suggestions are welcome.
>>
>>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). And maybe
>>(again...maybe) in the future AVP per dialog (they belong to a dialog).
>>
>>Hope I manage to bring some light ;)
>>
>>regards,
>>bogdan
>>
>>
>>Joachim Fabini wrote:
>>
>>    
>>
>>>Hi all,
>>>
>>>Unfortunately the previous thread on this topic ended
>>>without a definitive statement or conclusion, probably
>>>because of the New Year holiday (btw, Happy New Year to
>>>all of you!). So here's another try:
>>>
>>>OpenSER is currently session stateful but not call
>>>stateful. This is valid also/especially for the AVP
>>>module: You can store AVPs on a per-contact base but
>>>(imho) _not_ specific to a call or dialog. The reason
>>>for this is that the AVP module does not allow/
>>>implement the use of call-dependent variables as AVP
>>>names.
>>>
>>>Adding this feature to OpenSER doesn't require a change
>>>in interfaces (implementation effort is another topic ;).
>>>It's just about enabling the use of AVP or header values
>>>(like, e.g. call-id) as the _name_ of another AVP for
>>>DBS storage.
>>>I attach a specific example below.
>>>
>>>Can some of the developers and/or maintainers please
>>>comment and/or give some hints on the feasibility of
>>>this approach?
>>>Is it possible to add this feature to OpenSER? What
>>>effort is required to add this enhancement to the AVP
>>>module? Please come back if some details are unclear,
>>>I might have missed something important.
>>>
>>>Many thanks in advance for your reply and help,
>>>Best regards
>>>--Joachim
>>>
>>>PS: Example: The task is to process any SIP message that
>>>passes through our proxy. We must compute a unique ID
>>>specific to the call on the first message belonging to
>>>this call and store it in DBS. Whenever another message
>>>that is part of this call/dialog arrives, we retrieve the
>>>unique ID from the DBS and, e.g., append it as a specific
>>>header field value.
>>>The only way how this can be done is to use some call-
>>>specific AVP name (e.g. call-id), as we do not have any
>>>influence on the structure of the AVP value (so regexp-
>>>search based on AVP value does not help).
>>>
>>># This is the AVP name that is required to retrieve
>>># our specific, call-dependent AVP value from the
>>># database whenever a message that belongs to this
>>># call passes our OpenSER proxy.
>>>avp_printf("s:myTmpHeaderName", "$from/username$hdr(call-id)");
>>>
>>># This is the value we'd like to store. Could be also
>>># only "$Ts", i.e., we can _not_ rely on regular
>>># expression search for later retrieving the AVP
>>># from the DBS based on its value.
>>>avp_printf("s:myTmpHeaderValue", "$hdr(call-id)-$Ts");
>>>
>>># This storing of the call-dependent info in DBS does
>>># currently not work. OpenSER complains at start-up
>>># about the variable AVP name/key on both of the
>>># following lines. The former variant seems much more
>>># flexible to me than the latter one.
>>>avp_db_store("s:myTmpHeaderName","s:myTmpHeaderValue");
>>>avp_db_store("$hdr(call-id)","s:myTmpHeaderValue");
>>>
>>># This load obviously does also not work.
>>>avp_db_load("$hdr(call-id)","s:myTmpHeaderValue");
>>>
>>>
>>>
>>>_______________________________________________
>>>Users mailing list
>>>Users at openser.org
>>>http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>Devel mailing list
>>Devel at openser.org
>>http://openser.org/cgi-bin/mailman/listinfo/devel
>>    
>>
>>
>
>  
>