12 Mar
2011
12 Mar
'11
7:58 a.m.
in order to get invite requests accounted, it seems that accounting
flags need to be set before t_newtran() is called.
is there any way to unset the accounting flags after calling
t_newtran()? for example, i would not like to account invites that
result to 407 proxy authentication required.
-- juha
12 Mar
12 Mar
8:46 a.m.
Juha Heinanen writes:
is there any way to unset the accounting flags after
calling
t_newtran()? for example, i would not like to account invites that
result to 407 proxy authentication required.
just to clarify, i added statement
resetflag(ACC_FAILED_FLAG);
just before proxy_challenge() call, but it did not have any effect. i
guess the reason is that transaction was already created.
if failed transaction reporting cannot be undone after transaction has
been created, then another possibility (although not as attractive) would
be to add a filter param to accounting module that would list which
response codes >=300 script writer is not interested in.
-- juha
1:41 p.m.
Hi Juha,
great that you needed it so it got spotted, practically we had support for
sync'ing flags back to transaction from message in 1.x, but seems it got
lost during the integration.
I just reintroduced the t_flush_flags() in the tmx module. Being a fix
considering the lost of the old feature, it can be backported once you
confirm it works for you (unfortunately I am not able to test right now).
Cheers,
Daniel
On Sat, Mar 12, 2011 at 7:46 AM, Juha Heinanen <jh(a)tutpro.com> wrote:
Juha Heinanen writes:
--
Daniel-Constantin Mierla
http://www.asipto.com
is there any way to unset the accounting flags
after calling
t_newtran()? for example, i would not like to account invites that
result to 407 proxy authentication required.
just to clarify, i added statement
resetflag(ACC_FAILED_FLAG);
just before proxy_challenge() call, but it did not have any effect. i
guess the reason is that transaction was already created.
if failed transaction reporting cannot be undone after transaction has
been created, then another possibility (although not as attractive) would
be to add a filter param to accounting module that would list which
response codes >=300 script writer is not interested in.
-- juha
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
9:14 p.m.
Daniel-Constantin Mierla writes:
I just reintroduced the t_flush_flags() in the tmx
module. Being a fix
considering the lost of the old feature, it can be backported once you
confirm it works for you (unfortunately I am not able to test right
now).
daniel,
thanks for the new function. now 407 does not anymore get accounted
with this piece of script:
resetflag(ACC_FAILED_FLAG);
t_flush_flags();
proxy_challenge(...);
so the function seem to work ok and could be backported.
while at this, it may still be a good idea to have a failure code filter
param in acc module, because, people may not be interested, for
example, in 404 not found calls to be accounted.
-- juha
13 Mar
13 Mar
12:33 a.m.
Hello Juha,
On Sat, Mar 12, 2011 at 8:14 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
Daniel-Constantin Mierla writes:
ok, thanks for testing.
I just reintroduced the t_flush_flags() in the
tmx module. Being a fix
considering the lost of the old feature, it can be backported once you
confirm it works for you (unfortunately I am not able to test right
now).
daniel,
thanks for the new function. now 407 does not anymore get accounted
with this piece of script:
resetflag(ACC_FAILED_FLAG);
t_flush_flags();
proxy_challenge(...);
so the function seem to work ok and could be backported.
while at this, it may still be a good idea to have a failure code filter
param in acc module, because, people may not be interested, for
example, in 404 not found calls to be accounted.
It is fine for me - anyone that has time to do it just go ahead and let it
be controlled by module parameter.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
5004
days inactive
5004
days old
4 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Juha Heinanen