Skype

[albatross710]

I've been finding Skype incredibly useful for reducing my phone costs as I can call all of my required countries for 2.7c per min. Once I have my notebook connected to the wireless network I'm using Skype to make my calls, even when I'm in the office.

When in the office I use Skype even for local calls as quite often the call only lasts a couple of minutes and might cost 5c instead of our telcos 25c min.

I did get caught out recently though.

I called a supplier's call centre on their 13xx_x number using Skype and later discovered that Skpe charge 32 cents per minute for 13 numbers. I was onhold for most of it and the one call ended up costing ~$3 for the call which via our landline would have been 25c.

In summary, when travelling and at home I'll be Skyping as much as I can.

Wayne

 

[simongr]

I have tried skype. Audio wise it worked well between two skype users (i.e. using it like msn) but using it to call has been terrible - I am not sure if its a hardware issue - but the audio quality is almost unlistenable

 

[albatross710]

Occasionally I've had a bad call but in the main the call quality has been excellent. They are up to software version 2.5 so if you haven't tried for a while, give them another go.

I'm liking the "portable" functionality of taking my calls and phone account with me as I travel around.

 

[swissbignose]

Actually, they're up to version 3.0.

I use skype a bit for internal work calls and to call out, and have only experienced a problem where my bandwidth was constrained.

 

[NM]

I have tried skype. Audio wise it worked well between two skype users (i.e. using it like msn) but using it to call has been terrible - I am not sure if its a hardware issue - but the audio quality is almost unlistenable

Skype claim to operate with a bandwidth between peers of between 3 and 16 kbps. Knowing that the audio stream uses UDP and RTP, and assuming a few features of their proprietary CODEC (such as 20ms samples and 3 samples per packet), the IP/UDP/RTP overhead is 40 bytes per packet sent every 60ms, or 5.3Kbps.

It is well known that latency has an affect on the subjective measure of call quality. The ITU has defined in G.114 that one-way latency for a voice call should not exceed 150ms. So a packet rate any less than 15/second will result in exceeding this recommendation in cases where the network latency is anything more than about 30ms, especially when receive jitter buffers are considered.

So this tells me the Skype bandwidth claim at the low end of their range is unachievable. And at the upper end of their range, that allows around 10kbps for the audio CODEC content.

The most common standard CODEC for low bandwidth VoIP calls is G.729 which has a network bandwidth requirement of 29.4Kbps including IP/UDP/RTP header overhead, or 8-16Kbps raw CODEC bandwidth.

So Skype is getting more than 40% better compression than G.729 CODEC, which I suggest is a direct result of the voice quality you have experienced compared with standard VoIP implementations. Skype determines the available bandwidth between the peers and configures its CODEC accordingly. So if you have limited bandwidth between the peers then expect poor audio quality.

I have serious reservations about the peer-to-peer operation fo Skype, especially when connected to the Internet without a NAT gateway. The Skype network relies on leveraging the resources of the distributed community of users for its directory services. I am unwilling to allow my computer and Internet bandwidth to be used for that purpose. However, I do recognise that it can provide cheap call for people in some situations.

I use VoIP extensively when travelling as I can make calls from Australia and the USA from anywhere I have sufficient Internet bandwidth. But it involves a significant amount of corporate infrastructure to do that and certainly more than 3-16Kbps of bandwidth to maintain a call (more like 100Kbps by the tiime the IPSec tunnel overhead is added).

 

[Febs]

Skype is my best friend when travelling. I use a Bluetooth headset and can walk around my hotel room while speaking to girlfriend/friends/family in Australia. I've never had a problem with any hotel Internet connection - either speed, latency, or firewall-related.

It might be a bit more expensive than some other VoIP solutions, but it just works!

My only problem with it is the hassle I have expensing my Skype credit when I get back. Our expense department sees the word "credit" and associate it with pre-paid mobile phone credit, which they don't reimburse. Always gets through in the end though.

Cheers,
- Febs.

 

[adrian]

I use it quite a lot when I am overseas. I find it very good to call landlines, but not so great to call mobiles. I can live with that, for the cost. My current mobile has wifi, so I don't need to call thru my computer anymore - it is just like making a mobile call, but without the cost. Very handy....

 

[mainly tailfirst]

Skype claim to operate with a bandwidth between peers of between 3 and 16 kbps. Knowing that the audio stream uses UDP and RTP, and assuming a few features of their proprietary CODEC (such as 20ms samples and 3 samples per packet), the IP/UDP/RTP overhead is 40 bytes per packet sent every 60ms, or 5.3Kbps.

IIRC, Skype quotes BW usage at 3-16 kBytes/sec, not kbps. <checks web>
Yep, http://www.skype.com/help/faq/technical.html confirms this.

I've never instrumented the stream (though I may be motivated to do so now that I intend to use it more), but from experience I get excellent Skype-to-Skype audio quality at between 5-6kB/sec. I find 3-3.5kB/sec yields acceptable quality even for trans-pac calls into a landline.

I don't know what Skype uses for POTS termination - I suspect G.711 or G.729 - so even the lower bound of 3kB/sec should be OK.
<snip>

So this tells me the Skype bandwidth claim at the low end of their range is unachievable. And at the upper end of their range, that allows around 10kbps for the audio CODEC content.
The most common standard CODEC for low bandwidth VoIP calls is G.729 which has a network bandwidth requirement of 29.4Kbps including IP/UDP/RTP header overhead, or 8-16Kbps raw CODEC bandwidth.

If we assume an IP packet size of 160B ('typical' number I remember from somewhere), 40B header o/head and packet every 30mSec, we get approx 5.2kB/sec - which dovetails nicely with my very rough measuring (add another 14B for Ethernet header per packet). So having an audio stream at ~3.8kB/sec (30kb/sec) explains alot why the quality is so good.
As you state above, to get the quality that they do with an 8th of that bandwdth would be extraordinary - obviously they don't.
I don't think Skype's audio codec is that brilliant, certainly I would expect that Motorola and Nokia et al. have better ones in their phones.
<snip>

I have serious reservations about the peer-to-peer operation fo Skype, especially when connected to the Internet without a NAT gateway. The Skype network relies on leveraging the resources of the distributed community of users for its directory services. I am unwilling to allow my computer and Internet bandwidth to be used for that purpose. However, I do recognise that it can provide cheap call for people in some situations.

To me, this is the real magic of Skype. I give up some bandwidth (usually an ammortized cost if I'm on a decent monthly plan), minor hit to processing (free) and in turn I get excellent sound quality calling most people for nix. Fair enough swap - almost a 17th century commons in action.

Aside: I never thought I'd have such a good tech thread on AFF. But there you go

mt

 

[NM]

IIRC, Skype quotes BW usage at 3-16 kBytes/sec, not kbps. <checks web>
Yep, Skype Technical Frequently Asked Questions confirms this.

I've never instrumented the stream (though I may be motivated to do so now that I intend to use it more), but from experience I get excellent Skype-to-Skype audio quality at between 5-6kB/sec. I find 3-3.5kB/sec yields acceptable quality even for trans-pac calls into a landline.

Ahh, yes. That makes more sense. Making it 24-120kbps.

But with VoIP, the most common cause of quality issues are dropped packets and jitter. Unfortunately there is no way to control those things on a public network like the Internet.

Another major factor for any softphone can be the audio device being used. Using built in microphone/speakers or even just adding a microphone and headphones to a computer generally results in poor audio quality. Using a USB audio device with its own DPS generally results in better quality. I use a Nortel USB DPS headset and get very good audio quality with various soft phones that I use, yet using a microphone and headphones with the same computer and software results in very much sub-standard quality.

I don't know what Skype uses for POTS termination - I suspect G.711 or G.729 - so even the lower bound of 3kB/sec should be OK.

I believe it is neither. Their direct POTS connection in most cases will be T1/E1 (ISDN in most cases) which use a 64kbps PCM which is similar to G.711. The connection from the Skype client to the POTS gateway uses the Skype proprietary CODEC which is neither G.711 or G.729 (not that it really matters, so long as it works).

If we assume an IP packet size of 160B ('typical' number I remember from somewhere), 40B header o/head and packet every 30mSec, we get approx 5.2kB/sec - which dovetails nicely with my very rough measuring (add another 14B for Ethernet header per packet).

G.711 CODEC results in 160 bytes of data per packet. Sample rate is 8000 samples/second using logarithmic PCM. The CODEC sample interval is 10ms resulting in 80 bytes per sample interval, and two samples are carried in each voice payload resulting in 160 bytes every 20ms.

Add to the 20 bytes for IP, 8 bytes for UDP and 12 bytes for RTP and we have 40 bytes of packet overhead or 200 bytes/packet at a rate of 50 packets/second. This results in 80Kbps requirement plus the layer-2 MAC requirements (ethernet, PPP, FR etc). On ethernet it grows to 87.2Kbps and on FR it would be 82.8Kbps.

G.729 is a little different, producing 10Bytes or data every 10ms sample and again sent as 2 samples every 20ms resulting in 20 bytes of data with the same 40 bytes of IP/UDP/RTP overhead. These 60 byte packets are sent at a rate of 50 packets/second resulting in a requirement of 24Kbps plus layer-2 overhead. On ethernet it grows to 31.2Kbps and on FR it would be 26.8Kbps.

So having an audio stream at ~3.8kB/sec (30kb/sec) explains alot why the quality is so good.
As you state above, to get the quality that they do with an 8th of that bandwdth would be extraordinary - obviously they don't.
I don't think Skype's audio codec is that brilliant, certainly I would expect that Motorola and Nokia et al. have better ones in their phones.

You have to wonder why they didn't just use G.729. I guess by keeping it proprietary they have to maintain control of the product/service??

To me, this is the real magic of Skype. I give up some bandwidth (usually an ammortized cost if I'm on a decent monthly plan), minor hit to processing (free) and in turn I get excellent sound quality calling most people for nix. Fair enough swap - almost a 17th century commons in action.

Providing you have a good ISP connection and don't suffer congestion, lost packets or jitter, and you use a decent DSP audio device on the PC, quality can be good. I still worry about using any Peer-2-Peer application on my PC. But I probably make 15+ hours of calls a week using various VoIP services, all via my home ADSL Internet service. But mine have the added overhead of running through an IPSec tunnel as well, adding a further 52 bytes/packet overhead so my G.711 connections use closer to 120Kbps and G.729 is more like 70Kbps

Aside: I never thought I'd have such a good tech thread on AFF. But there you go

mt

Its amazing what snippets of trivia can be find in a community like this :mrgreen: .

 

[serfty]

What they said!

 

[Evan]

I feel right at home on this thread
But i am at home beer in hand, brain dead from to much work on a monday.

Anybody done the maths on the power requirements for POE to run all those alternate to skype VIOP handsets ? scary !
I think std PABX's and lines will be around a while yet.

Evan

 

[NM]

Anybody done the maths on the power requirements for POE to run all those alternate to skype VIOP handsets ? scary !

The one here on my desk at home is around 5 watts. But since I don't have POE at home (not supported on my Cisco 877W router) it is supplied from a plug-pack power supply.

No extra power requirements when using one my 3 IP Softphone clients (two SIP clients and a H.323 client).

I have had three concurrent active calls using SIP out over my ADSL service via a USA-based IP-PBX, one from my desk phone, one softphone on my laptop and one softphone on my PocketPC.

The real challenge is getting the QoS configured right so I can still surf and replicate my email etc without killing the call quality. Outbound queuing is easy (low latency queuing), but controlling the inbound is the tricky bit .

 

[Evan]

5 watts * 48 port blade = 240 watts / blade. hmmmmmm....

Why 3 calls at once, were you billing 3 customers at the same time as well

Do you use the IPsec on that router or your VPN is software off your workstation ?

E

 

[NM]

5 watts * 48 port blade = 240 watts / blade. hmmmmmm....

Actually, the IEEE 802.3AF standard says that each POE port should be able to deliver 15.4Watts. Now that is one heck of a power requirement for a chassis with lot of ports. Currently nobody is shipping a 48 port IEEE802.3AF compliant blade.

One of the big problem is in the provision of UPS power and cooling in the distribution layer of the network. People expect their phones to keep working during a power outage, so a corporate/enterprise VoIP solution needs to provide UPS power to the distribution layer switches that are delivering the POE. And those POE switches now have big power appetites and lots of heat dissipation to match, meaning the floor distribution wiring closets now need more power, UPS capabilities and air 24x7 air conditioning. So better calculate that in the ROI spreadsheet.

Consider that the Cisco 6500 chassis now supports up to 6000 Watts of power supply in order to deliver high density POE capabilities.

Not many phones that need 15.4 Watts, but some Wireless APs and VC units do come close.

Why 3 calls at once, were you billing 3 customers at the same time as well

I had two conflicting conference calls, so was listening to both at the same time. Then someone called my SIP address so I answered it on my PocketPC. Unfortunately I rarely get to bill anyone for my time, especially my conference calls.

Do you use the IPsec on that router or your VPN is software off your workstation ?

E

Both. I have a permanent PISec tunnel from my router to a location in the USA. The depending on which wireless SSID/VLAN my PC is connected to, it either routes down that IPSec tunnel or is NATed direct to the Internet via my ISP and I can then use a PC VPN client to connect to our Australian VPN gateway (also IPSec).

So if using the Softphone from the USA IP-PBX, I switch to the appropriate wireless SSID/VLAN and route down the IPSec tunnel. If using one of the Australian IP-PBX systems I use the PC VPN client routed to the Australian VPN gateway.

I am yet to find a usable PocketPC IPSec client, so it always connects to the secure SSID/VLAN and routes down the tunnel to the USA IP-PBX.

So when you add the POTS phone attached to my ADSL line, the home POTS line and my Mobile phone, I have quite a few options for making calls! The IP phone via the USA is very handy for calling AA since it is then litterally a local call .

 

[Kiwi Flyer]

 

[mainly tailfirst]

Ahh, yes. That makes more sense. Making it 24-120kbps.

But with VoIP, the most common cause of quality issues are dropped packets and jitter. Unfortunately there is no way to control those things on a public network like the Internet.

Agreed. If we could get all the parties involved to properly use the TOS or Diffserv flags, we could rectify this to a degree. But given the war going on over net neutrality and the requirement that everyone in the chain agree to the rules - I can't see it happening anytime soon. For now, just good old overprovision of BW and hope that the terminating ISPs have few hops to the SONET backbone is the way to go.

I believe it is neither. Their direct POTS connection in most cases will be T1/E1 (ISDN in most cases) which use a 64kbps PCM which is similar to G.711. The connection from the Skype client to the POTS gateway uses the Skype proprietary CODEC which is neither G.711 or G.729 (not that it really matters, so long as it works).

<overview snipped>

You have to wonder why they didn't just use G.729. I guess by keeping it proprietary they have to maintain control of the product/service??

After a little digging - I can claim this is work related research - I found that Skype uses an implementation of Internet Low Bit Rate Codec (iLBC)
for the voice codec. RFC is here: http://www.ietf.org/rfc/rfc3951.txt
This seems to degrade more gracefully with dropped packets then either G.711 or G.729. Other VoIP products can use it, so it's not Skype specific.

Its amazing what snippets of trivia can be find in a community like this :mrgreen: .

You're not kidding. I never thought I would ever see ANY references to 802.3 standards on a FF forum. :shock:

 

[mainly tailfirst]

The real challenge is getting the QoS configured right so I can still surf and replicate my email etc without killing the call quality. Outbound queuing is easy (low latency queuing), but controlling the inbound is the tricky bit .

There are a few ethernet controllers coming onto the market now that allow pre-classification of incoming traffic into separate receive queues. Some of these parts will be cheap enough to go into the sub $200 routers that you find from Netgear and the like. I am not yet aware of how the stack software will interface to these 'smart' ethernet controllers, but the capability is there to do a poor man's NBAR on receive traffic. In theory the same capability can be added to 802.11 controllers, but I have yet to see one.

mt

 

[Tooner]

I use Skype for Skype - Skype and video calls. Where the broadband is free or low costs it's a good way to stay in touch, I feel.

I don't understand how it works.

Clearly there are a few people who do and are contributing most to this thread!

 

[NM]

You're not kidding. I never thought I would ever see ANY references to 802.3 standards on a FF forum. :shock:

So the logical extension is now to discuss the signalling used by Skype . Again I assume its proprietary, but is it some manifestation of H.323, SIP, Q.931 or similar?

There are a few ethernet controllers coming onto the market now that allow pre-classification of incoming traffic into separate receive queues. Some of these parts will be cheap enough to go into the sub $200 routers that you find from Netgear and the like. I am not yet aware of how the stack software will interface to these 'smart' ethernet controllers, but the capability is there to do a poor man's NBAR on receive traffic. In theory the same capability can be added to 802.11 controllers, but I have yet to see one.

The problem is that the point of congestion is way before your receive queues. So unless you start playing with window sizes and delayed flow control (delayed ACKs) there is not much you can do to manage the inbound congestion successfully. And those things only work for TCP streams anyway. But it could be used for classification and marking purposes.

I could never go back to a basic home router after using my Cisco 877W. I have it running three separate SSIDs using VLANs (2 with WPA-PSK and one WEP which is my guest VLAN and only provides rate limited Internet access), outbound Diffserve marking and LLQ, policy-based routing to send some traffic down the IPSec tunnel and other is NATed and sent to the Internet with wo different NAT policies.Its my DHCP server, running IP-Helper between VLANs and makes a pretty good cup of coffee. No Netgear, Linksys, D-Link etc "router" is going to do that! Now if only Cisco made an 800-series router with POE .

But getting back on-topic. I do find using VoIP with a Sotfphone is a very valuable tool when travelling. And its always fun confusing people as to where I am. Making calls when in the USA that have a Caller-ID of 02xx_xx_xx confuses people, as does making calls with a US 817 area code when I am at home in Brisbane. Skype is a means for anyone to be able to take advantage of network bandwidth without the investment in the back-end infrastructure.

 

[mainly tailfirst]

So the logical extension is now to discuss the signalling used by Skype . Again I assume its proprietary, but is it some manifestation of H.323, SIP, Q.931 or similar?

Doesn't appear to be based on any previous signalling standard. Given the extraordinary lengths that Skype has gone to in obfuscating it's operation, most of the information I have learnt is based on reverse-engineering papers. The use of the super-node is key and there is a far bit of speculation as to what happens after the supernode is reached. Since everything is encrypted if v.hard to work out what exactly is being exchanged.

The problem is that the point of congestion is way before your receive queues. So unless you start playing with window sizes and delayed flow control (delayed ACKs) there is not much you can do to manage the inbound congestion successfully. And those things only work for TCP streams anyway. But it could be used for classification and marking purposes.

Aah, the 'inbound' problem on the WAN side. I assumed you were referring to the 'outbound' from your internal network. I.e. some of your precious upload link was getting clobbered by non-RT traffic. Pre-Classification and hardware support for RED can help with that. Agreed, that not much can be done once it is mixed into a single link (yet).

I could never go back to a basic home router after using my Cisco 877W. I have it running three separate SSIDs using VLANs (2 with WPA-PSK and one WEP which is my guest VLAN and only provides rate limited Internet access), outbound Diffserve marking and LLQ, policy-based routing to send some traffic down the IPSec tunnel and other is NATed and sent to the Internet with wo different NAT policies.Its my DHCP server, running IP-Helper between VLANs and makes a pretty good cup of coffee. No Netgear, Linksys, D-Link etc "router" is going to do that! Now if only Cisco made an 800-series router with POE .

True. I run a hacked firmware on my Linksys that does give me some of that functionality, though the rather pokey CPU in it means that the more features I turn on (e.g. VPN tunnel) things like wireless video streaming to my Myth box drop dead. The SW is willing, but the HW is weak...

A lot of what make Cisco routers great is the fact that they run IOS and have great support for their custom HW that they run it on. IMO, as more HW features make it into the low end parts and get supported by Linux, the difference will narrow.
The coffee feature is a new one though. Is it just filter or can it do espresso as well?

Skype is a means for anyone to be able to take advantage of network bandwidth without the investment in the back-end infrastructure.

Or more efficiently use that which has already been provisioned.

mt