[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 ????

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]

Originally Posted by wandering_fred

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

Originally Posted by wandering_fred

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.

Originally Posted by wandering_fred

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.

Originally Posted by wandering_fred

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]

Originally Posted by 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 ?

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

[NM]

Originally Posted by 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

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]

Originally Posted by NM

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]

Originally Posted by Evan

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

Originally Posted by Network World

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.