Skype

[Soundguy]

I have been using Skype for quite a while now; when I started I had to import a VOIP handset as they were not available here and at the time computer shops didn't know what I was talking about when I asked. But I find the audio quality is mediocre at best. I use it between work and home (Skype to Skype) and half the time give up and call on the regular phone as it keeps dropping and chopping. Sometimes you can only hear less than 50% of what the other party is saying. Yes, high speed ADSL either end.

I also use Skype Out to call India which is otherwise quite expensive via regular phone. But the quality is quite poor & frequently you have to give up and try again later. Updating software has made no noticable difference to the quality.

The biggest benefit to me is when travelling around the USA where wireless networks are plentiful and it is the cheapest way to check messagebank etc back home.

Wouldn't dream of trying to make any local business calls with it, have to apologise for the often choppy quality each call whenever I tried but when ringing Oz from the US customers accept the poor quality due to the distance.

 

[NM]

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.

Its the closed nature of what goes on that is the biggest concern to me. These are they same guys that developed some other peer-2-peer apps that have been used to spread some less than savoury programs around the net.

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).

My outbound QoS is rock solid. That is the part over which I have full control. My email replication is limited to a rate that will not kill everything else, Voice is LLQ etc. Best inbound results are obtained when I trunk all the traffic down the IPSec tunnel and hit the Internet from there. That way I have QoS control over all the inbound traffic. At the remote end I shape it down to my ADSL bandwidth, classify and mark the VoIP traffic and LLQ the traffic back down the tunnel. Works a treat. But when I allow some traffic to go to the internet directly from the router, I have no control over the inbound traffic

But I would like to see a networking novice configure and support the type of connection I use here. Its not for the faint hearted. Being an IOS CLI junky helps.

 

[mainly tailfirst]

I have been using Skype for quite a while now; when I started I had to import a VOIP handset as they were not available here and at the time computer shops didn't know what I was talking about when I asked. But I find the audio quality is mediocre at best. I use it between work and home (Skype to Skype) and half the time give up and call on the regular phone as it keeps dropping and chopping. Sometimes you can only hear less than 50% of what the other party is saying. Yes, high speed ADSL either end.

As NM can tell you better than I, it's not so much a matter of what the ends look like that determines how good your skype link is, but what lies in the middle. You can both have ADSL2 links at 12Mbit/s, but if your call goes through 30 hops and a satlink, odds are Skype is going to sound woeful. Try pinging your home IP address from your work one and vice versa and see:
a) how many packets are lost
b) average ping time

If these are good (e.g. 100% and <30mSec) then I suspect your work's firewall is the culprit. It may be blocking all UDP traffic and forcing skype to do a TCP connection via a supernode to get to your home machine. Result is degraded call quality, especially if the supernode is far away.

mt

 

[mainly tailfirst]

Its the closed nature of what goes on that is the biggest concern to me. These are they same guys that developed some other peer-2-peer apps that have been used to spread some less than savoury programs around the net.

I'm somewhat neutral on this. Kazaa has some decent non-infringing uses, but it was also clear what the majority of the appeal was. With Skype, IMO, they've gone to extreme lengths to obscure things to:
a) preserve their Skypein and SkypeOut revenue streams.
b) prevent 'ordinary' people from stopping their Skype clients from turning into Supernodes - thus preventing the Skype network from collapsing.

I have no problems using their software, certainly I regard them as at least as trustworthy as the free e-mail company I use.

It'll be interesting to see how they go complying with CALEA. That may force them to open things up a bit. In any case, in another year or two the basics

My outbound QoS is rock solid. That is the part over which I have full control. My email replication is limited to a rate that will not kill everything else, Voice is LLQ etc. Best inbound results are obtained when I trunk all the traffic down the IPSec tunnel and hit the Internet from there. That way I have QoS control over all the inbound traffic. At the remote end I shape it down to my ADSL bandwidth, classify and mark the VoIP traffic and LLQ the traffic back down the tunnel. Works a treat. But when I allow some traffic to go to the internet directly from the router, I have no control over the inbound traffic

But I would like to see a networking novice configure and support the type of connection I use here. Its not for the faint hearted. Being an IOS CLI junky helps.

Neat setup. Considerably more effort than I would be prepared to go to! IPTables is hairy enough for me, let alone configuring IOS and a remote VPN setup. :shock:

mt

 

[NM]

I'm somewhat neutral on this. Kazaa has some decent non-infringing uses, but it was also clear what the majority of the appeal was. With Skype, IMO, they've gone to extreme lengths to obscure things to:
a) preserve their Skypein and SkypeOut revenue streams.
b) prevent 'ordinary' people from stopping their Skype clients from turning into Supernodes - thus preventing the Skype network from collapsing.

The last think I want is for my PC to be a supernode! I agree with your view.

Neat setup. Considerably more effort than I would be prepared to go to! IPTables is hairy enough for me, let alone configuring IOS and a remote VPN setup. :shock:

Its helps being a CCIE .

 

[wandering_fred]

Well - perhaps this is time to take advantage of the group knowledge base...

Currently Skype with the various ADSL setups (2 locations) the basic elcheapo ADSL routers work fine - EXCEPT - when using SkypeOut from Oz to the USA. The problem there (when there is a problem) being excessive latency - delays in the conversation "change over" or serious echoes on the Oz end. SkypePC to SkypePC seems better behaved.

But here's where I need a pointer (or 2 or 3). We are moving back to the farm.... regional Australia. No ADSL in the local exchange - minimal prospects for ADSL in the exchange. House is about 4km from exchange.

Options seem to be DOV with 128kbs ISDN (2 lines) or satellite.... The latter seems to be problematic with rumors of VOIP being either banned under the usage agreements or serious issues with the (guaranteed and mandatory) satellite delays........ I'm behind a hill so the new 3G wireless looks to need a 20m tower.

Thoughts guys???????

Thanks
Happy wandering (unless you avoid the cities?)

Fred

 

[mainly tailfirst]

Well - perhaps this is time to take advantage of the group knowledge base...

Currently Skype with the various ADSL setups (2 locations) the basic elcheapo ADSL routers work fine - EXCEPT - when using SkypeOut from Oz to the USA. The problem there (when there is a problem) being excessive latency - delays in the conversation "change over" or serious echoes on the Oz end. SkypePC to SkypePC seems better behaved.

When you say "echos on the Oz end" I assume you mean you can here yourself echoing - that usually indicates feedback on the US side. Any number of things could be causing the audio problems. Could be a bad conversion at the US SkypeOut end, or might even be a dodgy speakerphone at the US end (thus not Skype at all).

But here's where I need a pointer (or 2 or 3). We are moving back to the farm.... regional Australia. No ADSL in the local exchange - minimal prospects for ADSL in the exchange. House is about 4km from exchange.

Options seem to be DOV with 128kbs ISDN (2 lines) or satellite.... The latter seems to be problematic with rumors of VOIP being either banned under the usage agreements or serious issues with the (guaranteed and mandatory) satellite delays........ I'm behind a hill so the new 3G wireless looks to need a 20m tower.

Thoughts guys???????

Thanks
Happy wandering (unless you avoid the cities?)

Fred

Uugh, not a lot of good choice there. From memory DoV is rather expensive, plus when you make a 'real' call, your bandwidth drops by half. Satellite is typically the 'broadband of last resort', though a lot of work has been done in recent times and I've even seen VoIP over satellite being advertised. E.g. http://www.voipnews.com.au/content/view/1288/109/
Is the satellite oneway (e.g. uplink is via a regular modem) or full duplex? If the former, then don't expect great Skype or email sending performance. If the latter, well it's not bad once you get used to the "click on a link, wait... wait... wait... boom! there's the page" mode of operation. I've not used two way comms via it though, so I can't really comment on that.

HTH
mt

 

[QF WP]

I'm with serfty and Kiwi Flyer, what have they been saying :?:

Being a non-techo person, it sailed clear over my head and may as well have been Swahili, for all I understood.

However, I have loaded Skype onto my computer as our cousins have decided it's time for us all to talk on Skype. Now I do have a headphone from my voice recognition software...now to put my toe in the water and see if it works.

 

[kpc]

I have been using Skype for a few months now...it is fantastic as my interstate phone call bills have vanished:mrgreen: On my recent trip to Penang and Singapore, I took my laptop with me. I got free WiFi every where I went, and I could call home to Oz for free. With the webcam, I could also show the people I was calling views of my hotel room, views out of my room, the airport lounges etc. It's a shame that Connexion no longer exists, as I could make calls on Skype from 30000 feet

As to how Skype works, even after reading the above, I have still no idea...

Oh...you can also call back to Oz to a normal phone for 2.6 c / minute....I love Skype!

 

[Evan]

DOV with 128kbs ISDN (2 lines)

That would be my choice for a low latency connection and 128kb at that low latency is actually not nearly as bad as it may sound.

Also ISDN has come down a huge amount in cost in the last couple of years.

For my work i would choose that anyway. Latency for me is a much bigger issue sometimes than bandwidth.

 

[wandering_fred]

Quote: As to how Skype works, even after reading the above, I have still no idea..

Well if I had all the details - would I be sitting here :mrgreen: ????

Some very simple minded thoughts

sound - at least the male voice is in the range of 440 Hertz (cycles per second if you are old as I am - A below middle C if you are a musician) - so sampling what noise there is - a few tens of thousands times a second - gives you the digital points that are used to create audio CDs or digital recordings. Since computers are actually so much faster than that - relatively speaking - it's an easy job and the quality is quite good.

OK now add in a computer network.... sending the CD quality audio from one computer to another - playing mp3 files across the work network - that is if the company still lets you - simply moves the (large) set of digital points in a stream to the audio player on the computer you have the earphones plugged into..... And almost all company (or household) networks are plenty fast enough for that.

What Skype have done is all the homework related to sending this set of digital points (your voice) across the open Internet network. Suffice to say - there the audio data files are competing with all the Excel, powerpoint and internet page files everyone else is sending. So getting them collected at the other end is a reasonably touchy task. And of course there is the directory lookup for the 6 to 8 million on-line users - so they can identify the computer to send the bits to.

Having done that - they add a few bells and whistles - Skype In and Skype Out - which connects to the Plain Old Telephone System - POTS for short. And they charge you enough to make a nice profit for themselves and seriously undercut the international telephone charges in most countries.

My problem - in short - is that dialup on the POTS - the old fashioned modem - doesn't really create a "pipe" wide enough to carry the (voice) digital bit stream reliably. ADSL or cable connections (even the slowest) are. Most WiFi hotposts are faster than the basic ADSL. But in Oz Telstra isn't going to put ADSL in the country exchanges unless they feel enough people have asked for it there - or - the government tells them to and provides some $$ to do it. Hence my efforts to find a satellite internet connection at a reasonable cost that will permit Voice over IP (VOIP) of which Skype is the most well known.

I'll let you know what the satellite ISP has to say........

Happier wandering

Fred

 

[NM]

sound - at least the male voice is in the range of 440 Hertz (cycles per second if you are old as I am - A below middle C if you are a musician) - so sampling what noise there is - a few tens of thousands times a second - gives you the digital points that are used to create audio CDs or digital recordings. Since computers are actually so much faster than that - relatively speaking - it's an easy job and the quality is quite good.

Telephony is usually limited to the frequency range 200-4000Hz. Nyquest shows us that sampling must be at double the maximum frequency rate to be able to rebuild the original signal. Digital telephony, including VoIP, generally samples at 8000Hz. CDs and other digital audio media that carry the full audio spectrum to 20KHz must sample at over 40KHz according to Nyquest, and 44HKz and 48KHz are common sampling rates. 96KHz is also common in high-end digital mixing consoles (and some lower-end ones like the Yamaha 01V96).

OK now add in a computer network.... sending the CD quality audio from one computer to another - playing mp3 files across the work network - that is if the company still lets you - simply moves the (large) set of digital points in a stream to the audio player on the computer you have the earphones plugged into..... And almost all company (or household) networks are plenty fast enough for that.

MP3 (and other CODECs) adds another level of "complexity" as it not just undergoing digital sampling, but then taking the end result and compressing it significantly. Depending on the amount of compression, the reconstruction of the original source may not be completely accurate.

What Skype have done is all the homework related to sending this set of digital points (your voice) across the open Internet network. Suffice to say - there the audio data files are competing with all the Excel, powerpoint and internet page files everyone else is sending. So getting them collected at the other end is a reasonably touchy task. And of course there is the directory lookup for the 6 to 8 million on-line users - so they can identify the computer to send the bits to.

The audio packets in any VoIP conversation need to be carried in real time, while transferring a file is less time critical. As such, most data transfers will use a reliable transport such as TCP that provides flow control, windowing, error/loss detection, sequencing and re-transmission etc. The real-time nature of voice traffic means that if a packet arrives of sequence or is dropped/lost enroute, there is no way to re-transmit it or queue the receipt to insert out-of-sequence packets. So VoIP is more susceptible to packet loss, sequencing and jitter (variation in latency/delay) than a file transfer.

The other problem on low-bandwidth links is the jitter created when large packets are serialised onto the transmission media. This can be a problem if you are using something like the 128Kbps ISDN mentioned previously. At 128Kbps (and note that this is a binding of two 64Kbps using multilink PPP usually), a 1500 byte packet (the default MTU size) will take around 10ms just to be serialised onto the ISDN trunk. So even with an priority queue for voice traffic, you are adding at least 10ms latency and hence jitter when transmitting large packets such as file transfers. For this reason, it is advisable to reduce the MTU on low-speed transmission services when using a priority queuing mechanism.

My problem - in short - is that dialup on the POTS - the old fashioned modem - doesn't really create a "pipe" wide enough to carry the (voice) digital bit stream reliably. ADSL or cable connections (even the slowest) are. Most WiFi hotposts are faster than the basic ADSL. But in Oz Telstra isn't going to put ADSL in the country exchanges unless they feel enough people have asked for it there - or - the government tells them to and provides some $$ to do it. Hence my efforts to find a satellite internet connection at a reasonable cost that will permit Voice over IP (VOIP) of which Skype is the most well known.

I'll let you know what the satellite ISP has to say........

Satellite Internet connection will add significant latency to the service. A geosynchronous satellite orbits at just over 35,000km altitude, resulting in around 250ms return signal path. So with just one satellite link you have more than exceeded the ITU recommendation for delay in an audio network.

Such delay has two affects, the first being the duplex nature of real conversations and a delay of more than 250ms is going to result in people talking over the top of each other. The other is the efficency and operation of echo cancellation. Echo is induced in voice networks as a result of several factors such as 2-4 wire hybrid circuits and mismatched impedance in analogue circuits. This is less of an issue for IP to IP conversations, but when making off-net calls such as SkypeIn and SkypeOut the conversion from analogue to digital in a potential source of echo. Digital Echo cancellation relies on the canceller knowing what was sent out and identifying the same (generally reduced level) signal returning some time later. This requires buffering of the retained outgoing source for a finite period of time. In most cases, digital echo cancellation cannot cope with more about 400ms buffering. A voice call over a geosynchronous satellite will have an echo return time of over 500ms and possibly up to 700ms if using a POTS gateway at a remote location.

So I would expect the best results for Skype (or any other VoIP technology) from the 128Kbos ISDN option, so long as you manage the QoS properly and ensure you don't saturate the return path during the call (i.e. downloading other things from the Internet at the same time). The asymmetric nature of ADSL is helpful since you can control out outbound queuing far easier than the inbound.

Another thing to aware of with the ISDN option is that it is often configured for voice calls as well. In this mode when you have a voice call active the data bandwidth drops to 64Kbps as one B channel is used for the voice call. 64Kbps is very marginal even for Skype.

Maximise your probability of decent call quality by reducing the MTU size and priority queuing the voice traffic (all RTP is probably good enough for home use). Also ensure you use an audio device with its own DSP and not rely on the PCs own microphone pre-amp and headphones. A good USB headset can be purchased for around $50 and it is well worth the investment if using VoIP for calls.

 

[mainly tailfirst]

I was going to join NM in suggesting likely MTU values for the ISDN link. But, after reading RFC1356, I decided that, like Toto, we just weren't in Kansas any more. No one on this forum should be subjected to any discussion on X.25 message sizes...

Instead, I'm going to suggest that this thread form the basis for course notes for someone's "Applications for IP Comms 201" lecture series

mt

 

[Evan]

On a side note has anybody noticed that some products like outlook client can generate some huge packets and with a large MTU size will happily cause Cisco's VPN client to blue screen your machine ?

Anyway food for thought if anybody has that issue.

Evan

 

[Mal]

On a side note has anybody noticed that some products like outlook client can generate some huge packets and with a large MTU size will happily cause Cisco's VPN client to blue screen your machine ?

Nope! Never seen a blue screen caused by the Cisco VPN client. Spose it is something to look out for though.

 

[NM]

On a side note has anybody noticed that some products like outlook client can generate some huge packets and with a large MTU size will happily cause Cisco's VPN client to blue screen your machine ?

Anyway food for thought if anybody has that issue.

Evan

What do you mean by huge packet? No single packet should exceed the MTU and its unusual to have an MTU greater than 1500 bytes unless on a Gig Ethernet, token ring, FDDI or similar high bandwidth circuit.

Have you reported your problem to the Cisco TAC?

 

[Evan]

What do you mean by huge packet? No single packet should exceed the MTU and its unusual to have an MTU greater than 1500 bytes unless on a Gig Ethernet, token ring, FDDI or similar high bandwidth circuit.

Have you reported your problem to the Cisco TAC?

I am not sure of the size now, but as you say 1500 bytes is a large packet, i have a feeling is was 2500. I presume the issue was reported to Cisco (Am am not the networking guru, but i will ask on of them), as it was really a configuration issue and a result of other software setting a large MTU i wouldn't really call it a Cisco problem.

Also our environment can be somewhat different that most others so it could also be specific to us and our strange config.
(By different i am refering to changes to windows to only allow connections to a single network at once, and all sort of other tweaks, this is to stop access to internet and the corprate network at the same time)

Was just something to keep in mind as a starting point for anybody having strange issues with the cisco vpn solutions.

Evan

 

[NM]

(By different i am refering to changes to windows to only allow connections to a single network at once, and all sort of other tweaks, this is to stop access to internet and the corprate network at the same time)

Actually, that is called "split tunnelling" and is very common to disable split tunnelling with VPN connections. It is perceived as a security risk to have access to both the local network and VPN at the same time. But it can cause some other issues such as not being able to print to a local network printer while the VPN tunnel is active.

Split Tunnelling is a configuration parameter defined by the VPN gateway device. Nothing is changed on the local PC to enable or disable it. During the tunnel establishment process, the VPN gateway tells the client what features it is permitted to use, such as whether split tunnelling is permitted or not. The gateway also delivers the client a list of routes that are inserted into the client's route table and any subsequent changes to the client route table are flagged as breach of policy and will cause the VPN session to be dropped. Early implementations of Split Tunnel restrictions did not perform the check on changes to the client's route table, so it didn't take long for some of us to write a .BAT, .CMD or Perl script to alter the route table after connecting the VPN. To overcome this, the Gateways can now be configured to allow connections from clients only with a certain minimum version of code that is known to properly restrict split tunnelling.

 

[Evan]

NM,

When running VPN it is very common not to allow split tunneling, this is just when windows is running, i if you have a local LAN connection and try to make a WiFi connection to a second network, causes some people with PDA's no end of trouble, we have an admin option to disable.

I have never seen it before i don't think for just the OS. As far as i know its either somehow done using Std windows restrictions and a notification program or they have inserted something custom in the network stack !
(Did i mention it also notifys our securiy officer if you do try and connect 2 networks as well as disabling your PC until you remove one network)

Never got that curious to find out how they do is as i have it disabled on my notebook but maybe some windows expert knows how they do it.

Evan

 

[NM]

Back on topic for a change

Posted on Network World today is a story about Skype software collecting details from user's PCs.

Web bloggers and the general news media have been buzzing for the last couple of weeks about “private user data” being collected by Skype, fearing a breach of personal privacy. Specifically, Skype software was reportedly reading users’ personal computer BIOS data and motherboard serial numbers and reporting the information back to Skype servers.

Of course any software can do this, and most software licensing or end user agreements (that we just agree to and don't read) permits the vendor to do this. But my concern is that we may not know just what nasties may be added in the next or subsequent version of the software. Once the world is hooked, they could add almost anything they like to the code and we may never know.