26 Feb
2003
26 Feb
'03
1: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