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");
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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? Isn't this a kind of global AVP?
Also, if dialog IDs are used for AVP identification (UUID), these AVPs can be considered "Call-specific". 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?
JF
On 1/18/06, Bogdan-Andrei Iancu bogdan@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
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@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
Hi,
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,
On the other hand, you would be able to manipulate global proxy behaviour without having to do a restart. But I guess there are better ways to achieve this, e.g. FIFO or unix sockets.
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?
Maybe you meant "shouldn't"... In that case, I agree it would be more efficient to store AVPs in memory along with the dlg structure, of course. But if you add some other requirements, such as failover handling, maybe using DB for this purpose starts to make sense, IMHO.
JF
regards, Bogdan
JF
On 1/18/06, Bogdan-Andrei Iancu bogdan@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
Hi,
JF wrote:
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,
On the other hand, you would be able to manipulate global proxy behaviour without having to do a restart. But I guess there are better ways to achieve this, e.g. FIFO or unix sockets.
indeed - is what I'm thinking of - define (via script) or read (from DB) the global AVPs at startup into memory, use them all the time from mem and if you want to changes them use FIFO or unix socket.
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?
Maybe you meant "shouldn't"...
yes, right :)
In that case, I agree it would be more efficient to store AVPs in memory along with the dlg structure, of course. But if you add some other requirements, such as failover handling, maybe using DB for this purpose starts to make sense, IMHO.
in a failover scenario, you will also need to replicate the dialogs, so you can also replicate the AVPs linked to them via same mechanism.
regards, bogdan
regards, Bogdan
JF
On 1/18/06, Bogdan-Andrei Iancu bogdan@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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
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 ofidentifying 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 intotransactions. 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
Hi Joachim,
Joachim Fabini wrote:
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.
there is this feature - you can load or store an AVP based on uid instead of user/domain.
- 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.
I guess the problem is that in script you have only static avp name and you need dynamic name, right?
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.
per script AVP may be used as temporary AVPs to perform some script processing.
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):
- AVP lifetime dialog
- AVP lifetime registration (or per-contact, or global scope with ability to use call variables as name)
ok - so having dynamic AVP names will be a first step....sounds reasonable and useful.
Hope I manage to bring some light ;)
Definitely, but it raised again some new questions.
At least we have some progress ;)
regards, bogdan
Thanks again for your help, regards --Joachim
Hi Bogdan,
The unique ID is the first requirement, so far everything OK.
there is this feature - you can load or store an AVP based on uid instead of user/domain.
Yes, we're using this feature and it is imho currently the only way how OpenSER users can associate a local constant string name (visibility restricted to transaction) with a variable value like a header field value or a combination of several header field values.
We'd like to be able to write this value to the database using a dynamic name - typically the call-id or a combination of the fields that identify the SIP dialog.
I guess the problem is that in script you have only static avp name and you need dynamic name, right?
Absolutely correct, this is our problem. I do not see any other way how to store and retrieve data based on SIP message content.
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.
per script AVP may be used as temporary AVPs to perform some script processing.
What is the difference when compared to the current per- transaction AVPs? Probably performance I guess...
- AVP lifetime dialog
- AVP lifetime registration (or per-contact, or global scope with ability to use call variables as name)
ok - so having dynamic AVP names will be a first step....sounds reasonable and useful.
For us it is extremly useful, we can not complete our tasks without. Btw, can your last statement can be taken as a feature announcement? :))))
At least we have some progress ;)
Much more than I expected.
Thanks, best regards --Joachim
Hi Joachim,
Joachim Fabini wrote:
The unique ID is the first requirement, so far everything OK.
there is this feature - you can load or store an AVP based on uid instead of user/domain.
Yes, we're using this feature and it is imho currently the only way how OpenSER users can associate a local constant string name (visibility restricted to transaction) with a variable value like a header field value or a combination of several header field values.
We'd like to be able to write this value to the database using a dynamic name - typically the call-id or a combination of the fields that identify the SIP dialog.
I guess the problem is that in script you have only static avp name and you need dynamic name, right?
Absolutely correct, this is our problem. I do not see any other way how to store and retrieve data based on SIP message content.
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.
per script AVP may be used as temporary AVPs to perform some script processing.
What is the difference when compared to the current per- transaction AVPs? Probably performance I guess...
rights - you get rid of synchronization problems (a transaction may be processed from several process in parallel) and you have some mem. efficiency (the AVP with a temporary purpose will not stay into the transaction)
per script AVP will exists as long as the script is executed for a message. once the execution ended, the AVP will be automatically removed. they will be visible only in that script instance.
- AVP lifetime dialog
- AVP lifetime registration (or per-contact, or global scope with ability to use call variables as name)
ok - so having dynamic AVP names will be a first step....sounds reasonable and useful.
For us it is extremly useful, we can not complete our tasks without. Btw, can your last statement can be taken as a feature announcement? :))))
take it like: it will be done, but no timeframe is promised ;)
regards, bogdan
Hi,
Regarding Joachim's first post...
# 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");
You could do: modparam("avpops", "avp_aliases", "myTmpHeaderAlias=s:myTmpHeaderName") avp_db_store("$myTmpHeaderAlias", "s:myTmpHeaderValue");
I tried something similar and it worked.
JF
On 1/19/06, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi Joachim,
Joachim Fabini wrote:
The unique ID is the first requirement, so far everything OK.
there is this feature - you can load or store an AVP based on uid instead of user/domain.
Yes, we're using this feature and it is imho currently the only way how OpenSER users can associate a local constant string name (visibility restricted to transaction) with a variable value like a header field value or a combination of several header field values.
We'd like to be able to write this value to the database using a dynamic name - typically the call-id or a combination of the fields that identify the SIP dialog.
I guess the problem is that in script you have only static avp name and you need dynamic name, right?
Absolutely correct, this is our problem. I do not see any other way how to store and retrieve data based on SIP message content.
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.
per script AVP may be used as temporary AVPs to perform some script processing.
What is the difference when compared to the current per- transaction AVPs? Probably performance I guess...
rights - you get rid of synchronization problems (a transaction may be processed from several process in parallel) and you have some mem. efficiency (the AVP with a temporary purpose will not stay into the transaction)
per script AVP will exists as long as the script is executed for a message. once the execution ended, the AVP will be automatically removed. they will be visible only in that script instance.
- AVP lifetime dialog
- AVP lifetime registration (or per-contact, or global scope with ability to use call variables as name)
ok - so having dynamic AVP names will be a first step....sounds reasonable and useful.
For us it is extremly useful, we can not complete our tasks without. Btw, can your last statement can be taken as a feature announcement? :))))
take it like: it will be done, but no timeframe is promised ;)
regards, bogdan
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Regarding Joachim's first post...
# This load obviously does also not work. avp_db_load("$hdr(call-id)","s:myTmpHeaderValue");
You could do: modparam("avpops", "avp_aliases", "myTmpHeaderAlias=s:myTmpHeaderName") avp_db_store("$myTmpHeaderAlias", "s:myTmpHeaderValue");
I tried something similar and it worked.
Thanks for the hint, I'll try this tomorrow. If it really works then adding the support for dynamic variable names to OpenSER might be only a matter of parser changes.
regards --Joachim
-
Bogdan-Andrei Iancu -
JF -
Joachim Fabini