asterisk users - Dec 2008 - Friday VUC 12 Noon ET with Kristian Kielhofner: Identifying Asterisk Quality Issues

Happy New Year in advance by a few ticks for the northern hemisphere.

Here's the first topic and guest for 2009:

In any voice path there are several potential sources of quality
problems, ranging from
echo to voice dropouts and everything in between.  With VoIP systems
the potential for
quality problems increases dramatically, often times making it very difficult to
identify the source of the problem.  Recqual is a utility that uses Asterisk and
Ecasound to make comparisons of complete audio paths - whether they be
IP, TDM, or any
combination.  In this Friday's VoIP User's Conference, Kristian
Kielhofner will give an
introduction to Recqual and provide several examples of its usage in real world
contexts.

More on Recqual here on Kristian's blog : http://tr.im/recqual2 or on
Voip-Info: http://tr.im/recqual

Join us if your head isn't still throbbing.

Best to all of you out there,

/r

On 12/31/08, randulo <spamsucks2005 at gmail.com>
wrote:
> Happy New Year in advance by a few ticks for the northern hemisphere.
>
>  Here's the first topic and guest for 2009:
>
>  In any voice path there are several potential sources of quality
>  problems, ranging from
>  echo to voice dropouts and everything in between.  With VoIP systems
>  the potential for
>  quality problems increases dramatically, often times making it very
difficult to
>  identify the source of the problem.  Recqual is a utility that uses
Asterisk and
>  Ecasound to make comparisons of complete audio paths - whether they be
>  IP, TDM, or any
>  combination.  In this Friday's VoIP User's Conference, Kristian
>  Kielhofner will give an
>  introduction to Recqual and provide several examples of its usage in real
world
>  contexts.
>
>  More on Recqual here on Kristian's blog : http://tr.im/recqual2 or on
>  Voip-Info: http://tr.im/recqual
>
>  Join us if your head isn't still throbbing.
>
>  Best to all of you out there,
>
>  /r
>
  I'd like to add that I am recruiting devs and other experts to
participate in this call.  John Todd will be joining me along with
several others (hopefully) to provide real world input on overall call
quality topics, such as:

- RTCP/RTCP XR
- QoS
- Etc, etc

  It's shaping up (no pun intended) to be a very interesting call!

-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com

On 12/31/08, Trixter aka Bret McDanel <trixter at 0xdecafbad.com>
wrote:
> On Wed, 2008-12-31 at 18:39 -0500, C. Savinovich wrote:
>  > Hello Kris, what's up?
>  >
>  >   I was reading your description for Recqual, and there is one thing
I don't
>  > get:
>  >
>  >     - We perform the test, which consists in playing a sound file
over the
>  > network via asterisk, and then comparing the difference in quality.
>  >     - How is it going to tell me what in my network is causing the
loss of
>  > quality?
>
>
>
> indeed, you would want to differentiate between jitter and loss, as well
>  as transcoding issues that may be present.  Even that wont really tell
>  you what part of the network, but it can tell you what to look for to
>  try to figure it out.
>
> --
>  Trixter http://www.0xdecafbad.com     Bret McDanel
>  pgp key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8AE5C721
>
(moved to Asterisk-Users)

  We spent quite a bit of time discussing recqual earlier today on The
VoIP User's Conference.  Thanks again Randy for organizing such a
lively discussion every week!

  I had quite a bit of time to explain recqual, the environment it
came out of, and where it could use some improvement.  If you have the
time I highly recommend at least /skimming/ the recording of the call.
 It will most likely answer any of your questions.

  To answer your specific questions:

  Recqual cannot possibly determine specific points of audio
degradation in a complete audio path. It can only test one variable
(basically).  It is important that you use other, existing tools to
try to eliminate all other potential sources of audio degradation.
Eliminate your machine, local LAN, and other factors as much as
possible.  You will need to have at least two separate paths to the
network you are testing (usually the PSTN), one of which is of known
quality.  Once all of these things are established, you can use
recqual to test the quality of various other audio paths, regardless
of technology (thanks to Asterisk).  SIP providers, POTS lines, B
channels on a PRI, etc can all be compared against your reference,
whatever that might be.

  Recqual, up to this point, has only been used by the author within
SIP networks.  However, as I pointed out in the README, VUC, and
earlier in this message, thanks to the protocol independent nature of
Asterisk, virtually any technology can be tested with only a few
modifications to your (possibly existing) Asterisk configuration.

  Also - recqual does not use sound files, as least not yet.  That
would be interesting although I don't know how it could work.  As of
now recqual simply generates continuous tones and does some
comparisons on them after they have gone through the network being
tested (again, usually the PSTN).

  I'm glad we have tools like Asterisk and ecasound that are simple
enough for someone like me to slap a shell script on top of to do some
pretty cool stuff!

-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com