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