i send the message below to wrong mailing list. i'm experiencing this behavior with sip-router, not kamailio. perhaps the behavior would be as expected with kamailio.
-- juha
----------------------------------------------------------------------
i have always thought that AVPs exits per transaction. that does not seem to be the case, however, because when i put in the beginning of my script
xlog("L_INFO", "Caller lcr_id $avp(CALLER_LCR_ID_AVP)\n"); this gets printed to syslog:
Aug 29 11:34:34 localhost /usr/sbin/sip-router[10210]: INFO: Caller lcr_id 2
is this the indented behavior? do i really need to delete all AVPs in the beginning of the script in order to make sure that they don't have any values left from processing of previous message?
-- juha
Juha,
i have always thought that AVPs exits per transaction. that does not seem to be the case, however, because when i put in the beginning of my script
xlog("L_INFO", "Caller lcr_id $avp(CALLER_LCR_ID_AVP)\n");
this gets printed to syslog:
Aug 29 11:34:34 localhost /usr/sbin/sip-router[10210]: INFO: Caller lcr_id 2
is this the indented behavior? do i really need to delete all AVPs in the beginning of the script in order to make sure that they don't have any values left from processing of previous message?
What kind of AVP is this? Where is its value defined? If it is a global AVP (defined in global_attrs table) then what you see could be correct. Global AVPs are always present.
If this is a domain level avp (defined in domain_attrs table) then what you see could be correct, provided that you called some function from domain module before the statement above (i.e. lookup_domain).
If it is neither domain-level nor global avp then the behavior you see is not intended.
You can also try to use the ser version of xlog module to see where the value comes from:
xlog("L_INFO", "User-level value: %$fu.CALLER_LCR_ID_AVP\n"); xlog("L_INFO", "Domain-level value: %$fd.CALLER_LCR_ID_AVP\n"); xlog("L_INFO", "Global-level value: %g.CALLER_LCR_ID_AVP\n");
Provided that this is an AVP with string name (If I am not mistaken then the ser version of xlog module does not support AVPs with integer names).
Jan.
Jan Janak writes:
What kind of AVP is this? Where is its value defined? If it is a global AVP (defined in global_attrs table) then what you see could be correct. Global AVPs are always present.
this avp is has been loaded from db using avpops avp_db_function. after starting sr, first message xlog prints null avp value, but subsequent messages print whatever value the previous one loaded to this avp.
Provided that this is an AVP with string name (If I am not mistaken then the ser version of xlog module does not support AVPs with integer names).
this avp has integer name.
i'm pretty sure that in k, these kind of avps used to undefined for each new transaction.
-- juha
On 29.08.2009 16:25 Uhr, Juha Heinanen wrote:
Jan Janak writes:
What kind of AVP is this? Where is its value defined? If it is a global AVP (defined in global_attrs table) then what you see could be correct. Global AVPs are always present.
this avp is has been loaded from db using avpops avp_db_function.
i tried with avp_db_query() and it gets reseted. Can you paste the cfg line that does the loading and tell in which kind of route you do it?
Cheers, Daniel
after starting sr, first message xlog prints null avp value, but subsequent messages print whatever value the previous one loaded to this avp.
Provided that this is an AVP with string name (If I am not mistaken then the ser version of xlog module does not support AVPs with integer names).
this avp has integer name.
i'm pretty sure that in k, these kind of avps used to undefined for each new transaction.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Daniel-Constantin Mierla writes:
i tried with avp_db_query() and it gets reseted. Can you paste the cfg line that does the loading and tell in which kind of route you do it?
daniel,
the query is
avp_db_load("$avp(AVP_NAME)", "a");
in my test, it loaded two avps.
when i changed the value of one avp, the change was properly reflected in the next message. however, when i went and deleted the avp, next messages still thought that the avp exists and has the value it had before i removed the avp from db.
this started me wonder that there could be a pretty serious bug somewhere.
-- juha
On 31.08.2009 11:46 Uhr, Juha Heinanen wrote:
Juha Heinanen writes:
the query is
avp_db_load("$avp(AVP_NAME)", "a");
in my test, it loaded two avps.
forgot to mention that the query is done in request route.
there was an overlapping between avp flag values used by avpops and sr core. Should be fixed now. Let me know if works.
Can a ser developer review the core patch and see if something was affected in ser avps?
Cheers, Daniel
On 31.08.2009 19:31 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
there was an overlapping between avp flag values used by avpops and sr core. Should be fixed now. Let me know if works.
now it works, i.e., avps loaded with avp_db_load are not anymore visible to next request.
ok.
On the other hand, I find a bit complex and confusing keeping the type of avp list as flag while they are also different lists -- meant here the ser avp lists - from, to, domain, global, ...
Cheers, Daniel
On Mon, Aug 31, 2009 at 6:46 PM, Daniel-Constantin Mierlamiconda@gmail.com wrote:
On 31.08.2009 19:31 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
> there was an overlapping between avp flag values used by avpops and sr > core. Should be fixed now. Let me know if works.
now it works, i.e., avps loaded with avp_db_load are not anymore visible to next request.
ok.
On the other hand, I find a bit complex and confusing keeping the type of avp list as flag while they are also different lists -- meant here the ser avp lists - from, to, domain, global, ...
Do you mean the flags passed to add_avp and other avp related functions? Those flags are used to make the avp interface backwards compatible (without specifying any of the flags the interface still works as expected). Modules are not supposed to work with avp lists directly and most modules only need to specify whether they want to search the from or to AVPs. Those flags do not map directly to individual lists, there is some extra logic behind them in the avp code.
Jan.
-
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com