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