On Feb 26, 2015, at 5:29 AM, Steven Ayre <steveayre@gmail.com> wrote:Two clarify this point... Most codecs are lossless, but don't necessarily throw the same information away so going through multiple codecs can throw out more information than using a single codec. Probably not an issue as long as the call isn't being transcoded *many* times. Also (software) transcoding uses more CPU and therefore it reduces the capacity of your server, which means you may get audio issues from an overloaded CPU at lower volumes.Most of the time audio issues will be network related - either jitter or packet loss. Wireshark will reveal those. There are also a number of rtp statistics in the XML CDR which includes information on RTP packet loss and jitter, and a computed quality score.On 25 February 2015 at 13:16, Luis Daniel Lucio Quiroz <luis.daniel.lucio@gmail.com> wrote:You shall try to void transcoding as much as possible
On Feb 25, 2015 2:54 AM, "Stanislav Sinyagin" <ssinyagin@gmail.com> wrote:by the way, here are freely available test speech samples:
http://www.voiptroubleshooter.com/open_speech/
http://www.pscr.gov/projects/audio_quality/mrt_library/mrt_library2.php
http://alt-usage-english.org/audio_archive.shtml
http://www.itu.int/net/itu-t/sigdb/menu.aspx
http://www.voxforge.org/On Wed, Feb 25, 2015 at 8:33 AM, Stanislav Sinyagin <ssinyagin@gmail.com> wrote:I hope this helps :)There is also a library for comparing WAV streams -- this would be the best for QoS measurements, and you would also be able to get the PSTN path into the test. But I didn't yet try it, as the customer was satisfied with RTP analysis:Here in scripts/ you can find a simple script that launches tshark and analyses the output:I'd say QoS drops even more abruptly if you hit the bandwidth or performance limits.tshark, a text terminal version of Wireshark, can analyze the quality of RTP streams and print a report that you can parse. Keep in mind that the analysis itself is quite CPU-intensive, so what I usually do is collect the RTP streams with tcpdump, and then run tshark in low-priority mode.
https://github.com/voxserv/voip_qos_probe
http://openpreservation.org/knowledge/blogs/2012/07/09/xcorrsound-waveform-compare-new-audio-quality-assurance-tool/
https://github.com/openpreserve/scape-xcorrsoundOn Wed, Feb 25, 2015 at 1:35 AM, Andrew V <avstarventures@gmail.com> wrote:How do you measure quality of service across all calls?What are ways to avoid bad quality of service?Say the call volume is in your control.Is it as easy as not letting the call volume get out of control?The attached is a hypothesis of the relationship between QOS and the number of concurrent calls. Does it work that way?What other factors need to be taken into account?<image.png>