[VOIPSEC] the quality of voip vs. the worthless completely broken mess

Albert caruabertu at gmail.com
Mon Dec 11 14:12:04 GMT 2006


I would be happy if all my voip calls were as good in quality as the
messages sent through the "worthless completely broken mess which is email"

The reality is that most times, echo, loss of spectrum, wow and flutter and
plain background NOISE, not to mention occasional fragments of someone
else's conversation, almost all the time, make most voip communications
(here) worse than leaky-cable hand-mediated trunk calls of old.

By the way, noisy pstn local calls, interception of conversation held over
"portables" etc... were not at all unusual, in my experience not even very
long ago. Not long ago, an important resource for a personal assistant, then
called secretary or phone operator, was a small collection of spelling
alphabets e.g. alpha, bravo, charlie, delta, echo, foxtrot etc...  so as to
be able to spell things out properly over the flaky lines.

Was this a worthless completely broken mess too?

With microwave and satellite repeaters, huge bandwidth and electronic
switching, new norms were possible and those days are now over for pstn.

The most interesting comment in this context was made by  Geoff Devine of
Cedarpoint and repeated by "Vijay K. Gurbani" of Alcatel-Lucent - that the
current PSTN quality, security and reliability was developed with taxpayer
money and near-infinite budgets.

Could the aim of this group thus be to devise ways to get serious budgets
for secure VOIP too - ITU/IETF and security teams around the telephone and
internet networks! ??

What do the readers receiving the output of a completely worthless broken
mess think?


2006/12/11, voipsec-request at voipsa.org < voipsec-request at voipsa.org>:
> Send Voipsec mailing list submissions to
>        voipsec at voipsa.org
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> or, via email, send a message with subject or body 'help' to
>        voipsec-request at voipsa.org
> You can reach the person managing the list at
>        voipsec-owner at voipsa.org
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Voipsec digest..."
> Today's Topics:
>   1. Re: [SearchSecurity.com] Better VoIP training   needed, SANS
>      director says (Simon Horne)
> ----------------------------------------------------------------------
> Message: 1
> Date: Mon, 11 Dec 2006 03:34:08 +0800
> From: Simon Horne < s.horne at packetizer.com>
> Subject: Re: [VOIPSEC] [SearchSecurity.com] Better VoIP training
>        needed, SANS director says
> To: Diana Cionoiu < diana at voip.null.ro>,Simon Horne
>        <s.horne at packetizer.com>
> Cc: Voipsec < Voipsec at voipsa.org>
> Message-ID: < at mail.isvo.net >
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> Diana
> I totally agree, security is not a mainstream issue until it starts to
> become an issue, then of course it's all too late.
> On the topic of IM have you had a chance to read my proposal and working
> document H.460.tm <http://h.460.tm/> (Text Messaging)
> http://www.packetizer.com/voip/h323/doc_status.html
> It is completely backwards interoperable. You can have two softphone
> connected to an old cisco network and be able to exchange text messages
> between eachother.  Gives you something to think about :-)
> >P.S. In H.323 haft of the bugs have been in ASN.1 parser, because that
> >protocol is too difficult to implement.
> This is a kinda funny statement to make given you previous post on the
> topic..:-)  There are quite a few (as you know) very good ASN.1 parsers
> available in both open source and can be purchased. For instance it took
> me
> no more than about 5 minutes (serious) to upgrade my code from H.323v5 to
> H.323v6 using an open source ASN.1 C++ parser and ASN.1 definitions
> straight out of the standards documents. Once you have a decent parser
> then
> building is just a snap. Understanding how it all works is a different
> story. The protocol is extremely complicated (in some areas overly
> complicated) but it was designed to accommodate most requirements of a
> VoIP
> system including PSTN interoperability and security framework from the
> very
> beginning. Trying to add these features later on can be just as difficult
> or more difficult to implement.
> I personally have used the existing security framework of H.323 to
> embedding digital certificates for authentication, diffie-hellmen keys for
> media encryption, caller credentials (username/password) for border call
> admission etc into pre-existing standard signalling messages and
> successfully deployed these devices interoperablity in pre-existing H.323
> networks. This isn't rocket science, if a flexible security framework
> exists than with a bit of effort it is possible, if it does not then
> securing that VoIP network, at best is difficult and potentially costly
> wholesale upgrading endeavor or at worst a worthless completely broken
> mess
> like email.
> Simon
> At 12:51 AM 11/12/2006, Diana Cionoiu wrote:
> >Hello Simon,
> >
> >This is why we decided to support Jingle in Yate. Jingle has the
> advantage
> >that it has a mechanism that works against spam (the dialback system
> >existing in Jabber), better than any other VoIP protocol that i know, and
> >it also has support for IM, and gateways to the main existing networks,
> >and probably in the future we will be able to build gateways for audio.
> >In the end i can say that i do hope for better networks, but security has
> >never been a mainstream issue, and i doubt it will become very soon. So
> >any protocol that wants to have a chance this days has to provide more
> >than security.
> >
> >Diana Cionoiu
> >
> >P.S. In H.323 haft of the bugs have been in ASN.1 parser, because that
> >protocol is too difficult to implement.
> >
> >Simon Horne wrote:
> >
> >>I have to agree with Richard, those on this list know there are
> currently
> >>functioning, workable VoIP solutions (and have been for many years)
> which
> >>have security built in from the get-go including SMA and H.323. You
> can't
> >>blame the programmer if the protocol he/she has to work with does not
> >>have the native capacity to support the required security the programmer
> >>is trying to program.  Its not the programmers fault.
> >>
> >>Lets be honest. The market has chosen to adopt a protocol which is very
> >>difficult to secure (as it has no native security support itself). That
> >>choice may come back to haunt the entire industry.
> >>
> >>Simon
> ------------------------------
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> End of Voipsec Digest, Vol 24, Issue 7
> **************************************

More information about the Voipsec mailing list