Damian wrote: >Subject: Re: [sipX-dev] XECS-2153 - CDRs shows 0 seconds >duration for calls that have been active for 10 hours or more > >Raymond Dans wrote: >> This issue deals with the case of the Proxy Call State Event >Observer >> missing an end of call (BYE) message. >> >> To trap this type of scenario, CDR will periodically check for calls >> that have been active for a long time (ie. > 8 hours is the current >> default) and when it finds one, it will close the CDR record >and write >> it to the database. > >It's SIP_CALLRESOLVER_MAX_CALL_LEN right? >Would be trivial to make it advanced parameter in sipXconfig. >
Yes, I'd be using SIP_CALLRESOLVER_MAX_CALL_LEN. Adding the parameter to sipXconfig advanced parameters could make it more flexible and maybe should be something we look at in the future. >> >> This issue deals with the fact that the record shows a total >time of 0 >> seconds and a call status of "Completed". >> >> To resolve this issue, I'd like to do 2 things: >> >> 1. Provide a total time value which represents the current >long call >> timeout value. Even though putting in this value is not accurate >> (since we don't know when the call ended or even if it has >ended), it >> is better for Call Accounting to have something other than 0 in it. >> >> 2. Instead of marking the call as "Completed" to introduce a new >> Status type of "Long Call". > >You are effectively going to put SIP_CALLRESOLVER_MAX_CALL_LEN right? > Yes (as above). >If someone is really using this for tracking the call time: is >it really fair that we would be setting quite a large value >for those calls just because proxy did not see or fail to log >the termination event? > >I would think that having a different state would be enough. > Neither setting the time to 0 nor to SIP_CALLRESOLVER_MAX_CALL_LEN would produce any more accurate results and would skew any statistics you generate. The only case where it could help to have it set to the max call length is that if the call truly lasted at least that long, the customer could at least be billed for that length of time. Raymond _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
