Hi Victor,

just a silly question - are you creating the transaction (via t_newtran) before setting the acc flag. Can you also print in failure route what are the message flags ($mF) ?

regards, bogdan

Victor Gamov wrote:

Bogdan-Andrei Iancu wrote:

...

Hi Victor,

is the 408 received or local generated?

It's received. Also 404 may be received.

All this responses correctly processed by failure_route[1] but not accounted.

direct acc_db_request() partially help but it not save response code into db (is it module feature or my misconfiguration. may be we need new feature request for ACC module?)

...

regards, bogdan

Victor Gamov wrote:

...

Hi All

I red ACC module manual many times but still can not understand what I need to do to account failed transactions (408 for example)

I make following configuration but failed transactions still not accounted

---------- cut here ------------------ modparam("acc", "early_media", 1) modparam("acc", "report_ack", 1) modparam("acc", "report_cancels", 1) modparam("acc", "failed_transaction_flag", 1) modparam("acc", "db_flag", 1)

route[1] {

setflag(1); t_on_failure("1"); t_relay(); }

failure_route[1] {

xlog("L_ERR", "failure_route[1]: METHOD=$rm; rc=$T_reply_code\n"); } ---------- cut here ------------------

Yes I can add some acc_db_request() into failure_route[1] but this function don't set sip_code field in DB.

Please advise me before I start to read sources :-)

Hi Victor,

I just gave it a try (with 1.3) using your acc config (but to syslog) and I got a record.

Do you get any errors in the script? can you try using the syslog acc?

regards, bogdan

Victor Gamov wrote:

Bogdan-Andrei Iancu wrote:

...

Hi Victor,

Hi Bogdan!

Thanks for your attention

...

just a silly question - are you creating the transaction (via t_newtran) before setting the acc flag.

No, only t_relay() in route[1]

...

Can you also print in failure route what are the message flags ($mF) ?

It's looks like

failure_route[1]: METHOD=INVITE; T_reply_code=404; flags=2147483654

(2147483654 is 10000000000000000000000000000110 in binary. All this flags sets by my config)

Significant info: I use OpenSER-1.2.1 release. May be it's my main problem?

...

Victor Gamov wrote:

...

Bogdan-Andrei Iancu wrote:

...

Hi Victor,

is the 408 received or local generated?

It's received. Also 404 may be received.

All this responses correctly processed by failure_route[1] but not accounted.

direct acc_db_request() partially help but it not save response code into db (is it module feature or my misconfiguration. may be we need new feature request for ACC module?)

...

regards, bogdan

Victor Gamov wrote:

...

Hi All

I red ACC module manual many times but still can not understand what I need to do to account failed transactions (408 for example)

I make following configuration but failed transactions still not accounted

---------- cut here ------------------ modparam("acc", "early_media", 1) modparam("acc", "report_ack", 1) modparam("acc", "report_cancels", 1) modparam("acc", "failed_transaction_flag", 1) modparam("acc", "db_flag", 1)

route[1] {

setflag(1); t_on_failure("1"); t_relay(); }

failure_route[1] {

xlog("L_ERR", "failure_route[1]: METHOD=$rm; rc=$T_reply_code\n"); } ---------- cut here ------------------

Yes I can add some acc_db_request() into failure_route[1] but this function don't set sip_code field in DB.

Please advise me before I start to read sources :-)

Bogdan-Andrei Iancu wrote:

Hi Victor,

I just gave it a try (with 1.3) using your acc config (but to syslog) and I got a record.

Do you get any errors in the script? can you try using the syslog acc?

Hi Bogdan!

Thanks for your attention. It was a my misunderstanding and following misconfiguration for "failed transactions" and "missed calls".

ACC module use "db_table_missed_calls" value to write failed transactions. When I set this parameter to my accounting table then everything is OK.

But I think that some clarifying for this in module documentation needed. Now module have following parameters (general and DB specific):

"failed_transaction_flag" -- Per transaction flag which says if the transaction should be accounted also in case of failure (status>=300).

"db_missed_flag" -- Request flag which needs to be set to account missed calls

"db_table_missed_calls" -- Table name for accounting missed calls

But what is it means "missing calls"? Failed transaction? or user not founded by USRLOC module? or some other?

If "missing" means "failed" (not founded is "failed" too) then we must change definitions and may be remove "db_missed_flag" parameter. If "missed" and "failed" is very different than new parameter "db_table_failed_calls" may be useful.

Thanks!

Hi Victor,

* to get also the failed transactions (completed with negative replies) you need to set the failed_transaction_flag

* if during serial forking you want to log some of the intermediary failed branches, you need to set the log|radius|db_missed_flag ** this flag will log the next failed branch as a “FAILED” event ** the flag will be automatically reset after the branch completion ** IMPORTANT: this flag triggers accounting when a branch fails (on the client side), when failed_transaction_flag triggers accounting when the whole transaction fails (on the server side) as the name says, it is useful for accounting the the “missed call” event during serial forking.

Let me know if this helps in understanding the difference between missed call and failed transaction

Regards, Bogdan

Victor Gamov wrote:

Any comments about doc/module enhancing ?

Victor Gamov wrote:

...

Bogdan-Andrei Iancu wrote:

...

Hi Victor,

I just gave it a try (with 1.3) using your acc config (but to syslog) and I got a record.

Do you get any errors in the script? can you try using the syslog acc?

Hi Bogdan!

Thanks for your attention. It was a my misunderstanding and following misconfiguration for "failed transactions" and "missed calls".

ACC module use "db_table_missed_calls" value to write failed transactions. When I set this parameter to my accounting table then everything is OK.

But I think that some clarifying for this in module documentation needed. Now module have following parameters (general and DB specific):

"failed_transaction_flag" -- Per transaction flag which says if the transaction should be accounted also in case of failure (status>=300).

"db_missed_flag" -- Request flag which needs to be set to account missed calls

"db_table_missed_calls" -- Table name for accounting missed calls

But what is it means "missing calls"? Failed transaction? or user not founded by USRLOC module? or some other?

If "missing" means "failed" (not founded is "failed" too) then we must change definitions and may be remove "db_missed_flag" parameter. If "missed" and "failed" is very different than new parameter "db_table_failed_calls" may be useful.

Thanks!

Hi Victor,

Victor Gamov wrote:

Bogdan-Andrei Iancu wrote:

...

Hi Victor,

Hi Bogdan!

...

• to get also the failed transactions (completed with negative

replies) you need to set the failed_transaction_flag

• if during serial forking you want to log some of the intermediary

failed branches, you need to set the log|radius|db_missed_flag ** this flag will log the next failed branch as a “FAILED” event ** the flag will be automatically reset after the branch completion ** IMPORTANT: this flag triggers accounting when a branch fails (on the client side), when failed_transaction_flag triggers accounting when the whole transaction fails (on the server side) as the name says, it is useful for accounting the the “missed call” event during serial forking.

Let me know if this helps in understanding the difference between missed call and failed transaction

So, "missed call" is failed branch (e.g. user not responding) and "failed transaction" is call with all branches failed ?

Yes correct. I just copied and pasted the text from the slides I prepare for "OpenSER Admin Training" course. It was a check (for me) to see how comprehensive the info is ;).

Regards, Bogdan