[VoiceOps] Easy ways to measure PDD

[Peter Beckman]

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/display/AST/Asterisk%2B12%2BCDR%2BSpecification&k=eghE%2F1871Dg5AgRfLcYONw%3D%3D%0A&r=6u4D%2FXrxCS2CFGDR%2F10ITB7whz3CLQp1FhOexohJiTo%3D%0A&m=p%2BnWYl7ATOEVGsxuFvlMaYlkq4B1R%2Fa1Q%2BiAwKdlEq4%3D%0A&s=acc7940148b3eb3494e6863ac37d86446b8dbfa3e0b8af811feb86c62908bb34
>
> 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/
---------------------------------------------------------------------------