[VOIPSEC] VoIP researches

Tue Dec 20 11:13:50 CST 2005

hey everybody
i'm new here
i'm working on VoIP securty paper for my PhD. thesis and i'm looking for new 
ideas
i'll be greatfull for any idea
thanks
aymen

>From: Voipsec-request at voipsa.org
>Reply-To: Voipsec at voipsa.org
>To: Voipsec at voipsa.org
>Subject: Voipsec Digest, Vol 12, Issue 20
>Date: Tue, 20 Dec 2005 09:35:12 +0000
>
>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: [CAnet - news] Assessing Skype's network impact
>       (Christopher A. Martin)
>    2. Re: Assessing Skype's network impact (Geoff Devine)
>    3. Re: [CAnet - news] Assessing Skype's network impact
>       (Gustavo Daniel Villarreal)
>    4. Re: [CAnet - news] Assessing Skype's network impact (Thomas Skora)
>    5. Re: [CAnet - news] Assessing Skype's network impact (AVM)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Mon, 19 Dec 2005 07:16:34 -0600
>From: "Christopher A. Martin" <chris at InfraVAST.com>
>Subject: Re: [VOIPSEC] [CAnet - news] Assessing Skype's network impact
>To: Chris Sutton <chris at c4l.co.uk>
>Cc: Voipsec at voipsa.org
>Message-ID: <43A6B2B2.70904 at InfraVAST.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Chris Sutton wrote:
>
> >Hi Robert,
> >
> >Thanks for the informative article. I'm always interested to read about
> >companies testing Skype.
> >
> >I wasn't aware that Skype used so much bandwidth! "33K to 46Kbps" IS a
> >lot for a voice call, and as you say, this would eat up bandwidth. Of
> >course this is only a problem due to the limited upload stream on your
> >office ADSL line. Nevertheless, such a high bitrate would still cause
> >problems.
> >
> >The G.729 codec in fact uses only 6.4 - 11.8kbps bandwidth per call, and
> >is a much better demonstration to customers of VoIP potential (there's
> >nothing like a dropped call/low audio quality to send a customer
> >running, screaming out the door!) I have found that codecs like G.711
> >(which is 64kbps) can only manage about 2 concurrent calls before audio
> >quality takes a severe nose dive.
> >
> >
> >
>One other point to note is that the overhead includes encryption with
>skype, as well as firewall traversal.
>
> >In my opinion it is this kind of limitation - like having a lack of PBX
> >redundancy - that will make VoIP unmarketable as a business solution let
> >alone as a replacement to POTS. I would even go as far as say that this
> >will be more important than security to most companies (at least until
> >VoIP becomes more widespread anyway)
> >
> >Sorry, just had to get that off my chest!!
> >
> >Regards,
> >
> >Chris
> >
> >-----Original Message-----
> >From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> >Behalf Of Voipsec-request at voipsa.org
> >Sent: 17 December 2005 12:00
> >To: Voipsec at voipsa.org
> >Subject: Voipsec Digest, Vol 12, Issue 17
> >
> >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. Fwd: [CAnet - news] Assessing Skype's network impact
> >      (Robert Moskowitz)
> >
> >
> >----------------------------------------------------------------------
> >
> >Message: 1
> >Date: Fri, 16 Dec 2005 10:29:38 -0500
> >From: Robert Moskowitz <rgm at icsalabs.com>
> >Subject: [VOIPSEC] Fwd: [CAnet - news] Assessing Skype's network
> >	impact
> >To: voipsec at voipsa.org
> >Message-ID: <7.0.0.16.2.20051216102846.03c14af8 at icsalabs.com>
> >Content-Type: text/plain; charset="us-ascii"; format=flowed
> >
> >Just another data point or two.
> >
> >
> >
> >>From: "Bill St.Arnaud" <bill.st.arnaud at canarie.ca>
> >>To: <news at canarie.ca>
> >>Date: Fri, 16 Dec 2005 10:14:27 -0500
> >>Subject: [CAnet - news] Assessing Skype's network impact
> >>Reply-To: bill.st.arnaud at canarie.ca
> >>List-Id: CA*net News mailing list <news.canarie.ca>
> >>
> >>Assessing Skype's network impact
> >>
> >>For more information on this item please visit the CANARIE CA*net 4
> >>
> >>
> >Optical
> >
> >
> >>Internet program web site at
> >>
> >>
> >http://www.canarie.ca/canet4/library/list.html
> >
> >
> >>-------------------------------------------
> >>
> >>[Thanks to Harvey Newman for this pointer. Some excerpts from Network
> >>
> >>
> >World
> >
> >
> >>article-- BSA]
> >>
> >><http://nwwsubscribe.com/highlights/facepage.asp?k=FOCHIPR&U=http://www
> >>
> >>
> >.nwfu
> >
> >
> >>sion.com&n=15>
> >>
> >>
> >>If you're worried about Skype creating a security problem for your
> >>network, don't, because the free VoIP service poses little danger to an
> >>enterprise network. That's a good thing, because it's just about
> >>impossible to keep Skype out of your network if end users are
> >>
> >>
> >determined
> >
> >
> >>to run it.
> >>
> >>That's the conclusion we reached after testing multiple versions of
> >>Skype for several weeks in our independent test lab.
> >>
> >>Skype is inscrutable and mysterious. It uses indecipherable encryption.
> >>It dynamically morphs traffic characteristics. It can work through
> >>virtually any network address translation (NAT)-based firewall.
> >>
> >>And with more than 4 million online users at any given time, one can
> >>assume that Skype has permeated many enterprise networks.
> >>
> >>We assessed the state of the encryption and security of the Skype
> >>messages and streams, looking for exposed information that could be
> >>useful to hackers and susceptible to man-in-the-middle interception and
> >>diversion tactics. We evaluated the security of Skype Instant Messaging
> >>and file transfer, along with the internetworking of Skype 1.4 and 2.0
> >>beta. We also tracked the effect of Skype operations, in terms of CPU
> >>and memory use, on laptops.
> >>
> >>Our testing shows that neither Skype VoIP nor Skype Instant Messaging
> >>poses any readily exploitable security threat. We also conducted a
> >>
> >>
> >dozen
> >
> >
> >>private interviews with hackers, enterprise network managers and
> >>
> >>
> >leading
> >
> >
> >>network-security-equipment suppliers, none of which could cite one case
> >>of Skype being exploited for insidious security assaults.
> >>
> >>Bandwidth is not a big concern either. A Skype voice call uses 33K to
> >>46Kbps of bandwidth in each direction. This is not a lot, and is
> >>
> >>
> >typical
> >
> >
> >>of an efficient WAN-oriented VoIP vocoding, such as G.729. Of course,
> >>
> >>
> >if
> >
> >
> >>a few dozen internal users are concurrently running Skype calls, this
> >>could eat up a T-1's worth of bandwidth.
> >>
> >>What should concern IT departments about Skype is not so much the
> >>
> >>
> >danger
> >
> >
> >>to security but the fact that it can't be controlled. Our testing shows
> >>that:
> >>
> >>*
> >>Skype works through firewalls and symmetric NATs (where a unique
> >>external IP address is associated with each internal user). We tried a
> >>number of commercial firewalls, configurations and even IPSs, which
> >>
> >>
> >work
> >
> >
> >>based on many higher-level traffic-analysis techniques, and we could
> >>
> >>
> >not
> >
> >
> >>prevent Skype from successfully establishing quality VoIP phone calls.
> >>*
> >>When Skype users download the software, they must consent to the usage
> >>agreement that includes a provision allowing Skype to commandeer their
> >>PC and its resources. The big fear is that the PC - ostensibly an
> >>enterprise node with private company files and communications stored on
> >>it - could become a Skype SuperNode. A Skype SuperNode is a
> >>
> >>
> >commandeered
> >
> >
> >>PC that plays a kind of proxy role in Skype call setup. We saw no
> >>evidence of any attempted takeover or use of any of the Skype-loaded
> >>
> >>
> >PCs
> >
> >
> >>or laptops we tested. Conventional wisdom is that a SuperNode takeover
> >>occurs only on nodes that maintain a long-term presence with the same
> >>public IP address.
> >>*
> >>
> >>Should Skype be stopped?
> >>
> >>We have not found or even heard of any plausible claims of inherent
> >>security threats or vulnerabilities associated with Skype at this time.
> >>
> >>In our research, we found one major U.S.-based global manufacturer that
> >>has decided to try to exclude Skype from its network. Technically, the
> >>company could not do so (see the story "Spotting and stopping Skype:
> >>good luck"), short of subjecting all its users' PCs to periodic scans
> >>
> >>
> >to
> >
> >
> >>detect Skype software. Even then, it would be possible for a user to go
> >>to work, download Skype, make calls and then uninstall Skype from
> >>
> >>
> >inside
> >
> >
> >>the enterprise network, all in an afternoon. The company has decided to
> >>arrange for users to make free, Internet-based calls via corporate
> >>network resources as an alternative to Skype.
> >>
> >>How do you identify and stop Skype? There will soon be IPS vendors that
> >>will work out a way to reliably spot and stop Skype calls in the short
> >>term. However, as of this writing, there is no vendor we could find
> >>
> >>
> >that
> >
> >
> >>offered a commercial solution that stops Skype calls permanently.
> >>
> >>Skype is inscrutable: Skype traffic is encrypted, the User Datagram
> >>Protocol and TCP ports it uses vary randomly; even the packet lengths
> >>and VoIP voice sample sizes vary.
> >>
> >>
> >>
> >>
> >>
> >>-------------------------------------
> >>To SUBSCRIBE:
> >>send a blank e-mail message to
> >>news-join at canarie.ca
> >>
> >>To UNSUBSCRIBE:
> >>send a blank email message to
> >>news-leave at canarie.ca
> >>-------------------------------------
> >>
> >>These news items and comments are mine alone and do not necessarily
> >>
> >>
> >reflect
> >
> >
> >>those  of the CANARIE board or management.
> >>-----------
> >>Bill.St.Arnaud at canarie.ca
> >>www.canarie.ca/~bstarn
> >>skype: pocketpro
> >>SkypeIn: +1 614 441-9603
> >>
> >>
> >>_______________________________________________
> >>news mailing list
> >>news at canarie.ca
> >>http://lists.canarie.ca/mailman/listinfo/news
> >>
> >>
> >
> >
> >Robert Moskowitz
> >Senior Technical Director
> >ICSA Labs, a division of Cybertrust, Inc.
> >W:      248-968-9809
> >F:      248-968-2824
> >VoIP:   248-291-0713
> >E:      rgm at icsalabs.com
> >
> >There's no limit to what can be accomplished if it doesn't matter who
> >gets the credit
> >
> >
> >
> >
> >
> >------------------------------
> >
> >_______________________________________________
> >Voipsec mailing list
> >Voipsec at voipsa.org
> >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> >
> >End of Voipsec Digest, Vol 12, Issue 17
> >***************************************
> >
> >
> >_______________________________________________
> >Voipsec mailing list
> >Voipsec at voipsa.org
> >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> >
> >
> >
>
>
>------------------------------
>
>Message: 2
>Date: Mon, 19 Dec 2005 08:44:32 -0500
>From: "Geoff Devine" <gdevine at cedarpointcom.com>
>Subject: Re: [VOIPSEC] Assessing Skype's network impact
>To: <Voipsec at voipsa.org>
>Message-ID:
>	<4EA2B4B3C5366B40BAFF28C60B2E353D38BF88 at exchange.cedarpointcom.com>
>Content-Type: text/plain;	charset="us-ascii"
>
> > I wasn't aware that Skype used so much bandwidth! "33K to 46Kbps" IS
> > a lot for a voice call, and as you say, this would eat up bandwidth.
>
>At 33 Kbps, you'll find that more than half of that is header overhead.
>33 Kbps is the typical results you expect to see from a compression
>codec.  MAC, IP, UDP, and RTP headers are fairly bloated when used to
>push compressed voice around the network.
>
> > I have found that codecs like G.711 (which is 64kbps) can only manage
> > about 2 concurrent calls before audio quality takes a severe nose
>dive.
>
>Since G.711 is the least complex codec, it's not the codec, it's the
>size of the internet pipe that needs to be considered.  The rule of
>thumb I always use is 4000 simultaneous G.711 calls on a Gig-E
>connection (keeping it under 50% utilization).  For residential
>broadband, it's more about when rate limiting kicks in.  In a cable
>environment with QoS, we routinely run 12 G.711 flows through a DOCSIS
>cable modem for multi-dwelling unit applications and the limit ends up
>being the number of discrete flows a DOCSIS cable modem chip can handle
>(16) rather than bandwidth limitations on the network.
>
>Geoff
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Mon, 19 Dec 2005 11:59:00 -0000
>From: "Chris Sutton" <chris at c4l.co.uk>
>Subject: Re: [VOIPSEC] [CAnet - news] Assessing Skype's network impact
>To: <Voipsec at voipsa.org>
>Message-ID: <025001c60493$997a98d0$6700a8c0 at office.toastedmedia.net>
>Content-Type: text/plain;	charset="us-ascii"
>
>Hi Robert,
>
>Thanks for the informative article. I'm always interested to read about
>companies testing Skype.
>
>I wasn't aware that Skype used so much bandwidth! "33K to 46Kbps" IS a
>lot for a voice call, and as you say, this would eat up bandwidth. Of
>course this is only a problem due to the limited upload stream on your
>office ADSL line. Nevertheless, such a high bitrate would still cause
>problems.
>
>The G.729 codec in fact uses only 6.4 - 11.8kbps bandwidth per call, and
>is a much better demonstration to customers of VoIP potential (there's
>nothing like a dropped call/low audio quality to send a customer
>running, screaming out the door!) I have found that codecs like G.711
>(which is 64kbps) can only manage about 2 concurrent calls before audio
>quality takes a severe nose dive.
>
>In my opinion it is this kind of limitation - like having a lack of PBX
>redundancy - that will make VoIP unmarketable as a business solution let
>alone as a replacement to POTS. I would even go as far as say that this
>will be more important than security to most companies (at least until
>VoIP becomes more widespread anyway)
>
>Sorry, just had to get that off my chest!!
>
>Regards,
>
>Chris
>
>-----Original Message-----
>From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
>Behalf Of Voipsec-request at voipsa.org
>Sent: 17 December 2005 12:00
>To: Voipsec at voipsa.org
>Subject: Voipsec Digest, Vol 12, Issue 17
>
>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. Fwd: [CAnet - news] Assessing Skype's network impact
>       (Robert Moskowitz)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 16 Dec 2005 10:29:38 -0500
>From: Robert Moskowitz <rgm at icsalabs.com>
>Subject: [VOIPSEC] Fwd: [CAnet - news] Assessing Skype's network
>	impact
>To: voipsec at voipsa.org
>Message-ID: <7.0.0.16.2.20051216102846.03c14af8 at icsalabs.com>
>Content-Type: text/plain; charset="us-ascii"; format=flowed
>
>Just another data point or two.
>
> >From: "Bill St.Arnaud" <bill.st.arnaud at canarie.ca>
> >To: <news at canarie.ca>
> >Date: Fri, 16 Dec 2005 10:14:27 -0500
> >Subject: [CAnet - news] Assessing Skype's network impact
> >Reply-To: bill.st.arnaud at canarie.ca
> >List-Id: CA*net News mailing list <news.canarie.ca>
> >
> >Assessing Skype's network impact
> >
> >For more information on this item please visit the CANARIE CA*net 4
>Optical
> >Internet program web site at
>http://www.canarie.ca/canet4/library/list.html
> >-------------------------------------------
> >
> >[Thanks to Harvey Newman for this pointer. Some excerpts from Network
>World
> >article-- BSA]
> >
> ><http://nwwsubscribe.com/highlights/facepage.asp?k=FOCHIPR&U=http://www
>.nwfu
> >sion.com&n=15>
> >
> >
> >If you're worried about Skype creating a security problem for your
> >network, don't, because the free VoIP service poses little danger to an
> >enterprise network. That's a good thing, because it's just about
> >impossible to keep Skype out of your network if end users are
>determined
> >to run it.
> >
> >That's the conclusion we reached after testing multiple versions of
> >Skype for several weeks in our independent test lab.
> >
> >Skype is inscrutable and mysterious. It uses indecipherable encryption.
> >It dynamically morphs traffic characteristics. It can work through
> >virtually any network address translation (NAT)-based firewall.
> >
> >And with more than 4 million online users at any given time, one can
> >assume that Skype has permeated many enterprise networks.
> >
> >We assessed the state of the encryption and security of the Skype
> >messages and streams, looking for exposed information that could be
> >useful to hackers and susceptible to man-in-the-middle interception and
> >diversion tactics. We evaluated the security of Skype Instant Messaging
> >and file transfer, along with the internetworking of Skype 1.4 and 2.0
> >beta. We also tracked the effect of Skype operations, in terms of CPU
> >and memory use, on laptops.
> >
> >Our testing shows that neither Skype VoIP nor Skype Instant Messaging
> >poses any readily exploitable security threat. We also conducted a
>dozen
> >private interviews with hackers, enterprise network managers and
>leading
> >network-security-equipment suppliers, none of which could cite one case
> >of Skype being exploited for insidious security assaults.
> >
> >Bandwidth is not a big concern either. A Skype voice call uses 33K to
> >46Kbps of bandwidth in each direction. This is not a lot, and is
>typical
> >of an efficient WAN-oriented VoIP vocoding, such as G.729. Of course,
>if
> >a few dozen internal users are concurrently running Skype calls, this
> >could eat up a T-1's worth of bandwidth.
> >
> >What should concern IT departments about Skype is not so much the
>danger
> >to security but the fact that it can't be controlled. Our testing shows
> >that:
> >
> >*
> >Skype works through firewalls and symmetric NATs (where a unique
> >external IP address is associated with each internal user). We tried a
> >number of commercial firewalls, configurations and even IPSs, which
>work
> >based on many higher-level traffic-analysis techniques, and we could
>not
> >prevent Skype from successfully establishing quality VoIP phone calls.
> >*
> >When Skype users download the software, they must consent to the usage
> >agreement that includes a provision allowing Skype to commandeer their
> >PC and its resources. The big fear is that the PC - ostensibly an
> >enterprise node with private company files and communications stored on
> >it - could become a Skype SuperNode. A Skype SuperNode is a
>commandeered
> >PC that plays a kind of proxy role in Skype call setup. We saw no
> >evidence of any attempted takeover or use of any of the Skype-loaded
>PCs
> >or laptops we tested. Conventional wisdom is that a SuperNode takeover
> >occurs only on nodes that maintain a long-term presence with the same
> >public IP address.
> >*
> >
> >Should Skype be stopped?
> >
> >We have not found or even heard of any plausible claims of inherent
> >security threats or vulnerabilities associated with Skype at this time.
> >
> >In our research, we found one major U.S.-based global manufacturer that
> >has decided to try to exclude Skype from its network. Technically, the
> >company could not do so (see the story "Spotting and stopping Skype:
> >good luck"), short of subjecting all its users' PCs to periodic scans
>to
> >detect Skype software. Even then, it would be possible for a user to go
> >to work, download Skype, make calls and then uninstall Skype from
>inside
> >the enterprise network, all in an afternoon. The company has decided to
> >arrange for users to make free, Internet-based calls via corporate
> >network resources as an alternative to Skype.
> >
> >How do you identify and stop Skype? There will soon be IPS vendors that
> >will work out a way to reliably spot and stop Skype calls in the short
> >term. However, as of this writing, there is no vendor we could find
>that
> >offered a commercial solution that stops Skype calls permanently.
> >
> >Skype is inscrutable: Skype traffic is encrypted, the User Datagram
> >Protocol and TCP ports it uses vary randomly; even the packet lengths
> >and VoIP voice sample sizes vary.
> >
> >
> >
> >
> >
> >-------------------------------------
> >To SUBSCRIBE:
> >send a blank e-mail message to
> >news-join at canarie.ca
> >
> >To UNSUBSCRIBE:
> >send a blank email message to
> >news-leave at canarie.ca
> >-------------------------------------
> >
> >These news items and comments are mine alone and do not necessarily
>reflect
> >those  of the CANARIE board or management.
> >-----------
> >Bill.St.Arnaud at canarie.ca
> >www.canarie.ca/~bstarn
> >skype: pocketpro
> >SkypeIn: +1 614 441-9603
> >
> >
> >_______________________________________________
> >news mailing list
> >news at canarie.ca
> >http://lists.canarie.ca/mailman/listinfo/news
>
>
>Robert Moskowitz
>Senior Technical Director
>ICSA Labs, a division of Cybertrust, Inc.
>W:      248-968-9809
>F:      248-968-2824
>VoIP:   248-291-0713
>E:      rgm at icsalabs.com
>
>There's no limit to what can be accomplished if it doesn't matter who
>gets the credit
>
>
>
>
>
>------------------------------
>
>_______________________________________________
>Voipsec mailing list
>Voipsec at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>End of Voipsec Digest, Vol 12, Issue 17
>***************************************
>
>
>
>
>------------------------------
>
>_______________________________________________
>Voipsec mailing list
>Voipsec at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>End of Voipsec Digest, Vol 12, Issue 19
>***************************************
>
>
>
>------------------------------
>
>Message: 3
>Date: Mon, 19 Dec 2005 10:23:01 -0600
>From: Gustavo Daniel Villarreal <dvillarreal at tvg.com.mx>
>Subject: Re: [VOIPSEC] [CAnet - news] Assessing Skype's network impact
>To: <Voipsec at voipsa.org>
>Message-ID: <BFCC3A85.250A%dvillarreal at tvg.com.mx>
>Content-Type: text/plain;	charset="ISO-8859-1"
>
>
>If the figures in the article reflect actual bandwidth plus overhead usage,
>then Skype's bandwidth usage is fairly typical. Overhead for VoIP calls can
>be well over 200%. A typical G.729 over Ethernet or Frame Relay will 
>consume
>30kbps, and 28kpbs over PPP (one way, assuming 50 packets per second), 
>which
>is quite a bit more than the 8kbps of the actual codec data. Applying IP
>Header Compression on PPP links, this overhead can be reduced to 14kbps
>total, a figure that is still well over the 8kbps of actual codec data.
>
>If the article's figures don't take overhead into account, then yes, wow it
>is a lot of bandwidth. Then again, Skype's perceived quality is much higher
>than G.729, and is encrypted.
>
>
>
>
>On 12/19/05 6:00 AM, "Voipsec-request at voipsa.org"
><Voipsec-request at voipsa.org> wrote:
>
> > I wasn't aware that Skype used so much bandwidth! "33K to 46Kbps" IS a
> > lot for a voice call, and as you say, this would eat up bandwidth. Of
> > course this is only a problem due to the limited upload stream on your
> > office ADSL line. Nevertheless, such a high bitrate would still cause
> > problems.
> >
> > The G.729 codec in fact uses only 6.4 - 11.8kbps bandwidth per call, and
> > is a much better demonstration to customers of VoIP potential (there's
> > nothing like a dropped call/low audio quality to send a customer
> > running, screaming out the door!) I have found that codecs like G.711
> > (which is 64kbps) can only manage about 2 concurrent calls before audio
> > quality takes a severe nose dive.
>
>--
>Gustavo Daniel Villarreal
>`````````````````````````
>Telecomunicaciones VG y Asoc.
>Monterrey, N.L. M?xico
>+528181302140
>
>
>
>
>
>
>------------------------------
>
>Message: 4
>Date: Mon, 19 Dec 2005 16:55:00 +0100
>From: Thomas Skora <voip at skora.net>
>Subject: Re: [VOIPSEC] [CAnet - news] Assessing Skype's network impact
>To: Voipsec at voipsa.org
>Message-ID: <kn1j73-954.ln1 at newspostings.skora.net>
>Content-Type: text/plain; charset=us-ascii
>
>"Christopher A. Martin" <chris at InfraVAST.com> writes:
>
> >>The G.729 codec in fact uses only 6.4 - 11.8kbps bandwidth per call, and
> >>is a much better demonstration to customers of VoIP potential (there's
> >>nothing like a dropped call/low audio quality to send a customer
> >>running, screaming out the door!) I have found that codecs like G.711
> >>(which is 64kbps) can only manage about 2 concurrent calls before audio
> >>quality takes a severe nose dive.
> >>
> >>
> >>
> > One other point to note is that the overhead includes encryption with
> > skype, as well as firewall traversal.
>
>Both task have never take place in the media stream. Look at SRTP, how
>many overhead the encryption causes here.
>
>Thomas
>
>
>
>
>------------------------------
>
>Message: 5
>Date: Tue, 20 Dec 2005 15:05:12 +0530
>From: AVM <drsavm at gmail.com>
>Subject: Re: [VOIPSEC] [CAnet - news] Assessing Skype's network impact
>To: Thomas Skora <voip at skora.net>
>Cc: Voipsec at voipsa.org
>Message-ID:
>	<a17009440512200135l30ecb502r9d72b5e600285a8 at mail.gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>On 12/19/05, Thomas Skora <voip at skora.net> wrote:
> >
> > "Christopher A. Martin" <chris at InfraVAST.com> writes:
> >
> > >>The G.729 codec in fact uses only 6.4 - 11.8kbps bandwidth per call, 
>and
> > >>is a much better demonstration to customers of VoIP potential (there's
> > >>nothing like a dropped call/low audio quality to send a customer
> > >>running, screaming out the door!) I have found that codecs like G.711
> > >>(which is 64kbps) can only manage about 2 concurrent calls before 
>audio
> > >>quality takes a severe nose dive.
> > >>
> > >>
> > >>
> > > One other point to note is that the overhead includes encryption with
> > > skype, as well as firewall traversal.
> >
> > Both task have never take place in the media stream. Look at SRTP, how
> > many overhead the encryption causes here.
> >
> > Thomas
>
>
>Hello,
>As Thomas pointed out, encryption would take place in the system before it
>leaves the system. As far as the symmetric encryption is not going to any
>overhead in the bandwidth except padding at the last block and few bytes of
>header information.
>
>AVM
>
>
>------------------------------
>
>_______________________________________________
>Voipsec mailing list
>Voipsec at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>End of Voipsec Digest, Vol 12, Issue 20
>***************************************

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.com/