Hi,
In a scenario A -> OpenSER -> B with the request being INVITE, B sends back 404 to OpenSER (the flag "db_missed_flag" of the acc module is set). OpenSER forks serially and sends another request to C, which is answered with 200.
Now I get two acc records, the 404 from B because of the missed-flag and the 200 from C. Now is there a way to selectively suppress the acc record for the 404 in the failure route? Concretely I'd like to decide in the failure route whether that transaction is being accounted.
Thanks, Andy
Hello,
On 08/07/06 16:32, Andreas Granig wrote:
Hi,
In a scenario A -> OpenSER -> B with the request being INVITE, B sends back 404 to OpenSER (the flag "db_missed_flag" of the acc module is set). OpenSER forks serially and sends another request to C, which is answered with 200.
Now I get two acc records, the 404 from B because of the missed-flag and the 200 from C. Now is there a way to selectively suppress the acc record for the 404 in the failure route? Concretely I'd like to decide in the failure route whether that transaction is being accounted.
try to use acc_db_request() instead of db_missed_flag for failed transactions. Maybe a look into the code would reveal how the callbacks for accounting are executed and so see if resetting the missed flag in failure route will prevent logging the 404.
Cheers, Daniel
Thanks, Andy
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Daniel-Constantin Mierla wrote:
try to use acc_db_request() instead of db_missed_flag for failed transactions. Maybe a look into the code would reveal how the callbacks for accounting are executed and so see if resetting the missed flag in failure route will prevent logging the 404.
By resetting the flag in the reply route the acc record can be suppressed, but it would be an ugly hack to check in the reply route if there will be serial forking in the failure route.
On the other hand, acc_db_request() doesn't log the response code if called in the failure route, so it seems to become be a hack anyway.
Thanks, Andy
On 08/07/06 20:43, Andreas Granig wrote:
Daniel-Constantin Mierla wrote:
try to use acc_db_request() instead of db_missed_flag for failed transactions. Maybe a look into the code would reveal how the callbacks for accounting are executed and so see if resetting the missed flag in failure route will prevent logging the 404.
By resetting the flag in the reply route the acc record can be suppressed, but it would be an ugly hack to check in the reply route
... yep, kind of ...
But in case of 404 the record should be in missed calls table, so B can see that someone tried to call it. The 200OK is recorded in acc table so you can bill it.
if there will be serial forking in the failure route.
On the other hand, acc_db_request() doesn't log the response code if called in the failure route, so it seems to become be a hack anyway.
you can give the reason as parameter to acc_db_request, but it does not have much flexibility. However, there is another flag for failed transactions
http://www.openser.org/docs/modules/1.1.x/acc.html#AEN229
You may get what you want by using this.
Cheers, Daniel
Thanks, Andy
Daniel-Constantin Mierla wrote:
But in case of 404 the record should be in missed calls table, so B can see that someone tried to call it. The 200OK is recorded in acc table so you can bill it.
We run a self-made mediation system, so we're logging everything into acc table. However, just for accounting I think it will be sufficient to build a small mapping route for the most common error codes to be used with acc_db_request().
But maybe we could extend the function to use the last reply code in the future?
Andy
On 08/08/06 12:11, Andreas Granig wrote:
Daniel-Constantin Mierla wrote:
But in case of 404 the record should be in missed calls table, so B can see that someone tried to call it. The 200OK is recorded in acc table so you can bill it.
We run a self-made mediation system, so we're logging everything into acc table. However, just for accounting I think it will be sufficient to build a small mapping route for the most common error codes to be used with acc_db_request().
But maybe we could extend the function to use the last reply code in the future?
acc module records only the selected code for billing purposes. In case of parallel/serial forking when many reply codes were received, an algorithm selects the code to be sent upstram, and that code is written in acc as well.
For missed calls, it logs the call leg, so each callee which was tried sees the call attempt.
Cheers, Daniel
Andy
Daniel-Constantin Mierla wrote:
acc module records only the selected code for billing purposes. In case of parallel/serial forking when many reply codes were received, an algorithm selects the code to be sent upstram, and that code is written in acc as well.
Ok, after struggling with the missed-calls-flag, I completely disabled this one and now use the failed-transaction-flag (which was disabled before), which is working as expected.
For missed calls, it logs the call leg, so each callee which was tried sees the call attempt.
And what exactly is logged when using the failed-transaction-flag? I just know that it works now, but I'm currently completely confused about the difference between these two :o/
Andy
On 08/08/06 15:06, Andreas Granig wrote:
Daniel-Constantin Mierla wrote:
acc module records only the selected code for billing purposes. In case of parallel/serial forking when many reply codes were received, an algorithm selects the code to be sent upstram, and that code is written in acc as well.
Ok, after struggling with the missed-calls-flag, I completely disabled this one and now use the failed-transaction-flag (which was disabled before), which is working as expected.
For missed calls, it logs the call leg, so each callee which was tried sees the call attempt.
And what exactly is logged when using the failed-transaction-flag? I just know that it works now, but I'm currently completely confused about the difference between these two :o/
missed call flag should be set to reports to users the calls they were not able to answer. A transaction fails when there is a negative reply sent back to caller. Since in the context of a transaction may be several attempts to different users, those users should see that they missed a call. Overall, it was just one failed transaction.
Cheers, Daniel
Andy
-
Andreas Granig -
Daniel-Constantin Mierla