> > _Problem_: > > > > The check that is currently done to determine whether or > not to close > > off the CDR record for the potentially failed or long > duration calls > > is to calculate the difference between the start time of > the call and > > the last time a CSE was received for this call. > > I do not believe it's true: call resolver checks the time > between the start of the call and the time cse was received > for _any_ call (not _this_ call as you write). > > Check the code. The condition looks like this: > > @last_event_time - start_time > max_call_len > > last_event_time is a time recorded from the last received CSE > (for any call). It works as long as you have new CSEs. > > [...] Damian, you're correct about the last_event_time and I knew that. I guess my brain was on holidays when I wrote that. > > > > > _Proposed Solution_: > > > > CSEs are processed by the "sipxcallresolver" into CDR records in > > essentially the same time that they occurred (sipxcallresolver > > processes them every 10 seconds). The potentially failed calls and > > long duration calls are examined every 5 minutes to > determine whether > > or not they've exceeded their time limits. > > > > Rather than do a time difference between the start and last > received > > CSEs, I think that a valid solution is to do a time > difference between > > the start time and the current system time. In other words: > > > > If (current time - start time of call) > 180 seconds then > > close off the cdr record (as a failed call) > > write the cdr record to the database End > > > > You cannot use the current system time. > > Let's say you analyze the CSEs from a week ago. You read CSE > request, then your code kicks in and you declare the call to > be over a week long. > You flush CDR before you had a chance to read BYE CSE.
Under what conditions would you be analysing CSEs from a week ago? The CSEs are analyzed usually within 10 seconds of them being generated and never looked at again. > > There is a much better solution for that: call resolver > reader threads should generate tick events if nothing has > been read from DB. > See discussion here: http://track.sipfoundry.org/browse/XECS-741 > I looked at this but found it to be a more difficult solution than using the current time. If there is some reason why CSEs wouldn't be analyzed soon after they're generated then you're correct that current time cannot be used and that I should look more closely at implementing your suggestion. > > > > > > Is there anything wrong with this logic? I can't see why this > > solution wouldn't work but maybe its because I'm still > relatively new to sipX. > > > > > > Thanks in advance > > > > > > > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
