On Mon, 20 Apr 2015, Calvin E. wrote:
Asterisk does have logging and can write CDR with start time and answer time. The exact details will depend on the version of Asterisk you are using.
For example, https://urldefense.proofpoint.com/v1/url?u=https://wiki.asterisk.org/wiki/di...
Watch for lines with "disposition" = "ANSWERED" and calculate the difference of "start" and "answer".
Indeed, and we currently measure that. Unfortunately the end receiver of the call determines the time between dial and answer, not the carrier, so that metric, while interesting, isn't all that useful.
Your requirements dictate that you know the PDD immediately, not as each call ends. You might have to do some digging to get that from the logs directly, or force CDRs to be written when calls are answered as well as when they end.
I could live with PDD being reported at the end of the call. Ideally though I should be able to see it as it happens though. CDRs don't help though. duration - billsec = 10 seconds, that's still the amount of time from the dial to the answer. Are you suggesting that I can infer that a carrier is having an increased PDD by noting the difference between the average ring-to-answer and the current ring-to-answer. It's a metric, not the ideal one, but I can see what you are getting at.
A "no ring timeout" setting will help to help route advance when facing unexpected PDD. 4 seconds is reasonable for most carriers, in my experience.
It would be great if carriers actually published the expectation.
This problem might already be solved by the asterisk community. Have you checked those forums/mailing lists?
No, I will spend some time digging.
Now might be the time to consider the future of your routing, rating, billing, monitoring, and alerting. The right solution now might save you considerable time and effort later.
If you really want to do this yourself, consider attaching your Asterisk boxes to a RADIUS server and doing your CDR crunching from there.
Again, the CDRs aren't really what I need. I already have 1/1 CDR tracking, an LCR system, an audit system from carrier CDRs, billing, monitoring and alerting. It would be nice if Asterisk output this into a sip.log Timestamp Type CallID From To 2015-04-20 23:40:21.812380 INVITE 4991c62d0c46cf37603d3e9675b74d4a at 10.9.8.7 sip:9520120000 at 10.9.8.7 sip:6460981122 at 10.20.30.40 2015-04-20 23:40:21.861749 100 4991c62d0c46cf37603d3e9675b74d4a at 10.9.8.7 sip:6460981122 at 10.20.30.40 sip:9520120000 at 10.9.8.7 2015-04-20 23:40:38.146872 183 4991c62d0c46cf37603d3e9675b74d4a at 10.9.8.7 sip:6460981122 at 10.20.30.40 sip:9520120000 at 10.9.8.7 A friend suggested this: * Pipe the live pcap output to something that decodes the SIP packet * If it is an INVITE, write the timestamp to a file named the CallID (may need to be bucketed by the first 3 characters of the callID) e.g. 4/9/9/4991c62d0c46cf37603d3e9675b74d4a-10.9.8.7 contains 1429587621.812380 * If it is a progress message * find the file * read the timestamp in the file * calculate the delta * determine the carrier based on the IP * post the metric * delete the file * Otherwise do nothing (discard) To keep things cleaned up you could run a cron job every 20 minutes that would delete files older than 3 hours (our max call length). Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------