29 Aug
2009
29 Aug
'09
5:19 a.m.
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
29 Aug
29 Aug
9:01 a.m.
New subject: scope of AVPs (AVP defined when execution of script starts)
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.
9:25 a.m.
New subject: scope of AVPs (AVP defined when execution of script starts)
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
31 Aug
31 Aug
4:31 a.m.
On 29.08.2009 16:25 Uhr, Juha Heinanen wrote:
Jan Janak 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?
Cheers,
Daniel
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.
--
Daniel-Constantin Mierla
* http://www.asipto.com/
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
4:44 a.m.
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
6:07 a.m.
On 31.08.2009 11:46 Uhr, Juha Heinanen wrote:
Juha Heinanen writes:
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
--
Daniel-Constantin Mierla
* http://www.asipto.com/
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.
12:46 p.m.
On 31.08.2009 19:31 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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
--
Daniel-Constantin Mierla
* http://www.asipto.com/
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.
1 Sep
1 Sep
4:36 a.m.
New subject: scope of AVPs (AVP defined when execution of script starts)
On Mon, Aug 31, 2009 at 6:46 PM, Daniel-Constantin
Mierla<miconda(a)gmail.com> wrote:
On 31.08.2009 19:31 Uhr, Juha Heinanen wrote:
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 writes:
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, ... 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.
5600
days inactive
5603
days old
9 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com