[VOIPSA Best Practices] DTMF and quality monitoring... RE: Best Practices document structure set - next question: are these the appropriate areas?

[Dustin D. Trammell]

On Fri, 2007-01-19 at 11:34 -0500, dan_york at Mitel.com wrote:
> 9b. I'm not sure on this personally.  It would seem that these apps
> are really using signaling connections and media connections, and so
> they would fall under those appropriate sections.  Which is to say
> that  the sections on "Securing Call Control" and "Securing Media"
> should probably take into account the use of those connections by
> applications. 

I would agree that applications making use of VoIP signaling and other
services should be considered in those individual sections when
authoring best practices.  I don't believe we need a separate section
for them.

> 11.  Interesting point.  Certainly "availability" is a security
> concern and *part* of that relates to quality assurance.  But I don't
> know how far we want to go down that road... we want to focus on
> helping people understand how to have a *secure* VoIP system, but not
> necessarily instructing them on how to have one with *excellent* audio
> quality.   
> 
> I don't know... what do others think?  How important should we stress
> quality assurance?

What I thought Greg was referring to was security for the systems doing
the QA, not necessarily the QoS itself.

However, we may need to define at what point degraded quality of service
becomes a /denial/ of service.  In VoIP, that line is quite blurred
because while you, listening to a conference call that receives some
jitter, may be able to still understand what was said, I may not.  In my
example, for you it's just crappy audio.  For me it's a denial of
service.  In my opinion, when degraded QoS becomes a denial of service,
that's when it enters the scope of security vs. an operational issue.

P.S. Sorry for the lag-time, I'm catching up (:

-- 
Dustin D. Trammell
VoIP Security Research
TippingPoint, a division of 3Com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <http://voipsa.org/pipermail/bestpractices_voipsa.org/attachments/20070129/499925ef/attachment.sig>