26 Feb
2003
26 Feb
'03
5:18 p.m.
I realize the accounting logging of ACK is only an attempt, but ...
It does seem fairly important in determining when the actual
call started.
Here is some filtered output from the syslog accounting output file:
--- -------- -------- -------- --- ---------- ----------
Call INVITE ACC BYE Length From To
--- -------- -------- -------- --- ---------- ----------
1 18:50:39 18:50:39 18:50:48 9 4695461243 -> 9723236598
2 18:53:19 18:53:19 19:08:46 927 4695461243 -> 9723937976
3 20:14:00 0 4695461246 -> 4695461235
4 20:16:41 20:16:48 7 4695461246 -> 4695461235
5 20:19:09 20:19:17 8 4695461246 -> 4695461235
6 20:30:18 20:30:23 5 4695461235 -> 4695461235
7 20:30:51 20:31:01 10 4695461246 -> 4695461235
8 20:37:14 20:37:17 3 4695461246 -> 4695461235
9 21:02:08 21:03:28 80 4695461235 -> 4695461240
10 21:21:26 21:21:26 21:36:33 907 4695461235 -> 4695461243
11 22:42:03 22:42:03 22:52:23 620 4695461235 -> 4695461235
12 22:59:22 22:59:33 11 4695461246 -> 4695461235
13 23:00:46 23:01:00 14 4695461246 -> 4695461235
14 23:08:11 23:08:21 10 4695461246 -> 4695461235
15 23:19:37 23:19:37 23:19:41 4 4695461235 -> 4695461235
16 23:22:49 23:22:56 7 4695461235 -> 4695461235
17 23:28:55 23:28:55 23:29:07 12 4695461235 -> 4695461243
18 23:29:18 23:29:18 23:42:53 815 4695461235 -> 4695461243
19 09:08:11 09:08:11 09:08:52 41 9725678129 -> 4695461236
20 09:09:50 09:10:38 48 4695461236 -> 99727139968
21 09:11:15 09:12:00 45 4695461236 -> 99727139968
22 09:12:35 09:12:35 09:13:39 64 2143357976 -> 4695461240
23 09:18:57 09:18:57 09:19:29 32 4695461235 -> 9724620762
24 09:23:17 09:24:25 68 4695461235 -> 4695461240
--- -------- -------- -------- --- ---------- ----------
I note the ACK times are all the same as the INVITE times.
Isn't the wrong ACK being recorded? Is this a problem with
my .cfg? A much more useful ACK would be the second one (when the
far end ACKs after the 180 Ringing and 200 OK messages.
A typical call, from UA perspective:
INVITE ->
401 unauth.. <-
ACK -> (evidently, the one being accounted)
INVITE (with cred) ->
100 Trying <-
180 Ringing <-
200 OK <-
ACK -> (the ACK that SHOULD be accounted, IMHO)
...
---greg
26 Feb
26 Feb
7:08 p.m.
At 05:18 PM 2/26/2003, Greg Fausak wrote:
I realize the accounting logging of ACK is only an
attempt, but ...
It does seem fairly important in determining when the actual
call started.
I'm little a bit reluctant to go into the ACK-accounting bussiness
for reasons of how SIP is built.
In my opinon, one can consider a call to begin when 200 is sent out.
The problem with 200/ACK is that it is not a part of transaction.
Why does it matter? Well, that's because a proxy server cannot
recognize (even if ACK is forced to visit it through proxy
through record-routing) whether an ACK belongs to an INVITE or
not. It might have take a different upstream path and have thus
different transaction identifier in Via/branch. Ambiguities
would even exist if we tried dialog matching instead -- you
may have forwarding resulting in spirals and then you would not
really know to which of the dialogs the ACK belongs.
If you were really so much interested in it, we could introduce
some "transaction-matching parameter" to record-routes and try to
match them. That's doable, though not right immediatelly.
-Jiri
[...]
I note the ACK times are all the same as the INVITE
times.
Isn't the wrong ACK being recorded? Is this a problem with
my .cfg? A much more useful ACK would be the second one (when the
far end ACKs after the 180 Ringing and 200 OK messages.
A typical call, from UA perspective:
INVITE ->
401 unauth.. <-
ACK -> (evidently, the one being accounted)
One can match negative ACKs but they maintain only a transport
role -- I would not wait for it, with 401, the transaction is
complete.
INVITE (with cred) ->
100 Trying <-
180 Ringing <-
200 OK <-
ACK -> (the ACK that SHOULD be accounted, IMHO)
All is already decided when 200 is sent. Also, 200-ACKs are not
easy to account, see above.
-Jiri
7:31 p.m.
At 05:18 PM 2/26/2003, Greg Fausak wrote:
I agree. Wouldn't it make sense to write an accounting record for
the OK200 message, and skip the ACK accounting, since it really
doesn't mean anything. I mean, the wrong ACK is being accounted anyway.
---greg
I realize the accounting logging of ACK is only an
attempt, but ...
It does seem fairly important in determining when the actual
call started.
I'm little a bit reluctant to go into the ACK-accounting bussiness
for reasons of how SIP is built.
In my opinon, one can consider a call to begin when 200 is sent out. The problem with 200/ACK is that it is not a part of
transaction.
Why does it matter? Well, that's because a proxy server cannot
recognize (even if ACK is forced to visit it through proxy
through record-routing) whether an ACK belongs to an INVITE or
not. It might have take a different upstream path and have thus
different transaction identifier in Via/branch. Ambiguities
would even exist if we tried dialog matching instead -- you
may have forwarding resulting in spirals and then you would not
really know to which of the dialogs the ACK belongs.
If you were really so much interested in it, we could introduce
some "transaction-matching parameter" to record-routes and try to
match them. That's doable, though not right immediatelly.
-Jiri
[...]
I note the ACK times are all the same as the
INVITE times.
Isn't the wrong ACK being recorded? Is this a problem with
my .cfg? A much more useful ACK would be the second one (when the
far end ACKs after the 180 Ringing and 200 OK messages.
A typical call, from UA perspective:
INVITE ->
401 unauth.. <-
ACK -> (evidently, the one being accounted)
One can match negative ACKs but they maintain only a transport
role -- I would not wait for it, with 401, the transaction is
complete.
INVITE (with cred) ->
100 Trying <-
180 Ringing <-
200 OK <-
ACK -> (the ACK that SHOULD be accounted, IMHO)
All is already decided when 200 is sent. Also, 200-ACKs are not
easy to account, see above.
-Jiri
7:52 p.m.
Just set the acc option "report_ack" to 0.
-Jiri
At 07:31 PM 2/26/2003, Greg Fausak wrote:
I agree. Wouldn't it make sense to write an
accounting record for
the OK200 message, and skip the ACK accounting, since it really
doesn't mean anything. I mean, the wrong ACK is being accounted anyway.
---greg
7739
days inactive
7739
days old
3 comments
3 participants
participants (3)
-
Greg Fausak -
Jiri Kuthan -
lgfausakļ¼ august.net