Raymond Dans wrote: > I've recently been working on an issue whereby the sipxcallresolver is > not properly flushing CDR records to the database for failed or long > call scenarios. The solution that I've proposed has been questioned and > I'd like to get people's thoughts on it. Sorry for the lengthy e-mail > but not very many people have looked at the sipxcallresolver > functionality so I decided to describe basically how it works. > > _Background_: > > "sipXproxy" generates call state events (CSE) based on the SIP messages > it has processed. These CSEs are written to the postgres database for > later processing by the "sipxcallresolver" (CDR record generator). > > Every 10 seconds or so, the "sipxcallresolver" process wakes up, reads > the latest CSEs from the database and begins generating a CDR record. > Once a complete CDR record is generated, the information is written to > another table in the postgres database. > > When building a CDR record, they are classed into currently active, > potentially failed calls and potentially long duration calls. To > determine when a CDR record is complete and should be written to the > database, the following criteria is used: > > 1. Call has ended successfully. > 2. Call appears to have failed (because of a CSE indicating a rejection > or failure type event) and we've not received any new CSEs for this call > in over 180 seconds. > > 3. Call has been active for a very very long time ( > 8 hours) - the > thought here is that we missed or lost a CSE indicating end of call. > > Every 5 minutes, a thread checks the potentially failed queue and long > duration calls queue and based on the time duration from the start of > the call determines whether or not to complete the records and write > them to the database as either failed or long duration. > > _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. [...] > > _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. 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 > > > 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
