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
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
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@tutpro.com wrote:
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
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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
Hello Juha,
On Sat, Mar 12, 2011 at 8:14 PM, Juha Heinanen jh@tutpro.com wrote:
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.
ok, thanks for testing.
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 -
Juha Heinanen