So after a recent discussion about how to quickly diagnose SIP calls from packets (tcpdump + sngrep for the win!), I'm now wondering if there is a tool I don't know about that would be able to parse the same .pcap file that contains all of my port 5060 traffic and output the PDD time for each call found within. Bonus points if I can specify a time/date range. I don't want to manage yet another server or metrics repository in order to hold all of this call data, so some of the larger (and pricier) tools mentioned before are out for me. I've contacted the author of sngrep and though the packet capture code is already there, he reasonably doesn't want to turn sngrep into sipawk or sipsed. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
www.voipmonitor.org PDD charts and so, so much more. -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matthew at crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com
On Apr 20, 2015, at 5:11 PM, Peter Beckman <beckman at angryox.com> wrote:
So after a recent discussion about how to quickly diagnose SIP calls from packets (tcpdump + sngrep for the win!), I'm now wondering if there is a tool I don't know about that would be able to parse the same .pcap file that contains all of my port 5060 traffic and output the PDD time for each call found within. Bonus points if I can specify a time/date range.
I don't want to manage yet another server or metrics repository in order to hold all of this call data, so some of the larger (and pricier) tools mentioned before are out for me.
I've contacted the author of sngrep and though the packet capture code is already there, he reasonably doesn't want to turn sngrep into sipawk or sipsed.
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Yup Shripal
On Apr 20, 2015, at 5:23 PM, Matthew Crocker <matthew at corp.crocker.com> wrote:
www.voipmonitor.org
PDD charts and so, so much more.
-- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710
E: matthew at crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com
On Apr 20, 2015, at 5:11 PM, Peter Beckman <beckman at angryox.com> wrote:
So after a recent discussion about how to quickly diagnose SIP calls from packets (tcpdump + sngrep for the win!), I'm now wondering if there is a tool I don't know about that would be able to parse the same .pcap file that contains all of my port 5060 traffic and output the PDD time for each call found within. Bonus points if I can specify a time/date range.
I don't want to manage yet another server or metrics repository in order to hold all of this call data, so some of the larger (and pricier) tools mentioned before are out for me.
I've contacted the author of sngrep and though the packet capture code is already there, he reasonably doesn't want to turn sngrep into sipawk or sipsed.
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ 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
Thanks Matthew... but... "I don't want to manage yet another server or metrics repository in order to hold all of this call data..." This requires a whole pile of new software to be installed AND MySQL to be run somewhere. http://www.voipmonitor.org/doc/Architecture I have .pcap files from tcpdump with the call data. sngrep can parse it very fast and very well, but it is a curses-GUI and I need something I can automate. Dream workflow: sipgrep --packet-type-start INVITE --report pdd --direction outbound \ --input-packet-capture sip07.pcap \ | shell-script-mangle \ | xargs -n1 push-metrics This way I can have a graph of PDD per termination partner (the shell-script-mangle would translate IP addresses into service provider tags/names) and push the metrics to my existing metrics system (statsd + graphite + grafana) and alert when things pass a threshold. Beckman On Mon, 20 Apr 2015, Matthew Crocker wrote:
www.voipmonitor.org
PDD charts and so, so much more.
On Apr 20, 2015, at 5:11 PM, Peter Beckman <beckman at angryox.com> wrote:
So after a recent discussion about how to quickly diagnose SIP calls from packets (tcpdump + sngrep for the win!), I'm now wondering if there is a tool I don't know about that would be able to parse the same .pcap file that contains all of my port 5060 traffic and output the PDD time for each call found within. Bonus points if I can specify a time/date range.
I don't want to manage yet another server or metrics repository in order to hold all of this call data, so some of the larger (and pricier) tools mentioned before are out for me.
I've contacted the author of sngrep and though the packet capture code is already there, he reasonably doesn't want to turn sngrep into sipawk or sipsed.
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://urldefense.proofpoint.com/v1/url?u=https://puck.nether.net/mailman/l...
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
Since you can already parse the pcap, here's a napkin sketch assuming something like php, bash, tcsh, etc. Were you looking for something more specific? Find all INVITEs, store (as in-memory temp data) timestamps, Call-ID, and CSeq Find first matching non-100 response for each INVITE based on Call-ID and Cseq (in case there are later reinvites) Calculate difference in timestamp ... Profit! On Mon, Apr 20, 2015 at 11:35 AM, Peter Beckman <beckman at angryox.com> wrote:
Thanks Matthew... but...
"I don't want to manage yet another server or metrics repository in order to hold all of this call data..."
This requires a whole pile of new software to be installed AND MySQL to be run somewhere. http://www.voipmonitor.org/doc/Architecture
I have .pcap files from tcpdump with the call data. sngrep can parse it very fast and very well, but it is a curses-GUI and I need something I can automate.
Dream workflow:
sipgrep --packet-type-start INVITE --report pdd --direction outbound \ --input-packet-capture sip07.pcap \ | shell-script-mangle \ | xargs -n1 push-metrics
This way I can have a graph of PDD per termination partner (the shell-script-mangle would translate IP addresses into service provider tags/names) and push the metrics to my existing metrics system (statsd + graphite + grafana) and alert when things pass a threshold.
Beckman
On Mon, 20 Apr 2015, Matthew Crocker wrote:
www.voipmonitor.org
PDD charts and so, so much more.
On Apr 20, 2015, at 5:11 PM, Peter Beckman <beckman at angryox.com> wrote:
So after a recent discussion about how to quickly diagnose SIP calls from packets (tcpdump + sngrep for the win!), I'm now wondering if there is a tool I don't know about that would be able to parse the same .pcap file that contains all of my port 5060 traffic and output the PDD time for each call found within. Bonus points if I can specify a time/date range.
I don't want to manage yet another server or metrics repository in order to hold all of this call data, so some of the larger (and pricier) tools mentioned before are out for me.
I've contacted the author of sngrep and though the packet capture code is already there, he reasonably doesn't want to turn sngrep into sipawk or sipsed.
Beckman
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/
--------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org
https://urldefense.proofpoint.com/v1/url?u=https://puck.nether.net/mailman/l...
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Do you have an SBC or switch that already measures this and outputs it with the CDR? Do you want to report on all PDD long-term? Or just one or two specific calls? Regards, Richard From: "Calvin E." <calvine at gmail.com> Date: Monday, April 20, 2015 at 4:07 PM To: VoiceOps <voiceops at voiceops.org>, <beckman at angryox.com> Subject: Re: [VoiceOps] Easy ways to measure PDD
Since you can already parse the pcap, here's a napkin sketch assuming something like php, bash, tcsh, etc. Were you looking for something more specific?
Find all INVITEs, store (as in-memory temp data) timestamps, Call-ID, and CSeq Find first matching non-100 response for each INVITE based on Call-ID and Cseq (in case there are later reinvites) Calculate difference in timestamp ... Profit!
On Mon, Apr 20, 2015 at 11:35 AM, Peter Beckman <beckman at angryox.com> wrote:
Thanks Matthew... but...
"I don't want to manage yet another server or metrics repository in order to hold all of this call data..."
This requires a whole pile of new software to be installed AND MySQL to be run somewhere. http://www.voipmonitor.org/doc/Architecture
I have .pcap files from tcpdump with the call data. sngrep can parse it very fast and very well, but it is a curses-GUI and I need something I can automate.
Dream workflow:
sipgrep --packet-type-start INVITE --report pdd --direction outbound \ --input-packet-capture sip07.pcap \ | shell-script-mangle \ | xargs -n1 push-metrics
This way I can have a graph of PDD per termination partner (the shell-script-mangle would translate IP addresses into service provider tags/names) and push the metrics to my existing metrics system (statsd + graphite + grafana) and alert when things pass a threshold.
Beckman
On Mon, 20 Apr 2015, Matthew Crocker wrote:
www.voipmonitor.org <http://www.voipmonitor.org>
PDD charts and so, so much more.
On Apr 20, 2015, at 5:11 PM, Peter Beckman <beckman at angryox.com> wrote:
So after a recent discussion about how to quickly diagnose SIP calls from packets (tcpdump + sngrep for the win!), I'm now wondering if there is a tool I don't know about that would be able to parse the same .pcap file that contains all of my port 5060 traffic and output the PDD time for each call found within. Bonus points if I can specify a time/date range.
I don't want to manage yet another server or metrics repository in order to hold all of this call data, so some of the larger (and pricier) tools mentioned before are out for me.
I've contacted the author of sngrep and though the packet capture code is already there, he reasonably doesn't want to turn sngrep into sipawk or sipsed.
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://urldefense.proofpoint.com/v1/url?u=https://puck.nether.net/mailman/ listinfo/voiceops&k=eghE%2F1871Dg5AgRfLcYONw%3D%3D%0A&r=6u4D%2FXrxCS2CFGDR% 2F10ITB7whz3CLQp1FhOexohJiTo%3D%0A&m=f3JKNUc1MsE7jFK9faN7F%2Fy8KIJ4OtgCKrTc lex%2BqhM%3D%0A&s=7df9cc8d4717ef69b1427ff171b83de29281fb43ab72ffc000daf9311 a4c8f73
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ 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
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/ ---------------------------------------------------------------------------
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://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification Watch for lines with "disposition" = "ANSWERED" and calculate the difference of "start" and "answer". 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. 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. This problem might already be solved by the asterisk community. Have you checked those forums/mailing lists? 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. https://wiki.asterisk.org/wiki/display/AST/RADIUS+CDR+Backend On Mon, Apr 20, 2015 at 1: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/ ---------------------------------------------------------------------------
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/ ---------------------------------------------------------------------------
On 21/04/15 06:18, Peter Beckman wrote:
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).
If I would have to code it and do it in C (for performance reasons), perhaps I would go for patching sngrep (already mentioned here) or sipgrep. sngrep already has options to display duration of singaling and duration of connecting, so could be easy to track the places in the exiting code. On the other hand, I am not sure if it would be easy to just write reports to files instead of displaying with ncurses on the terminal. Main reason for replying here is to point to wireshark/tshark, which has embedded Lua support. That could be handy for non-C programers and the performances are still high. Searching on google for wireshark+sip+lua will reveal several examples that can be used as a starting point. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com
On 4/20/15 5:43 PM, 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://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification
Watch for lines with "disposition" = "ANSWERED" and calculate the difference of "start" and "answer".
PDD isn't the time difference between start and answer. It's the time difference between invite and ringing. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
You're absolutely right, I had a brainfart while looking at the Asterisk CDR details. You won't get PDD from this. Regarding the other discussion of what PDD is in SIP signalling versus real human experience, it all depends what you're looking for and how you're willing to find it. Detecting non-silence in the 18x pre-session or post 200 OK session media is probably the best way of gauging the subjective human experience, but requires considerably more effort than checking the SIP signalling. Also, RTP analysis is not an option if you do not anchor media between your customers and carriers (passing SDP connection address/port from end to end). "UAS (downstream carriers) can start sending a 183 in place of 100" If your provider is doing this then you should probably consider changing service. Defaulting to 18x can break route advancement if UAS does not ultimately 200 OK the call. In my environment a 503, 404, 603 etc. after 18x is assumed to be a voice reject and ends the call, whereas a rejection without 18x would advance to the next carrier. On Tue, Apr 21, 2015 at 9:08 AM, Jay Hennigan <jay at west.net> wrote:
On 4/20/15 5:43 PM, 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://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification
Watch for lines with "disposition" = "ANSWERED" and calculate the difference of "start" and "answer".
PDD isn't the time difference between start and answer. It's the time difference between invite and ringing.
-- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Our practice suggests that it's perfectly safe to measure time difference between processing of initial INVITE and either (a) non-100 1xx response (either 183+SDP or 180) or (b) final affirmative answer (2xx). -- Alex On 04/21/2015 03:45 PM, Calvin E. wrote:
Regarding the other discussion of what PDD is in SIP signalling versus real human experience, it all depends what you're looking for and how you're willing to find it.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Alex, That's exactly what we do. And the only other twist, since we work with a lot of dialer traffic, is that the originator may hang up before 180/183/200 come through. So the whole 20-30 second non-connected call may be PDD. To operationalize the data and make it actionable, we measure prevalence of 8+second PDD (arbitrary) calls by provider. If it exceeds 20% (also arbitrary) in any 15 minute interval we flag it, run some examples and send to the NOC team to investigate/escalate with the provider. We have just started doing this, and have gone from being driven by client-reported issues to proactively chasing after providers to fix it? and we are definitely starting to see some improvements, as well as patterns. The hope is we can further tighten the parameters to keep the offending calls to sub 10%. 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 Alex Balashov Sent: Tuesday, April 21, 2015 3:51 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Easy ways to measure PDD Our practice suggests that it's perfectly safe to measure time difference between processing of initial INVITE and either (a) non-100 1xx response (either 183+SDP or 180) or (b) final affirmative answer (2xx). -- Alex On 04/21/2015 03:45 PM, Calvin E. wrote:
Regarding the other discussion of what PDD is in SIP signalling versus
real human experience, it all depends what you're looking for and how
you're willing to find it.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
This goes back to my earlier question on a different thread To what extent is the industry using Successful Session Setup (SRD) & Failed Session Setup SRD as specified in IETF RFC 6076 , as a precisely defined SIP equivalent of PDD? Are there any deficiencies in SRD that make it not suitable? If the industry could standardize on these KPI?s, then the vendors (Asterisk etc ) could build to them and we?d all have something to do apples v apples comparison between carriers. Thanks Richard www.teraquant.com From: Ivan Kovacevic <ivan.kovacevic at startelecom.ca> Date: Tuesday, April 21, 2015 at 2:02 PM To: Alex Balashov <abalashov at evaristesys.com>, <voiceops at voiceops.org> Subject: Re: [VoiceOps] Easy ways to measure PDD
Alex,
That's exactly what we do. And the only other twist, since we work with a lot of dialer traffic, is that the originator may hang up before 180/183/200 come through. So the whole 20-30 second non-connected call may be PDD.
To operationalize the data and make it actionable, we measure prevalence of 8+second PDD (arbitrary) calls by provider. If it exceeds 20% (also arbitrary) in any 15 minute interval we flag it, run some examples and send to the NOC team to investigate/escalate with the provider.
We have just started doing this, and have gone from being driven by client-reported issues to proactively chasing after providers to fix it? and we are definitely starting to see some improvements, as well as patterns.
The hope is we can further tighten the parameters to keep the offending calls to sub 10%.
Best Regards,
Ivan Kovacevic Vice President, Client Services Star Telecom | www.startelecom.ca <http://www.startelecom.ca> | SIP Based Services for Contact Centers
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Alex Balashov Sent: Tuesday, April 21, 2015 3:51 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Easy ways to measure PDD
Our practice suggests that it's perfectly safe to measure time difference between processing of initial INVITE and either (a) non-100 1xx response (either 183+SDP or 180) or (b) final affirmative answer (2xx).
-- Alex
On 04/21/2015 03:45 PM, Calvin E. wrote:
Regarding the other discussion of what PDD is in SIP signalling versus real human experience, it all depends what you're looking for and how you're willing to find it.
-- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/ <http://www.evaristesys.com/> , http://www.csrpswitch.com/ <http://www.csrpswitch.com/> _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://puck.nether.net/mailman/listinfo/voiceops> _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On Tue, 21 Apr 2015, Alex Balashov wrote:
Our practice suggests that it's perfectly safe to measure time difference between processing of initial INVITE and either (a) non-100 1xx response (either 183+SDP or 180) or (b) final affirmative answer (2xx).
Safe to measure? Does that mean it is harmful to measure other things? I think it is important to understand the difference between the two measurements you mention. INVITE to non-100 response: Post Dial Delay INVITE to 2xx answer: Ring Time Post Dial Delay is something your carrier controls. Ring Time is something the called party controls. Your carrier should be very consistent in their PDD. The called party is often a human which scientific trials have proven are random and inconsistent and cannot be relied upon. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
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/ -------------------------------------------------------------------------- -
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.
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
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
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...> 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
My point wasn't trying to extract the PDD out of Asterisk but to act on it accordingly which is exactly why the timeout option exists. If a call is taking "too long" to connect, timeout and perform another action. If you want to track how many times this happens for a route or carrier so be it - that is easily attainable at the dialplan level - export it to a log or push to fastagi to trend/handle somewhere else. As the OP mentioned they do not want another box and this is built into the existing solution to both recognize the situation and handle it. I understand the overwhelming need we all feel to trend things and you can never have too much data however sometimes the solution is already there begging us to use it if only we stop looking at what we think we want and listen to what we need. ________________________________________ From: Eric Wieling [EWieling at nyigc.com] Sent: Tuesday, April 21, 2015 10: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 ________________________________ 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.
You are referring to the various SIP timer options in Asterisk? -----Original Message----- From: Jesse Howard [mailto:jhoward at ShoreTel.com] Sent: Tuesday, April 21, 2015 11:38 AM To: Eric Wieling; Richard Jobson; Peter Beckman Cc: VoiceOps Subject: RE: [VoiceOps] Easy ways to measure PDD My point wasn't trying to extract the PDD out of Asterisk but to act on it accordingly which is exactly why the timeout option exists. If a call is taking "too long" to connect, timeout and perform another action. If you want to track how many times this happens for a route or carrier so be it - that is easily attainable at the dialplan level - export it to a log or push to fastagi to trend/handle somewhere else. As the OP mentioned they do not want another box and this is built into the existing solution to both recognize the situation and handle it. I understand the overwhelming need we all feel to trend things and you can never have too much data however sometimes the solution is already there begging us to use it if only we stop looking at what we think we want and listen to what we need. ________________________________________ From: Eric Wieling [EWieling at nyigc.com] Sent: Tuesday, April 21, 2015 10: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 ________________________________ 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.
Wow - thanks for mentioning sngrep - looks like a great tool! --- Christopher Aloi Sent from my iPhone
On Apr 20, 2015, at 5:11 PM, Peter Beckman <beckman at angryox.com> wrote:
So after a recent discussion about how to quickly diagnose SIP calls from packets (tcpdump + sngrep for the win!), I'm now wondering if there is a tool I don't know about that would be able to parse the same .pcap file that contains all of my port 5060 traffic and output the PDD time for each call found within. Bonus points if I can specify a time/date range.
I don't want to manage yet another server or metrics repository in order to hold all of this call data, so some of the larger (and pricier) tools mentioned before are out for me.
I've contacted the author of sngrep and though the packet capture code is already there, he reasonably doesn't want to turn sngrep into sipawk or sipsed.
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (13)
-
abalashov＠evaristesys.com -
beckman＠angryox.com -
calvine＠gmail.com -
ctaloi＠gmail.com -
EWieling＠nyigc.com -
ivan.kovacevic＠startelecom.ca -
jay＠west.net -
jhoward＠ShoreTel.com -
lindsey＠e-c-group.com -
matthew＠corp.crocker.com -
miconda＠gmail.com -
richard＠teraquant.com -
shripald＠gmail.com