<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I don't think most end users or IT managers are going to agree with these definitions for PDD. If your customers complain to your local Public Utilities Commission or equivalent governing body, they're not complaining about time between SIP messages. They're talking about<a href="https://books.google.com/books?id=Byl4uDi-tBIC&pg=PA72&dq=post+dial+delay&hl=en&sa=X&ei=CXk2VebFNNKVyAT-sYH4Bg&ved=0CCkQ6AEwAg#v=onepage&q=post%20dial%20delay&f=false" class=""> "the time from output of the dialing signals...from the terminal of the calling subscriber until the ring-back tone is received."</a><div class=""><br class=""></div><div class=""><div class="">For all of my termination to the PSTN in the US, the ringback is in audio. To really get PDD, you'd need to process the audio channel and listen for voice energy. With G.711 it's probably pretty easy to decode just a little RTP to detect it. For example, you could look at the variance of the last 100 RTP payload byte values, and if they're zero then you've got silence.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class="">The signaling based methods we're all discussing here are actually measuring the time to establish a SIP dialog. That's certainly informative and it's easy to cheat: the UAS (downstream carriers) can start sending a 183 in place of 100. </div><div class=""><br class=""></div><div class="">To answer the OP question, I have a lot of fun with tshark -Tfields. You'd have to correlate the call IDs...for example,</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>tshark -i en6 -Y 'sip.CSeq.method==INVITE' -T fields -e frame.time_epoch -e sip.Call-ID -e sip.to.tag -e sip.Status-Code</div><div class=""><br class=""></div><div class="">You might get output like this:</div><div class=""><br class=""></div><div class=""><div class="">1429634006.467713000<span class="Apple-tab-span" style="white-space:pre"> </span>5ca341afb6da7cd2</div><div class="">1429634006.512273000<span class="Apple-tab-span" style="white-space:pre"> </span>5ca341afb6da7cd2<span class="Apple-tab-span" style="white-space:pre"> </span>100</div><div class="">1429634006.554476000<span class="Apple-tab-span" style="white-space:pre"> </span>5ca341afb6da7cd2<span class="Apple-tab-span" style="white-space:pre"> </span>1752914037-1429634006342<span class="Apple-tab-span" style="white-space:pre"> </span>401</div><div class="">1429634006.635424000<span class="Apple-tab-span" style="white-space:pre"> </span>5ca341afb6da7cd2</div><div class="">1429634006.678992000<span class="Apple-tab-span" style="white-space:pre"> </span>5ca341afb6da7cd2<span class="Apple-tab-span" style="white-space:pre"> </span>100</div><div class="">1429634010.485804000<span class="Apple-tab-span" style="white-space:pre"> </span>5ca341afb6da7cd2<span class="Apple-tab-span" style="white-space:pre"> </span>1553636734-1429634010302<span class="Apple-tab-span" style="white-space:pre"> </span>183</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">The fourth frame is the original INVITE; there's no Status-Code, but we have the call ID.</div><div class=""><br class=""></div><div class="">The final frame shows the establishment of the dialog. It took 3.85 seconds.</div><div class=""><br class=""></div><div class="">The To-Tag is important because you want to distinguish between initial INVITEs (which have no To-Tag until the dialog begins) and re-INVITEs (which have a To-Tag on the INVITE because they're in-dialog transactions.)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Because of the tshark/dumpcap interconnection using temporary files, tshark can't run forever. </div><div class=""><br class=""></div><div class=""><div class=""><div class=""> <br class=""> --- <a href="mailto:mark@ecg.co" class="">mailto:mark@ecg.co</a> <br class=""> tel:+1-229-316-0013 <br class=""> <a href="http://ecg.co/lindsey" class="">http://ecg.co/lindsey</a> <br class=""><br class=""><br class=""><br class=""></div><br class=""><blockquote type="cite" class="">On Apr 21, 2015, at 11:21 , Ivan Kovacevic <<a href="mailto:ivan.kovacevic@startelecom.ca" class="">ivan.kovacevic@startelecom.ca</a>> wrote:<br class=""><br class="">We have recently started measuring it (using FreeSwitch). It is the time<br class="">from the initial INVITE to the first provisional response (e.g. 180/183).<br class=""><br class="">Best Regards,<br class=""><br class="">Ivan Kovacevic<br class="">Vice President, Client Services<br class="">Star Telecom | <a href="http://www.startelecom.ca" class="">www.startelecom.ca</a> | SIP Based Services for Contact Centers<br class=""><br class=""><br class="">-----Original Message-----<br class="">From: VoiceOps [<a href="mailto:voiceops-bounces@voiceops.org" class="">mailto:voiceops-bounces@voiceops.org</a>] On Behalf Of Eric<br class="">Wieling<br class="">Sent: Tuesday, April 21, 2015 11:15 AM<br class="">To: Jesse Howard; Richard Jobson; Peter Beckman<br class="">Cc: VoiceOps<br class="">Subject: Re: [VoiceOps] Easy ways to measure PDD<br class=""><br class="">I thought PDD / Post Dial Delay was the time between the caller dialing<br class="">and the caller hearing ringback. If that is correct you will *never* get<br class="">PDD info out of Asterisk. Asterisk only tracks the time between dialing<br class="">and answer.<br class=""><br class=""><br class="">-----Original Message-----<br class="">From: VoiceOps [<a href="mailto:voiceops-bounces@voiceops.org" class="">mailto:voiceops-bounces@voiceops.org</a>] On Behalf Of Jesse<br class="">Howard<br class="">Sent: Tuesday, April 21, 2015 11:10 AM<br class="">To: Richard Jobson; Peter Beckman<br class="">Cc: VoiceOps<br class="">Subject: Re: [VoiceOps] Easy ways to measure PDD<br class=""><br class="">Isn't this exactly what the timeout option in the dial command is for on<br class="">Asterisk?<br class=""><br class="">You can both limit the maximum PDD and route advance/alert directly from<br class="">your dialplan.<br class=""><br class="">To be honest, ASR and ACD have always been more telling from trending<br class="">perspectives than PDD where I only care about PDD when it is overly long.<br class="">What it was before the current delay is usually irrelevant for the most<br class="">part especially since PDD tends to manifest for specific routes vs. the<br class="">carrier in general.<br class=""><br class="">Jesse<br class="">________________________________________<br class="">From: Richard Jobson [<a href="mailto:richard@teraquant.com" class="">richard@teraquant.com</a>]<br class="">Sent: Monday, April 20, 2015 11:16 PM<br class="">To: Peter Beckman<br class="">Cc: Calvin E.; VoiceOps<br class="">Subject: Re: [VoiceOps] Easy ways to measure PDD<br class=""><br class="">Well if it needs to be real-time, it is not really a CDR function.<br class="">Oracles Palladion/COM can do it out of the box. But there again you need<br class="">to install a box. You can install it on VME.<br class="">It will send you an SNMP trap or email in real-time as soon as the minute<br class="">average KPI (e.g. PDD) is exceeded per trunk. And Oracle has a reseller<br class="">who can make Palladion sing for its supper :)<br class=""><br class=""><br class="">On 4/20/15, 5:02 PM, "Peter Beckman" <<a href="mailto:beckman@angryox.com" class="">beckman@angryox.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Mon, 20 Apr 2015, Richard Jobson wrote:<br class=""><br class=""><blockquote type="cite" class="">Do you have an SBC or switch that already measures this and outputs<br class="">it with the CDR?<br class=""></blockquote><br class="">Nope.<br class=""><br class=""><blockquote type="cite" class="">Do you want to report on all PDD long-term? Or just one or two<br class="">specific calls?<br class=""></blockquote><br class="">Long term. A handful of Asterisk servers. Looking for what Calvin E.<br class="">suggested, except a tool that someone has already written. I can do<br class="">what Calvin suggests, but interpreted scripts are no match for C<br class="">compiled packet matching.<br class=""><br class="">What Calvin suggests is something that would work for a PCAP file<br class="">processed after the fact. I'm looking for something that would be<br class="">able to<br class="">catch the non-100 response for each INVITE and log it to a file or<br class="">send a<br class="">metric. Even if it has to wake up and parse a 80MB+ pcap file each<br class="">run to<br class="">find the PDD per Call-ID, then determine if that Call-ID has been<br class="">reported. Lots of caching of data... it can be done, but speed is<br class="">important and a scripting language is quick and dirty but unlikely to<br class="">be<br class="">fast and reliable.<br class=""><br class="">Does Asterisk support logging or emitting metrics like PDD?<br class=""><br class="">When a carrier jumps from <1 second Post Dial Delay to 20+ seconds<br class="">Post<br class="">Dial Delay I need (a) to know about it and (b) be able to demote them<br class="">in<br class="">my LCR in an automated fashion temporarily so I don't need to wake up<br class="">and<br class="">take care of my customers.<br class=""><br class="">Beckman<br class="">-----------------------------------------------------------------------<br class="">---<br class="">-<br class="">Peter Beckman Internet<br class="">Guy<br class=""><a href="mailto:beckman@angryox.com" class="">beckman@angryox.com</a><br class="">http://www.angryox.com/<br class="">-----------------------------------------------------------------------<br class="">---<br class="">-<br class=""></blockquote><br class=""><br class=""><br class=""><br class="">________________________________<br class=""><br class="">This e-mail and any attachments are confidential. If it is not intended<br class="">for you, please notify the sender, and please erase and ignore the<br class="">contents.<br class="">_______________________________________________<br class="">VoiceOps mailing list<br class=""><a href="mailto:VoiceOps@voiceops.org" class="">VoiceOps@voiceops.org</a><br class="">https://puck.nether.net/mailman/listinfo/voiceops<br class="">_______________________________________________<br class="">VoiceOps mailing list<br class="">VoiceOps@voiceops.org<br class="">https://puck.nether.net/mailman/listinfo/voiceops<br class="">_______________________________________________<br class="">VoiceOps mailing list<br class="">VoiceOps@voiceops.org<br class="">https://puck.nether.net/mailman/listinfo/voiceops<br class=""></blockquote><br class=""></div></div></div></div></body></html>