Some time ago I had some problems with accounting of failed transactions vs. missed transactions. I could solve them by using a dedicated flag for every parameter.

regards klaus

Federico Giannici wrote:

Daniel-Constantin Mierla wrote:

...

Hello,

have you set the flag to log missed transaction? http://openser.org/docs/modules/1.0.x/acc.html#AEN407

No, I set the following:

modparam("acc", "db_flag", 1) modparam("acc", "failed_transaction_flag", 1)

But no "db_missed_flag". Anyway:

1. I don't want to log missed calls in a separate table.

2. The failed INVITEs are actually logged in the normal table, but the

AVPs I set are not logged (it seems that they are not found).

In normal cases the AVP are correctly logged. Even in many error cases (404, and so on) they are logged too. But in some cases, with strange errors (488, 422), the AVPs are NOT logged (accounting is done, but AVPs are "n\a")!

Any explanation of this?

Thanks.

...

Or is that the some avps are not any more stored for failed transaction? Maybe some snippets of your config will give us more hints about what happens there.

Cheers, Daniel

On 11/26/05 14:04, Federico Giannici wrote:

...

I'm using OpenSER 1.0.0 on OpenBSD 3.7 amd64.

I have a strange problem with the accounting: I set a couple of AVPs for every message that arrives at the server. I'm sure they are there because they are written in the syslog logging. Sometimes, when an INVITE is relayed (with transactions) and receives an error (488, 422, etc.), in the SQL logging there is no more presence of the AVPs! Is this a known problem? How can I avoid this?

Thanks.

e.g try:

modparam("acc", "db_flag", 1) modparam("acc", "failed_transaction_flag", 2)

I had problems with accounting of missed calls. In my config:

modparam("acc", "radius_flag", 1) modparam("acc", "db_flag", 11) modparam("acc", "failed_transaction_flag", 2) modparam("acc", "db_missed_flag", 12)

this works, where else this did not worked:

modparam("acc", "radius_flag", 1) modparam("acc", "db_flag", 11) modparam("acc", "failed_transaction_flag", 2) modparam("acc", "db_missed_flag", 2)

klaus

Federico Giannici wrote:

Klaus Darilion wrote:

...

Some time ago I had some problems with accounting of failed transactions vs. missed transactions. I could solve them by using a dedicated flag for every parameter.

I didn't understood. Can you explain me what you mean for "using a dedicated flag for every parameter"?

Thanks.

...

Federico Giannici wrote:

...

Daniel-Constantin Mierla wrote:

...

Hello,

have you set the flag to log missed transaction? http://openser.org/docs/modules/1.0.x/acc.html#AEN407

No, I set the following:

modparam("acc", "db_flag", 1) modparam("acc", "failed_transaction_flag", 1)

But no "db_missed_flag". Anyway:

1. I don't want to log missed calls in a separate table.

2. The failed INVITEs are actually logged in the normal table, but

the AVPs I set are not logged (it seems that they are not found).

In normal cases the AVP are correctly logged. Even in many error cases (404, and so on) they are logged too. But in some cases, with strange errors (488, 422), the AVPs are NOT logged (accounting is done, but AVPs are "n\a")!

Any explanation of this?

Thanks.

...

Or is that the some avps are not any more stored for failed transaction? Maybe some snippets of your config will give us more hints about what happens there.

Cheers, Daniel

On 11/26/05 14:04, Federico Giannici wrote:

...

I'm using OpenSER 1.0.0 on OpenBSD 3.7 amd64.

I have a strange problem with the accounting: I set a couple of AVPs for every message that arrives at the server. I'm sure they are there because they are written in the syslog logging. Sometimes, when an INVITE is relayed (with transactions) and receives an error (488, 422, etc.), in the SQL logging there is no more presence of the AVPs! Is this a known problem? How can I avoid this?

Thanks.

Bogdan-Andrei Iancu wrote:

Hi Federico,

use avp_print() (works only with debug=9) in failure_route to inspect the list of present AVP. maybe you do not have the AVPs you are trying to log.

But I set those AVPs in EVERY message received by the server. Moreover, I'm SURE they are there because before forwarding those INVITEs with t_relay() I log the messages to syslog and the AVPs ARE THERE.

Then, when some kind of errors are received (488, 422, etc.) it seems that those AVPs are "lost" by the transaction engine... But I'm not sure what conditions cause this lost.

Bye.

Federico Giannici wrote:

...

Daniel-Constantin Mierla wrote:

...

Hello,

have you set the flag to log missed transaction? http://openser.org/docs/modules/1.0.x/acc.html#AEN407

No, I set the following:

modparam("acc", "db_flag", 1) modparam("acc", "failed_transaction_flag", 1)

But no "db_missed_flag". Anyway:

1. I don't want to log missed calls in a separate table.

2. The failed INVITEs are actually logged in the normal table, but the

AVPs I set are not logged (it seems that they are not found).

In normal cases the AVP are correctly logged. Even in many error cases (404, and so on) they are logged too. But in some cases, with strange errors (488, 422), the AVPs are NOT logged (accounting is done, but AVPs are "n\a")!

Any explanation of this?

Thanks.

...

Or is that the some avps are not any more stored for failed transaction? Maybe some snippets of your config will give us more hints about what happens there.

Cheers, Daniel

On 11/26/05 14:04, Federico Giannici wrote:

...

I'm using OpenSER 1.0.0 on OpenBSD 3.7 amd64.

I have a strange problem with the accounting: I set a couple of AVPs for every message that arrives at the server. I'm sure they are there because they are written in the syslog logging. Sometimes, when an INVITE is relayed (with transactions) and receives an error (488, 422, etc.), in the SQL logging there is no more presence of the AVPs! Is this a known problem? How can I avoid this?

Thanks.

I'm still not able to make these errors reproducible.

Now I found that the "AVPs vanishing" occours with 200 OK situations too. It seems to be related to packets retransmission. They occur when the following errors are logged:

Nov 28 22:28:30 eowyn OpenSER[3010]: ERROR: t_newtran: transaction already in process 0x502bbc58 Nov 28 22:28:30 eowyn OpenSER[3010]: ERROR: sl_reply_error used: I'm terribly sorry, server error occurred (1/SL)

These are generated by this classic code:

if ( !t_relay() ) { sl_reply_error(); }

Now I'm asking myself: is it correct to reply to a message that is a retrasmission? Shouldn't we simply ignore it? Couldn't it confuse the UAs?

Thanks.

Federico Giannici wrote:

Bogdan-Andrei Iancu wrote:

...

Hi Federico,

use avp_print() (works only with debug=9) in failure_route to inspect the list of present AVP. maybe you do not have the AVPs you are trying to log.

But I set those AVPs in EVERY message received by the server. Moreover, I'm SURE they are there because before forwarding those INVITEs with t_relay() I log the messages to syslog and the AVPs ARE THERE.

Then, when some kind of errors are received (488, 422, etc.) it seems that those AVPs are "lost" by the transaction engine... But I'm not sure what conditions cause this lost.

Bye.

...

Federico Giannici wrote:

...

Daniel-Constantin Mierla wrote:

...

Hello,

have you set the flag to log missed transaction? http://openser.org/docs/modules/1.0.x/acc.html#AEN407

No, I set the following:

modparam("acc", "db_flag", 1) modparam("acc", "failed_transaction_flag", 1)

But no "db_missed_flag". Anyway:

1. I don't want to log missed calls in a separate table.

2. The failed INVITEs are actually logged in the normal table, but

the AVPs I set are not logged (it seems that they are not found).

In normal cases the AVP are correctly logged. Even in many error cases (404, and so on) they are logged too. But in some cases, with strange errors (488, 422), the AVPs are NOT logged (accounting is done, but AVPs are "n\a")!

Any explanation of this?

Thanks.

...

Or is that the some avps are not any more stored for failed transaction? Maybe some snippets of your config will give us more hints about what happens there.

Cheers, Daniel

On 11/26/05 14:04, Federico Giannici wrote:

...

I'm using OpenSER 1.0.0 on OpenBSD 3.7 amd64.

I have a strange problem with the accounting: I set a couple of AVPs for every message that arrives at the server. I'm sure they are there because they are written in the syslog logging. Sometimes, when an INVITE is relayed (with transactions) and receives an error (488, 422, etc.), in the SQL logging there is no more presence of the AVPs! Is this a known problem? How can I avoid this?

Thanks.

The problem is surely related to the retrasmission of the INVITEs and probably to the UAC module.

I was able to reproduce the problem (AVPs vanishing) by adding a delay of 3 seconds for every message received. In this way a caused a couple of retrasmission for each message. Moreover that occurred only to the calls to a PSTN gateway using by the UAC module for authenticatuion and From substitution.

In this case the INVITE's AVPs are no more present when the INVITE is logged by the ACC module (even if they were present before entering the transaction engine).

If calls are made to other voip users (not using the UAC module) or if there is non INVITE retrasmission, the AVPs are correctly found.

BTW, I used the t_lookup_request() function to test if the message is a retrasmission. It turned out that that INVITE and BYE retrasmissions are correctly identified, but not the ACK retrasmission. I don't know if this is the correct behaviour.

I hope this information can be useful to find the problem.

Thanks.

Federico Giannici wrote:

The mistery keeps increasing!

I have found that if I set an AVP in an INVITE message, then the same AVP is logged in the ACCOUNTING of the corresponding ACK message!

But it is NOT in the ACK message before it enters the transaction engine (with a t_relay()). So it is the transaction engine that "copies" the INVITE AVPS to the ACK. Or the accounting routines use the AVPs from the corresponding INVITE instead of the ACK ones.

Is this the expected behaviour? Why this happens?

Thanks.

Federico Giannici wrote:

...

I'm still not able to make these errors reproducible.

Now I found that the "AVPs vanishing" occours with 200 OK situations too. It seems to be related to packets retransmission. They occur when the following errors are logged:

Nov 28 22:28:30 eowyn OpenSER[3010]: ERROR: t_newtran: transaction already in process 0x502bbc58 Nov 28 22:28:30 eowyn OpenSER[3010]: ERROR: sl_reply_error used: I'm terribly sorry, server error occurred (1/SL)

These are generated by this classic code:

if ( !t_relay() ) { sl_reply_error(); }

Now I'm asking myself: is it correct to reply to a message that is a retrasmission? Shouldn't we simply ignore it? Couldn't it confuse the UAs?

Thanks.

Federico Giannici wrote:

...

Bogdan-Andrei Iancu wrote:

...

Hi Federico,

use avp_print() (works only with debug=9) in failure_route to inspect the list of present AVP. maybe you do not have the AVPs you are trying to log.

But I set those AVPs in EVERY message received by the server. Moreover, I'm SURE they are there because before forwarding those INVITEs with t_relay() I log the messages to syslog and the AVPs ARE THERE.

Then, when some kind of errors are received (488, 422, etc.) it seems that those AVPs are "lost" by the transaction engine... But I'm not sure what conditions cause this lost.

Bye.

...

Federico Giannici wrote:

...

Daniel-Constantin Mierla wrote:

...

Hello,

have you set the flag to log missed transaction? http://openser.org/docs/modules/1.0.x/acc.html#AEN407

No, I set the following:

modparam("acc", "db_flag", 1) modparam("acc", "failed_transaction_flag", 1)

But no "db_missed_flag". Anyway:

1. I don't want to log missed calls in a separate table.

2. The failed INVITEs are actually logged in the normal table, but

the AVPs I set are not logged (it seems that they are not found).

In normal cases the AVP are correctly logged. Even in many error cases (404, and so on) they are logged too. But in some cases, with strange errors (488, 422), the AVPs are NOT logged (accounting is done, but AVPs are "n\a")!

Any explanation of this?

Thanks.

...

Or is that the some avps are not any more stored for failed transaction? Maybe some snippets of your config will give us more hints about what happens there.

Cheers, Daniel

On 11/26/05 14:04, Federico Giannici wrote:

> I'm using OpenSER 1.0.0 on OpenBSD 3.7 amd64. > > I have a strange problem with the accounting: I set a couple of > AVPs for every message that arrives at the server. I'm sure they > are there because they are written in the syslog logging. > Sometimes, when an INVITE is relayed (with transactions) and > receives an error (488, 422, etc.), in the SQL logging there is > no more presence of the AVPs! > Is this a known problem? > How can I avoid this? > > > Thanks.

Hi Frederico,

short question : it's about an INVITE or ACK?

regards, bogdan

Federico Giannici wrote:

Hi, Bogdan. No suggestion for this problem?

Today I made some other debugging and found that the AVP is still correctly set at the start and at the end of the onreply_route and failure_route corresponding at the INVITE.

And I still confirm you that the AVP is "lost" when there is a retrasmission and the message if forwarded with the autentication and from-modify by means of the UAC module.

No problem when there is no retrasmissin or for forwarding without the UAC module.

What else I can try? What other information I can provide you?

Thanks.

Federico Giannici wrote:

...

The problem is surely related to the retrasmission of the INVITEs and probably to the UAC module.

I was able to reproduce the problem (AVPs vanishing) by adding a delay of 3 seconds for every message received. In this way a caused a couple of retrasmission for each message. Moreover that occurred only to the calls to a PSTN gateway using by the UAC module for authenticatuion and From substitution.

In this case the INVITE's AVPs are no more present when the INVITE is logged by the ACC module (even if they were present before entering the transaction engine).

If calls are made to other voip users (not using the UAC module) or if there is non INVITE retrasmission, the AVPs are correctly found.

BTW, I used the t_lookup_request() function to test if the message is a retrasmission. It turned out that that INVITE and BYE retrasmissions are correctly identified, but not the ACK retrasmission. I don't know if this is the correct behaviour.

I hope this information can be useful to find the problem.

Thanks.

Federico Giannici wrote:

...

The mistery keeps increasing!

I have found that if I set an AVP in an INVITE message, then the same AVP is logged in the ACCOUNTING of the corresponding ACK message!

But it is NOT in the ACK message before it enters the transaction engine (with a t_relay()). So it is the transaction engine that "copies" the INVITE AVPS to the ACK. Or the accounting routines use the AVPs from the corresponding INVITE instead of the ACK ones.

Is this the expected behaviour? Why this happens?

Thanks.

Federico Giannici wrote:

...

I'm still not able to make these errors reproducible.

Now I found that the "AVPs vanishing" occours with 200 OK situations too. It seems to be related to packets retransmission. They occur when the following errors are logged:

Nov 28 22:28:30 eowyn OpenSER[3010]: ERROR: t_newtran: transaction already in process 0x502bbc58 Nov 28 22:28:30 eowyn OpenSER[3010]: ERROR: sl_reply_error used: I'm terribly sorry, server error occurred (1/SL)

These are generated by this classic code:

if ( !t_relay() ) { sl_reply_error(); }

Now I'm asking myself: is it correct to reply to a message that is a retrasmission? Shouldn't we simply ignore it? Couldn't it confuse the UAs?

Thanks.

Federico Giannici wrote:

...

Bogdan-Andrei Iancu wrote:

...

Hi Federico,

use avp_print() (works only with debug=9) in failure_route to inspect the list of present AVP. maybe you do not have the AVPs you are trying to log.

But I set those AVPs in EVERY message received by the server. Moreover, I'm SURE they are there because before forwarding those INVITEs with t_relay() I log the messages to syslog and the AVPs ARE THERE.

Then, when some kind of errors are received (488, 422, etc.) it seems that those AVPs are "lost" by the transaction engine... But I'm not sure what conditions cause this lost.

Bye.

...

Federico Giannici wrote:

> Daniel-Constantin Mierla wrote: > >> Hello, >> >> have you set the flag to log missed transaction? >> http://openser.org/docs/modules/1.0.x/acc.html#AEN407 > > > > > > > > > No, I set the following: > > modparam("acc", "db_flag", 1) > modparam("acc", "failed_transaction_flag", 1) > > But no "db_missed_flag". > Anyway: > > 1) I don't want to log missed calls in a separate table. > > 2) The failed INVITEs are actually logged in the normal table, > but the AVPs I set are not logged (it seems that they are not > found). > > In normal cases the AVP are correctly logged. Even in many error > cases (404, and so on) they are logged too. But in some cases, > with strange errors (488, 422), the AVPs are NOT logged > (accounting is done, but AVPs are "n\a")! > > Any explanation of this? > > Thanks. > > >> Or is that the some avps are not any more stored for failed >> transaction? Maybe some snippets of your config will give us >> more hints about what happens there. >> >> Cheers, >> Daniel >> >> On 11/26/05 14:04, Federico Giannici wrote: >> >>> I'm using OpenSER 1.0.0 on OpenBSD 3.7 amd64. >>> >>> I have a strange problem with the accounting: I set a couple >>> of AVPs for every message that arrives at the server. I'm sure >>> they are there because they are written in the syslog logging. >>> Sometimes, when an INVITE is relayed (with transactions) and >>> receives an error (488, 422, etc.), in the SQL logging there >>> is no more presence of the AVPs! >>> Is this a known problem? >>> How can I avoid this? >>> >>> >>> Thanks. >>

Hi Frederico,

it;s not sure for me what the scenario is: you have calls to PSTN which hits failure_route in order to perform auth and from mangling via UAC module, right?

and if there are retransmissions of the INVITE the AVPs disappear - where exactly on the path? can pin point? and if there are no retransmissions, everything is ok?

by the way we are talking about ACK or INVITE?

regards, bogdan

Federico Giannici wrote:

The problem is surely related to the retrasmission of the INVITEs and probably to the UAC module.

I was able to reproduce the problem (AVPs vanishing) by adding a delay of 3 seconds for every message received. In this way a caused a couple of retrasmission for each message. Moreover that occurred only to the calls to a PSTN gateway using by the UAC module for authenticatuion and From substitution.

In this case the INVITE's AVPs are no more present when the INVITE is logged by the ACC module (even if they were present before entering the transaction engine).

If calls are made to other voip users (not using the UAC module) or if there is non INVITE retrasmission, the AVPs are correctly found.

BTW, I used the t_lookup_request() function to test if the message is a retrasmission. It turned out that that INVITE and BYE retrasmissions are correctly identified, but not the ACK retrasmission. I don't know if this is the correct behaviour.

I hope this information can be useful to find the problem.

Thanks.

Federico Giannici wrote:

...

The mistery keeps increasing!

I have found that if I set an AVP in an INVITE message, then the same AVP is logged in the ACCOUNTING of the corresponding ACK message!

But it is NOT in the ACK message before it enters the transaction engine (with a t_relay()). So it is the transaction engine that "copies" the INVITE AVPS to the ACK. Or the accounting routines use the AVPs from the corresponding INVITE instead of the ACK ones.

Is this the expected behaviour? Why this happens?

Thanks.

Federico Giannici wrote:

...

I'm still not able to make these errors reproducible.

Now I found that the "AVPs vanishing" occours with 200 OK situations too. It seems to be related to packets retransmission. They occur when the following errors are logged:

Nov 28 22:28:30 eowyn OpenSER[3010]: ERROR: t_newtran: transaction already in process 0x502bbc58 Nov 28 22:28:30 eowyn OpenSER[3010]: ERROR: sl_reply_error used: I'm terribly sorry, server error occurred (1/SL)

These are generated by this classic code:

if ( !t_relay() ) { sl_reply_error(); }

Now I'm asking myself: is it correct to reply to a message that is a retrasmission? Shouldn't we simply ignore it? Couldn't it confuse the UAs?

Thanks.

Federico Giannici wrote:

...

Bogdan-Andrei Iancu wrote:

...

Hi Federico,

use avp_print() (works only with debug=9) in failure_route to inspect the list of present AVP. maybe you do not have the AVPs you are trying to log.

But I set those AVPs in EVERY message received by the server. Moreover, I'm SURE they are there because before forwarding those INVITEs with t_relay() I log the messages to syslog and the AVPs ARE THERE.

Then, when some kind of errors are received (488, 422, etc.) it seems that those AVPs are "lost" by the transaction engine... But I'm not sure what conditions cause this lost.

Bye.

...

Federico Giannici wrote:

...

Daniel-Constantin Mierla wrote:

> Hello, > > have you set the flag to log missed transaction? > http://openser.org/docs/modules/1.0.x/acc.html#AEN407

No, I set the following:

modparam("acc", "db_flag", 1) modparam("acc", "failed_transaction_flag", 1)

But no "db_missed_flag". Anyway:

1. I don't want to log missed calls in a separate table.

2. The failed INVITEs are actually logged in the normal table,

but the AVPs I set are not logged (it seems that they are not found).

In normal cases the AVP are correctly logged. Even in many error cases (404, and so on) they are logged too. But in some cases, with strange errors (488, 422), the AVPs are NOT logged (accounting is done, but AVPs are "n\a")!

Any explanation of this?

Thanks.

> Or is that the some avps are not any more stored for failed > transaction? Maybe some snippets of your config will give us > more hints about what happens there. > > Cheers, > Daniel > > On 11/26/05 14:04, Federico Giannici wrote: > >> I'm using OpenSER 1.0.0 on OpenBSD 3.7 amd64. >> >> I have a strange problem with the accounting: I set a couple of >> AVPs for every message that arrives at the server. I'm sure >> they are there because they are written in the syslog logging. >> Sometimes, when an INVITE is relayed (with transactions) and >> receives an error (488, 422, etc.), in the SQL logging there is >> no more presence of the AVPs! >> Is this a known problem? >> How can I avoid this? >> >> >> Thanks. >

Hi, Bogdan.

I have found the exact situation and function that cause the problem: it is the uac_replace_from() function when called by an INVITE retrasmission!

I discovered this because I found that I can avoid the problem simply testing if an INVITE is a retrasmission (with the t_lookup_request() function) and in this case immediatly execute an "exit". In this way the AVPs no longer disapper from the accounting.

If I position this test immediately before the call to uac_replace_from(), then the AVPs are still present. If I position this test immediately after the call to uac_replace_from(), then the AVPs disappear from the accounting!

Now, I think that you should intervene because I think that I don't have the "know how" to fully understand the internal functioning of the uac_replace_from()...

Tell me if you need any more information.

Bye.

Federico Giannici wrote:

Bogdan-Andrei Iancu wrote:

...

Hi Frederico,

it;s not sure for me what the scenario is: you have calls to PSTN which hits failure_route in order to perform auth and from mangling via UAC module, right?

Yes.

Actually, the from mangling is done in the route, the auth mangling in the failure_route.

...

and if there are retransmissions of the INVITE the AVPs disappear - where exactly on the path?

They are still there at the end of the route (after the final t_relay), before and after the corresponding onreply_route and failure_route. But they are not there when the accounting is done.

...

can pin point? and if there are no retransmissions, everything is ok?

Yes, with no retrasmission I never found that they disappear. Moreover I was able to reproduce the problem only when the UAC module is used.

...

by the way we are talking about ACK or INVITE?

I'm talking about the INVITE.

I'm not an expert of SER internals, but I have a suggestion: could it be related to the way the uac_auth() function (in modules/uac/auth.c) chooses the branch to use when there is a retrasmit?

Thanks.

...

Federico Giannici wrote:

...

The problem is surely related to the retrasmission of the INVITEs and probably to the UAC module.

I was able to reproduce the problem (AVPs vanishing) by adding a delay of 3 seconds for every message received. In this way a caused a couple of retrasmission for each message. Moreover that occurred only to the calls to a PSTN gateway using by the UAC module for authenticatuion and From substitution.

In this case the INVITE's AVPs are no more present when the INVITE is logged by the ACC module (even if they were present before entering the transaction engine).

If calls are made to other voip users (not using the UAC module) or if there is non INVITE retrasmission, the AVPs are correctly found.

BTW, I used the t_lookup_request() function to test if the message is a retrasmission. It turned out that that INVITE and BYE retrasmissions are correctly identified, but not the ACK retrasmission. I don't know if this is the correct behaviour.

I hope this information can be useful to find the problem.

Thanks.

Federico Giannici wrote:

...

The mistery keeps increasing!

I have found that if I set an AVP in an INVITE message, then the same AVP is logged in the ACCOUNTING of the corresponding ACK message!

But it is NOT in the ACK message before it enters the transaction engine (with a t_relay()). So it is the transaction engine that "copies" the INVITE AVPS to the ACK. Or the accounting routines use the AVPs from the corresponding INVITE instead of the ACK ones.

Is this the expected behaviour? Why this happens?

Thanks.

Federico Giannici wrote:

...

I'm still not able to make these errors reproducible.

Now I found that the "AVPs vanishing" occours with 200 OK situations too. It seems to be related to packets retransmission. They occur when the following errors are logged:

Nov 28 22:28:30 eowyn OpenSER[3010]: ERROR: t_newtran: transaction already in process 0x502bbc58 Nov 28 22:28:30 eowyn OpenSER[3010]: ERROR: sl_reply_error used: I'm terribly sorry, server error occurred (1/SL)

These are generated by this classic code:

if ( !t_relay() ) { sl_reply_error(); }

Now I'm asking myself: is it correct to reply to a message that is a retrasmission? Shouldn't we simply ignore it? Couldn't it confuse the UAs?

Thanks.

Federico Giannici wrote:

...

Bogdan-Andrei Iancu wrote:

> Hi Federico, > > use avp_print() (works only with debug=9) in failure_route to > inspect the list of present AVP. maybe you do not have the AVPs > you are trying to log.

But I set those AVPs in EVERY message received by the server. Moreover, I'm SURE they are there because before forwarding those INVITEs with t_relay() I log the messages to syslog and the AVPs ARE THERE.

Then, when some kind of errors are received (488, 422, etc.) it seems that those AVPs are "lost" by the transaction engine... But I'm not sure what conditions cause this lost.

Bye.

> Federico Giannici wrote: > >> Daniel-Constantin Mierla wrote: >> >>> Hello, >>> >>> have you set the flag to log missed transaction? >>> http://openser.org/docs/modules/1.0.x/acc.html#AEN407 >> >> >> >> >> >> >> >> >> >> No, I set the following: >> >> modparam("acc", "db_flag", 1) >> modparam("acc", "failed_transaction_flag", 1) >> >> But no "db_missed_flag". >> Anyway: >> >> 1) I don't want to log missed calls in a separate table. >> >> 2) The failed INVITEs are actually logged in the normal table, >> but the AVPs I set are not logged (it seems that they are not >> found). >> >> In normal cases the AVP are correctly logged. Even in many error >> cases (404, and so on) they are logged too. But in some cases, >> with strange errors (488, 422), the AVPs are NOT logged >> (accounting is done, but AVPs are "n\a")! >> >> Any explanation of this? >> >> Thanks. >> >> >>> Or is that the some avps are not any more stored for failed >>> transaction? Maybe some snippets of your config will give us >>> more hints about what happens there. >>> >>> Cheers, >>> Daniel >>> >>> On 11/26/05 14:04, Federico Giannici wrote: >>> >>>> I'm using OpenSER 1.0.0 on OpenBSD 3.7 amd64. >>>> >>>> I have a strange problem with the accounting: I set a couple >>>> of AVPs for every message that arrives at the server. I'm sure >>>> they are there because they are written in the syslog logging. >>>> Sometimes, when an INVITE is relayed (with transactions) and >>>> receives an error (488, 422, etc.), in the SQL logging there >>>> is no more presence of the AVPs! >>>> Is this a known problem? >>>> How can I avoid this? >>>> >>>> >>>> Thanks.

Bogdan-Andrei Iancu wrote:

Hi Federico,

thanks for troubleshooting it so far..really helpful . I will start looking what might be the impact of uac_replace_from() over the avps.....

Nice to hear you, Bogdan.

I looked at the source of uac_replace_from() and cannot see anything related to AVPs. Probably the real problem is in the TM engine, and uac_replace_from() simply "trigger" it. Anyway, you will surely be better than me to find the real cause...

regards, bogdan

PS: what from_restore_mode are you using?

I'm using "auto".

Bye.

Federico Giannici wrote:

...

Hi, Bogdan.

I have found the exact situation and function that cause the problem: it is the uac_replace_from() function when called by an INVITE retrasmission!

I discovered this because I found that I can avoid the problem simply testing if an INVITE is a retrasmission (with the t_lookup_request() function) and in this case immediatly execute an "exit". In this way the AVPs no longer disapper from the accounting.

If I position this test immediately before the call to uac_replace_from(), then the AVPs are still present. If I position this test immediately after the call to uac_replace_from(), then the AVPs disappear from the accounting!

Now, I think that you should intervene because I think that I don't have the "know how" to fully understand the internal functioning of the uac_replace_from()...

Tell me if you need any more information.

Bye.

Federico Giannici wrote:

...

Bogdan-Andrei Iancu wrote:

...

Hi Frederico,

it;s not sure for me what the scenario is: you have calls to PSTN which hits failure_route in order to perform auth and from mangling via UAC module, right?

Yes.

Actually, the from mangling is done in the route, the auth mangling in the failure_route.

...

and if there are retransmissions of the INVITE the AVPs disappear - where exactly on the path?

They are still there at the end of the route (after the final t_relay), before and after the corresponding onreply_route and failure_route. But they are not there when the accounting is done.

...

can pin point? and if there are no retransmissions, everything is ok?

Yes, with no retrasmission I never found that they disappear. Moreover I was able to reproduce the problem only when the UAC module is used.

...

by the way we are talking about ACK or INVITE?

I'm talking about the INVITE.

I'm not an expert of SER internals, but I have a suggestion: could it be related to the way the uac_auth() function (in modules/uac/auth.c) chooses the branch to use when there is a retrasmit?

Thanks.

...

Federico Giannici wrote:

...

The problem is surely related to the retrasmission of the INVITEs and probably to the UAC module.

I was able to reproduce the problem (AVPs vanishing) by adding a delay of 3 seconds for every message received. In this way a caused a couple of retrasmission for each message. Moreover that occurred only to the calls to a PSTN gateway using by the UAC module for authenticatuion and From substitution.

In this case the INVITE's AVPs are no more present when the INVITE is logged by the ACC module (even if they were present before entering the transaction engine).

If calls are made to other voip users (not using the UAC module) or if there is non INVITE retrasmission, the AVPs are correctly found.

BTW, I used the t_lookup_request() function to test if the message is a retrasmission. It turned out that that INVITE and BYE retrasmissions are correctly identified, but not the ACK retrasmission. I don't know if this is the correct behaviour.

I hope this information can be useful to find the problem.

Thanks.

Federico Giannici wrote:

...

The mistery keeps increasing!

I have found that if I set an AVP in an INVITE message, then the same AVP is logged in the ACCOUNTING of the corresponding ACK message!

But it is NOT in the ACK message before it enters the transaction engine (with a t_relay()). So it is the transaction engine that "copies" the INVITE AVPS to the ACK. Or the accounting routines use the AVPs from the corresponding INVITE instead of the ACK ones.

Is this the expected behaviour? Why this happens?

Thanks.

Federico Giannici wrote:

> I'm still not able to make these errors reproducible. > > Now I found that the "AVPs vanishing" occours with 200 OK > situations too. It seems to be related to packets retransmission. > They occur when the following errors are logged: > > Nov 28 22:28:30 eowyn OpenSER[3010]: ERROR: t_newtran: > transaction already in process 0x502bbc58 > Nov 28 22:28:30 eowyn OpenSER[3010]: ERROR: sl_reply_error used: > I'm terribly sorry, server error occurred (1/SL) > > These are generated by this classic code: > > if ( !t_relay() ) > { > sl_reply_error(); > } > > Now I'm asking myself: is it correct to reply to a message that > is a retrasmission? Shouldn't we simply ignore it? Couldn't it > confuse the UAs? > > Thanks. > > > > Federico Giannici wrote: > >> Bogdan-Andrei Iancu wrote: >> >>> Hi Federico, >>> >>> use avp_print() (works only with debug=9) in failure_route to >>> inspect the list of present AVP. maybe you do not have the AVPs >>> you are trying to log. >> >> >> >> >> >> >> >> >> >> But I set those AVPs in EVERY message received by the server. >> Moreover, I'm SURE they are there because before forwarding >> those INVITEs with t_relay() I log the messages to syslog and >> the AVPs ARE THERE. >> >> Then, when some kind of errors are received (488, 422, etc.) it >> seems that those AVPs are "lost" by the transaction engine... >> But I'm not sure what conditions cause this lost. >> >> Bye. >> >> >>> Federico Giannici wrote: >>> >>>> Daniel-Constantin Mierla wrote: >>>> >>>>> Hello, >>>>> >>>>> have you set the flag to log missed transaction? >>>>> http://openser.org/docs/modules/1.0.x/acc.html#AEN407 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> No, I set the following: >>>> >>>> modparam("acc", "db_flag", 1) >>>> modparam("acc", "failed_transaction_flag", 1) >>>> >>>> But no "db_missed_flag". >>>> Anyway: >>>> >>>> 1) I don't want to log missed calls in a separate table. >>>> >>>> 2) The failed INVITEs are actually logged in the normal table, >>>> but the AVPs I set are not logged (it seems that they are not >>>> found). >>>> >>>> In normal cases the AVP are correctly logged. Even in many >>>> error cases (404, and so on) they are logged too. But in some >>>> cases, with strange errors (488, 422), the AVPs are NOT logged >>>> (accounting is done, but AVPs are "n\a")! >>>> >>>> Any explanation of this? >>>> >>>> Thanks. >>>> >>>> >>>>> Or is that the some avps are not any more stored for failed >>>>> transaction? Maybe some snippets of your config will give us >>>>> more hints about what happens there. >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>> On 11/26/05 14:04, Federico Giannici wrote: >>>>> >>>>>> I'm using OpenSER 1.0.0 on OpenBSD 3.7 amd64. >>>>>> >>>>>> I have a strange problem with the accounting: I set a couple >>>>>> of AVPs for every message that arrives at the server. I'm >>>>>> sure they are there because they are written in the syslog >>>>>> logging. Sometimes, when an INVITE is relayed (with >>>>>> transactions) and receives an error (488, 422, etc.), in the >>>>>> SQL logging there is no more presence of the AVPs! >>>>>> Is this a known problem? >>>>>> How can I avoid this? >>>>>> >>>>>> >>>>>> Thanks.