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. In the majority of cases, this time difference will never be over the limit that is checked (180 seconds for failed, 8 hours for long duration). For example on an incoming call, if its abandoned (i.e. far end has hung up) before its answered anywhere the difference between the start of the call and the last CSE for this call is usually only a couple of seconds. The time difference from the start of the call to last event will never exceed the 180 seconds and will then not be closed off and flushed to the database. 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 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
