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
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
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.
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
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
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
-
Greg Fausak -
Jiri Kuthan -
lgfausakļ¼ august.net