[VoiceOps] Easy ways to measure PDD
Mark R Lindsey
lindsey at e-c-group.com
Tue Apr 21 12:39:39 EDT 2015
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 "the time from output of the dialing signals...from the terminal of the calling subscriber until the ring-back tone is received." <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>
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.
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.
To answer the OP question, I have a lot of fun with tshark -Tfields. You'd have to correlate the call IDs...for example,
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
You might get output like this:
1429634006.467713000 5ca341afb6da7cd2
1429634006.512273000 5ca341afb6da7cd2 100
1429634006.554476000 5ca341afb6da7cd2 1752914037-1429634006342 401
1429634006.635424000 5ca341afb6da7cd2
1429634006.678992000 5ca341afb6da7cd2 100
1429634010.485804000 5ca341afb6da7cd2 1553636734-1429634010302 183
The fourth frame is the original INVITE; there's no Status-Code, but we have the call ID.
The final frame shows the establishment of the dialog. It took 3.85 seconds.
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.)
Because of the tshark/dumpcap interconnection using temporary files, tshark can't run forever.
--- mailto:mark at ecg.co
tel:+1-229-316-0013
http://ecg.co/lindsey
> On Apr 21, 2015, at 11:21 , Ivan Kovacevic <ivan.kovacevic at startelecom.ca> wrote:
>
> We have recently started measuring it (using FreeSwitch). It is the time
> from the initial INVITE to the first provisional response (e.g. 180/183).
>
> Best Regards,
>
> Ivan Kovacevic
> Vice President, Client Services
> Star Telecom | www.startelecom.ca | SIP Based Services for Contact Centers
>
>
> -----Original Message-----
> From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Eric
> Wieling
> Sent: Tuesday, April 21, 2015 11:15 AM
> To: Jesse Howard; Richard Jobson; Peter Beckman
> Cc: VoiceOps
> Subject: Re: [VoiceOps] Easy ways to measure PDD
>
> I thought PDD / Post Dial Delay was the time between the caller dialing
> and the caller hearing ringback. If that is correct you will *never* get
> PDD info out of Asterisk. Asterisk only tracks the time between dialing
> and answer.
>
>
> -----Original Message-----
> From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jesse
> Howard
> Sent: Tuesday, April 21, 2015 11:10 AM
> To: Richard Jobson; Peter Beckman
> Cc: VoiceOps
> Subject: Re: [VoiceOps] Easy ways to measure PDD
>
> Isn't this exactly what the timeout option in the dial command is for on
> Asterisk?
>
> You can both limit the maximum PDD and route advance/alert directly from
> your dialplan.
>
> To be honest, ASR and ACD have always been more telling from trending
> perspectives than PDD where I only care about PDD when it is overly long.
> What it was before the current delay is usually irrelevant for the most
> part especially since PDD tends to manifest for specific routes vs. the
> carrier in general.
>
> Jesse
> ________________________________________
> From: Richard Jobson [richard at teraquant.com]
> Sent: Monday, April 20, 2015 11:16 PM
> To: Peter Beckman
> Cc: Calvin E.; VoiceOps
> Subject: Re: [VoiceOps] Easy ways to measure PDD
>
> Well if it needs to be real-time, it is not really a CDR function.
> Oracles Palladion/COM can do it out of the box. But there again you need
> to install a box. You can install it on VME.
> It will send you an SNMP trap or email in real-time as soon as the minute
> average KPI (e.g. PDD) is exceeded per trunk. And Oracle has a reseller
> who can make Palladion sing for its supper :)
>
>
> On 4/20/15, 5:02 PM, "Peter Beckman" <beckman at angryox.com> wrote:
>
>> On Mon, 20 Apr 2015, Richard Jobson wrote:
>>
>>> Do you have an SBC or switch that already measures this and outputs
>>> it with the CDR?
>>
>> Nope.
>>
>>> Do you want to report on all PDD long-term? Or just one or two
>>> specific calls?
>>
>> Long term. A handful of Asterisk servers. Looking for what Calvin E.
>> suggested, except a tool that someone has already written. I can do
>> what Calvin suggests, but interpreted scripts are no match for C
>> compiled packet matching.
>>
>> What Calvin suggests is something that would work for a PCAP file
>> processed after the fact. I'm looking for something that would be
>> able to
>> catch the non-100 response for each INVITE and log it to a file or
>> send a
>> metric. Even if it has to wake up and parse a 80MB+ pcap file each
>> run to
>> find the PDD per Call-ID, then determine if that Call-ID has been
>> reported. Lots of caching of data... it can be done, but speed is
>> important and a scripting language is quick and dirty but unlikely to
>> be
>> fast and reliable.
>>
>> Does Asterisk support logging or emitting metrics like PDD?
>>
>> When a carrier jumps from <1 second Post Dial Delay to 20+ seconds
>> Post
>> Dial Delay I need (a) to know about it and (b) be able to demote them
>> in
>> my LCR in an automated fashion temporarily so I don't need to wake up
>> and
>> take care of my customers.
>>
>> Beckman
>> -----------------------------------------------------------------------
>> ---
>> -
>> Peter Beckman Internet
>> Guy
>> beckman at angryox.com
>> http://www.angryox.com/
>> -----------------------------------------------------------------------
>> ---
>> -
>
>
>
>
> ________________________________
>
> This e-mail and any attachments are confidential. If it is not intended
> for you, please notify the sender, and please erase and ignore the
> contents.
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20150421/d5a27e30/attachment.html>
More information about the VoiceOps
mailing list