18 Jan
2006
18 Jan
'06
11:26 p.m.
Hi,
JF wrote:
Hi,
I see the DB as an external storage media. It's a special type of
location - a bulk storage.
- 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?
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(a)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@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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Devel mailing list
Devel(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel