How eQSO Works|
Posted Apr 29, 2003 - 12:03 AM
Email this to a friend Print this story
A guide to the inner workings of eQSO and voice over IP.
eQSO is a "voice-over IP" system - that is, voice delivered using the Internet Protocol.
In general, this means sending voice information in digital form in discrete packets rather than in the traditional circuit-committed protocols of the public switched telephone network (PSTN).
eQSO is a "client/server" implementation of this technology. Essentially, there is an eQSO server which we host on our bandwidth (its domain is eqso.446user.co.uk) and which "users" (meaning here either PMR446 RF Gateways or PC users) connect to from their computers via the internet.
Actually, we host two servers - a main server and a backup. We run a script which periodically calls the main server. If that script gets a response to the effect that "the main server is alive" then it keeps the status quo. If it gets no response, it alters the DNS entry for eqso.446user.co.uk to the IP address of the backup.
What this means in practice is if the main server goes down for any reason, the backup takes over service. Because the domain remains static, this process is invisible to users with the exception of a potential downtime of up to 5 minutes as the DNS server updates.
A System Status image is displayed in the top right hand corner of the front page of this website. If you're having trouble connecting to the server, this is the first place to look (there is also a Server Status Forum).
The eQSO software was developed by Paul M0ZPD and was intended specifically for use by Radio Amateurs, although he has directly given us permission to use it within the terms of its freeware licence for PMR446. RF gateways and PC users can be in different countries all over the World, and this makes it possible to talk to other users in other countries using a PMR446 radio through your local gateway (assuming you're within range). This has created a new dimension to PMR446 and we hope that will contribute to the continuing uptake of the service.
The following diagram shows how the system functions using the internet as its backbone.
Because of the nature of eQSO being a "client/server" application, rather than two gateways establishing a direct connection (peer to peer) every audio stream goes via our server as per the above diagram.
The system requires approximately 15kbs (kilo-bytes per second) per audio stream. As a user starts talking, either the gateway he is working through, or the PC Client he is connected through, sends an audio stream to the server. The server then relays by seperate streams the audio to each other client connected to the room.
That's makes a system like this bandwidth intensive (if there's 10 people in the room, that requires a constant bandwidth of 150kbs), and is the reason we ask people to contact us for a callsign issue before they connect a gateway. We need to be able to calculate how much bandwidth is likely to be required now and in the future.
It's the upstream bandwidth that does most of the work as only one user can talk at a time. So the talking user sends a 15kbs audio stream down to our server which then has to send 'x' number of 15 kbs streams upstream to the listening users and gateways, 'x' being the number of people connected to the server less one (the person talking).
Lack of bandwidth can contribute to what is sometimes (confusingly) called "packet loss" which materialises as gaps in the audio stream. In practice, although you may sometimes hear pauses in someones audio, you won't actually have lost any of their "over", those packets containing the audio data have simply got delayed in their journey over the internet and not lost. Packet 'delay' would actually be a more accurate description.
Packet delay is usually noticeable when the internet is busy at peak times (evenings often between about 7pm and 9pm in the UK for example) and usually only with users who are on dial-up modems.
99% of the time the audio coming from a broadband connected user will not get interupted, although it has been noticed from time to time when the internet is exceptionally busy (or we're shifting some large files around at the same time!).
Dean & TJ