7 Aug
2006
7 Aug
'06
4:32 p.m.
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
7 Aug
7 Aug
7:48 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
8:43 p.m.
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
9:33 p.m.
On 08/07/06 20:43, Andreas Granig wrote:
Daniel-Constantin Mierla wrote:
... 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.
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.
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
8 Aug
8 Aug
12:11 p.m.
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
12:44 p.m.
On 08/08/06 12:11, 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.
For missed calls, it logs the call leg, so each callee which was tried
sees the call attempt.
Cheers,
Daniel
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
3:06 p.m.
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
9 Aug
9 Aug
6:54 p.m.
On 08/08/06 15:06, Andreas Granig wrote:
Daniel-Constantin Mierla wrote:
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
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
6682
days inactive
6684
days old
7 comments
2 participants
participants (2)
-
Andreas Granig -
Daniel-Constantin Mierla