15 Dec
2010
15 Dec
'10
1:36 p.m.
i have been using radius for accounting, but now looked at db accounting
for another project. couple of issues:
- why is sip reason (the comment after reply's reason code) a mandatory
field in accounting table? if someone offers a good reason, my
opinion is that it should be removed. if someone needs it, he/she can
add it to db_extra list.
- is there possibility to fall back to syslog accounting if database
insert fails?
-- juha
15 Dec
15 Dec
4:42 p.m.
Hello,
On 12/15/10 2:36 PM, Juha Heinanen wrote:
i have been using radius for accounting, but now
looked at db accounting
for another project. couple of issues:
- why is sip reason (the comment after reply's reason code) a mandatory
field in accounting table? if someone offers a good reason, my
opinion is that it should be removed. if someone needs it, he/she can
add it to db_extra list.
it is so from the early implementation. Not sure how is
with radius, but
the reason phrase is also taken from acc_db_request() parameter (comment
param) and stored in db.
- is there possibility to fall back to syslog
accounting if database
insert fails?
you can account to both at the same time, but internally there is
no
such mechanism, although would not be hard to implement.
One more thing, if you use acc_db_request(), if that fails then you can
call acc_log_request(), but I assumed you refer to usage of flags for
accounting.
Cheers,
Daniel
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
5:08 p.m.
Daniel-Constantin Mierla writes:
it is so from the early implementation. Not sure how
is with radius, but
the reason phrase is also taken from acc_db_request() parameter (comment
param) and stored in db.
in radius server i can choose, what actually gets written to db. the
fact that response reason text has been on the fixed list for ever is
not good enough reason for not removing it from the fixed list.
you can account to both at the same time, but
internally there is no
such mechanism, although would not be hard to implement.
One more thing, if you use acc_db_request(), if that fails then you can
call acc_log_request(), but I assumed you refer to usage of flags for
accounting.
yes,
--- juha
5:14 p.m.
On 12/15/10 6:08 PM, Juha Heinanen wrote:
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
Daniel-Constantin Mierla writes:
It is practically part of a parameter from acc_*_request() functions, so
it is not really a pseudo-variable that can be added to *_extra
parameter. This is a constraint for this case. For the acc with flags,
it is taken indeed from reply reason phrase.
Cheers,
Daniel
it is so from the early implementation. Not sure
how is with radius, but
the reason phrase is also taken from acc_db_request() parameter (comment
param) and stored in db.
in radius server i can choose, what actually gets written
to db. the
fact that response reason text has been on the fixed list for ever is
not good enough reason for not removing it from the fixed list. you can
account to both at the same time, but internally there is no
such mechanism, although would not be hard to implement.
One more thing, if you use acc_db_request(), if that fails then you can
call acc_log_request(), but I assumed you refer to usage of flags for
accounting.
yes,
--- juha
5147
days inactive
5147
days old
3 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Juha Heinanen