29 Jul
2006
29 Jul
'06
1:57 p.m.
well, unfrotunately we have seen a large list of reasons for such behaviour. As an
example,
once, a UA was on reboot generating all the same "random" callid all over again.
Sometimes
retransmissions come even after the transaction in SER timedout properly. Sometimes
clients
die and don't tell us. Sometimes, due to forking, multiple calls may be established.
It is
a lot of small sub-cases. We have been trying to help some providers with sorting out the
CDRs and it was about dilligent and patience collection of all possible (and impossible
too)
cases, which may fail under Morphy's laws.
So I think if you want to make it good and robust, you are left with tedious work.
one more hint: using just callid is not robust (forking, non-random UACs, etc...) you
need to sort by the dialog-identifying triple {from-tag,callid,to-tag}.
-jiri
At 13:01 29/07/2006, Steve Blair wrote:
We are generating accounting records for INVITE, BYE
and CANCEL methods. We use flatstore and rotate the files nightly via cron.daily. We
expected the number of each type of record to "add up". That is we expected each
INVITE to have either a BYE or CANCEL based on the Call-ID field but we are actually
getting duplicates and in some cases seem to get BYEs without a corresponding INVITE.
I think some of these BYE may be for calls initiated by the proxy to either our Asterisk
voicemail server or to another UA because of blind transfers initiated at the phone or
call forward always initiated by the proxy.
The trouble is we have 600+ subscribers and the logs are huge. I have used cat, grep and
sort to try and identify the mismatch but this is tedious at best. Does anyone have any
insight into why the mismatch might exist and suggestions for record matching based on the
Call-ID field.
We are using ser 0.9.7-pre3, Cisco 79x0 phones running 7.3 image and Cisco 2821 gateways
running 12.3(8)T11.
Thanks,Steve
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
--
Jiri Kuthan http://iptel.org/~jiri/