Voice-over-IP on RISC OS: What's involved?

By Chris Williams. Published: 30th Oct 2005, 15:47:16 | Permalink | Printable

A client is possible once someone with the brains is talked into making it

With media outlets firefighting the outbreak of blogging and high street stores plotting revenge against online shops, the telecom giants thought they were safe from the Internet - some even providing the broadband and dialup connections that people use. Suddenly, however, a new technology has appeared on the radar and is threatening to torpedo the corporate strangle-hold of voice communications. Voice-over-IP allows people to chat to each other over the Internet using a microphone headset with a PC or a normal phone, and by 2010, half the UK population is expected to be using it.

Calls between VoIP users are usually free, whereas connections to external phone networks require payment as usual. The VoIP protocol works by breaking conversations up into packets of encoded data and sending them over the Internet, in the same sort of way your requests for web pages, email and other information are sent. By using this existing infrastructure, VoIP service providers can keep their costs down while providing standard features including caller display, voicemail and 1471. A number of service providers exist, the most famous being Skype.

So, on RISC OS?
At the moment, there are no VoIP clients nor any development work known to be underway for a new client. Skype uses a closed source protocol, which is a show stopper, although there are a number of open source libraries which provide VoIP functionality. The SIP Foundry is working on a number of libraries and components that could be used to make a VoIP client. These all make use of the SIP standard, which controls the flow of real-time communications. The GNU also have their own open source implementation too, and the H.323 standard is an alternative to SIP.

The audio data recorded live during conversation also needs sampling and compressing, and there are plenty of codecs available to do that - for example, G.711. This works by converting an audio stream into a digital representation at a rate of 64kbits/s. A RISC OS client would also need a way to capture audio from a microphone, and there are a number of ways to achieve this. The Iyonix's audio-in could be handy, although at the moment the software interface for this isn't flexible enough to provide a live stream. There is also the headache of maintaining real-time data streams on RISC OS, given its approach to multitasking, and having the processing power to recreate conversations - especially when packets inevitably arrive late or out of sequence. The VoIP client would, obviously, also have to decompress arriving audio data and output the sound. Developers we spoke to recently felt that a VoIP client is certainly possible, once someone finds the time to produce one.

Once all this is implemented and rolled into an application, the SIP capable client could then connect to and use any SIP compliant VoIP provider. Due to the amount of data shifted during a conversation, a broadband connection is mandatory. Consumer groups have also warned users of ISPs with 'download caps' to make sure they don't go over these limits with endless VoIP calls.

And in the meantime?
Several RISC OS users have found that plugging a phone into a VoIP capable broadband router and using a supported provider works well. RISC OS browsers, including Oregano 1 and the Firefox port, can be used to configure the kit. Vonage use SIP-compatible LinkSys routers to provide VoIP functionality, as illustrated here. A sticking point with VoIP is the issue of emergency services calls: On a normal copper telephone network, calls to 999 still work even when the electricity supply fails. VoIP users are out of luck in such situations, or if their computer hardware fails for whatever reason, although Vonage and other providers do offer a 999 service.

Gossiptel and Sipgate are also used by RISC OS users using extra equipment that provide VoIP functionality to normal phones, such as the Vigor2600V. There is a wide choice of providers and hardware in the absence of a native RISC OS client.

One user down under in Australia, Ross McGuinness, is considering using VoIP, and asked how a RISC OS client could be developed and funded. He said: "With the spread of broadband and the move away from standard copper telephone services this is the major change facing telephony.

"In my case the copper service is deteriorating and I'm awaiting a two way satellite service, shared over a radio network, with my neighbours. This service is supplied by one of the alternative telephone service operators who is also looking to expand their telephone customer base using VoIP on their broadband service. It is cheaper than building or possibly replacing a copper network in Australia's vast distances.

"With a copper cable damaged by several major lightning strikes and unlikely to be improved in the short term, if ever, I'm keen to see if VoIP can replace one of my land lines."

Links

More on VoIP

Previous: Users to represent RISC OS at Euro mega-show
Next: Taking OS features for granted

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

I would very much like to see VoIP on RISC OS. Apart from being useful in its own right, it's also one of those technologies that one will soon need on a computer to interact with others (a bit like instant messaging - you can live without it but you'll end up questioning why you can't do it while others can).

I see this as a market opportunity but also, as I implied above, as a defence of our platform against the need to run Windows/MacOS/whatever in parallel with RISC OS.

It's also something that needs to be done right. Elements of it need to be in an open framework for other RO applications to hook into (eg the ability of a database app to offer a 'call the phone number now' button). That, and the OS implications mentioned in the article, make me wonder if Castle or ROL need to do at least some of it. Or perhaps define the framework.

I do hope we don't end up with a repeat of the USB saga and have more than one standard.

Don't I recall Acorn showing a video-conference application at a show shortly before their demise?

TonyStill on 30/10/05 5:54PM
[ Reply | Permalink | Report ]

Tony Still: I do not think there are any OS implications, so I do not think ROL or Castle would need to get involved. If Chris' comment about RISC OS having problems with realtime data streams due to the way multitasking works was correct, then it would be unlikely that this could be changed anyway. Fortunately, I do not think that it is true. For instance, ShareFS happily serves clients in the background even while programs single-task.

wuerthne on 30/10/05 7:28PM
[ Reply | Permalink | Report ]

An excellent article and one that covers both the background and some of the things that need to be covered.

My day to day work revolves around Voip implementations and the biggest issue is making sure that you have a good Quality of Service (QOS) enabled infrastructure else you get distorted speech. Things like someone doing a large download and contention ratios on braodband will all play a part as more people try out Voip.

The main thing with closed standards like Skype and other implementations is that you get the free bit but only if you call within the same provider. The mistake that people also make is that Voip isn't free if you don't have ADSL or a PC. Granted that is less a problem now but broadband caps also come into play as stated.

I would like Voip for my Iyonix say as part of an application like Grapevine but I think we should have a common set of API's, even if it is at an application level, so we don't get a repeat of the USB situation. This hopefully could mean anyone could addon to a basic application.

Thanks for an informative article

bluenose on 30/10/05 7:55PM
[ Reply | Permalink | Report ]

Great discussion about VoIP fo RISC OS.

It was only a couple of weeks ago on the New Zealand RISC OS chat site I was asking how and what was needed to make Skype work on RISC OS.

I assumed it was just a software program issue, but here I can see there is much more than just a piece of software.

It looks encouraging to see if VoIP could be developed.

Steve Harrington

Sawadee on 31/10/05 3:03AM
[ Reply | Permalink | Report ]

wuerthne> ShareFS is not a real-time system; if the data arrives just 500ms late it doesn't matter. If audio data arrives late or isn't decompressed promptly then the distortion is very noticable and equally distracting.

For one-way playback of CD audio, MP3s and DVD, for example, the usual workaround is to have a large buffer and to slightly delay playback with respect to the incoming data. This, of course, is not a workable solution for a two-way conversation which requires low latency.

I believe that in the present RO multitasking environment and/or the presence of background activity such as ShareFS network traffic, a VoIP client will not perform well unless driven from a periodic IRQ with RO as it stands. For example, loading a multi-megabyte file into memory is sufficient to break up or halt audio that relies upon CallBacks.

adrianl on 31/10/05 5:30AM
[ Reply | Permalink | Report ]

Somebody mentioned Grapevine I would think that an application like that is one that needs to be expanded to include Voip as well as the usual MSN,Yahoo,Google etc video chats. However that opens up the can of worms that is video on RiscOS or rather the lack of it.

mripley on 31/10/05 8:30AM
[ Reply | Permalink | Report ]

adrianl: But audio doesn't have to relies on CallBacks. If you install a voice module you get an interrupt when the buffer needs to be filled. If you also have a module reading data from an internet socket under interrupt it could be done. Still a lot of work :-(

Peter V

Peter on 31/10/05 9:43AM
[ Reply | Permalink | Report ]

One of the big questions is - it it worth all the work when you can buy a VOIP router, and plug a regular phone straight in. I suppose if something like Skype were available, you'd have the free skype<->skype calls, but for general telephony, a VOIP router might still be the better bet. Is it necessarily worth major software investment for something that can already be done in hardware?

arawnsley on 31/10/05 10:09AM
[ Reply | Permalink | Report ]

Thanks to Chris for a clear and concise article on this matter. It is one that the RISC OS community needs to address sooner rather than later.

The two way satellite broadband I referred to is substantially funded by the Australian Commonwealth Govt to address issues of line quality in areas outside the major urban cantres. I can see that it will be the telephony service of the future as it will be cheaper than copper service once in place, and hopefully less prone to failure.

I for one would welcome the opportunity to support development of VoIP (recently mentioned as a possible development to Grapevine) via a Gimp Print/Firefox type scheme.

Once again thanks for the clarification of VoIP and RISC OS issues

rmac on 31/10/05 10:18AM
[ Reply | Permalink | Report ]

adrianl: I did not claim it would be easy. I was just refuting the point Chris has made: He claimed the problem was in the RISC OS approach to multitasking, which is not true. VOIP would not need to work on callbacks like ShareFS but ShareFS is a nice example to demonstrate that multitasking does not come into it at this level. Real-time data processing is difficult on any operating system and the interrupt latency of RISC OS is not too bad.

wuerthne on 31/10/05 10:45AM
[ Reply | Permalink | Report ]

My point is that some of the work must be done on callbacks with RO as it stands because you can't call the Internet module to read audio data from the IP stack in an IRQ handler.

Certain operations, such as loading a large file, or even lengthy graphics operations, cause the OS to spend a long time in SVC mode, preventing callbacks from occurring. The issue is not with IRQ latency, rather callback latency which cannot exceed 150ms, give or take, without affecting quality.

I think that's achievable - though as Martin says, probably not easy - for a singletasking client, but I also think it will break up badly when used in the desktop alongside other activities. Personally that's not a product I'd be prepared to build and sell.

You are, of course, free to prove me wrong.

And for the record, Chris is more or less quoting my opinion, so don't blame him

adrianl on 31/10/05 2:08PM
[ Reply | Permalink | Report ]

Couldn't it single-task? It would probably help to at least have that option for slower machines, anyway.

Loris on 31/10/05 2:11PM
[ Reply | Permalink | Report ]

Single task/multi-task ?

Are you really likely to load large files etc whilst on the phone - I don't.

demondb on 31/10/05 5:11PM
[ Reply | Permalink | Report ]

Personally, yes, because I would most likely be using VoIP to talk through and diagnose any problems encountered with my software, so I would be using the computer for other tasks at the same time.

Loading large files, though, was just an easy illustration; I'm quite sure that other situations when this problem would occur. One even more obvious illustration, with RO as it stands, is clicking on the icon of an empty CD-ROM drive whilst there's music playing.

adrianl on 31/10/05 5:42PM
[ Reply | Permalink | Report ]

Adrian, I don't think that reading audio data would be the worst problem. It's a two ways communication here, so you have also to capture and encode audio from your microphone.

Not only do you have you the problem of encoding audio from the sound card (always a heavier process than decoding) in realtime at the same time as decoding it from the received IP packets but audio capture suffer from the fact that RISC OS has no API for sound capture.

I don't now if sound capture cards are still available for the RPC but since IIRC both the Iyonix and the A9Home come with a microphone socket, it would be nice to have Castle and ROL to talk to each other for once and define a standard API.

andretim on 31/10/05 6:52PM
[ Reply | Permalink | Report ]

Would Gaim be a good candidate for porting? Apparently it is planned that version 2 will have sip support. (The Mac port Adium is superb.)

launch on 31/10/05 7:21PM
[ Reply | Permalink | Report ]

In reply to arawnsley:

I understand your reservations about possible sales. Personally, I would prefer a RO-based solution so would buy that in preference to a hardware/router solution. I admit that that is an irrational position but it's just what I would prefer.

A pledge scheme (as suggested by rmac) might be the answer to some of the doubts though I frankly doubt that the level of ineterst would match either GIMP print or Firefox.

I'd still like it though :-)

TonyStill on 31/10/05 9:34PM
[ Reply | Permalink | Report ]

Very interesting article. Thanks drobe

The GNU oSIP library mentioned in the article ([link]) compiles very easily on RISC OS and looks usable.

I know little about SIP, but imagine this is by far the easiest part of the process. Nonetheless it would be great if someone with some audio skills could take it further.

flypig on 31/10/05 9:51PM
[ Reply | Permalink | Report ]

Some points of interest, a bandwidth VoIP uses a lot if it, if you don't have fast broadband and unlimited then don't even think about it, note VoIP is starting to be removed by some phone companies, go to [link] as an alternative why not use voice recognition to change voice to text and a Speech Synthesis to speak the text.

runningman on 2/11/05 6:36PM
[ Reply | Permalink | Report ]

I bought a SIP phone for eighty quid which plugs straight into my router which already supports QoS. A great way to get free landlane calls to most of Europe and the US! I've very pleased with it, although Im finding sipgate's reliability is sometimes off for availability of my incoming number.

spellinn on 4/11/05 9:14AM
[ Reply | Permalink | Report ]

I've not seen any VOIP software so the question is; what facilities would a computer based solution offer over an above self contained dedicated hardware, which has a number of advantages such as QOS provisions, and the fact it already exists?

druck on 7/11/05 11:05AM
[ Reply | Permalink | Report ]

The x86 PC advantage is that you dont need a router - you can use a USB phone, or the built-in mic/headphones and a USB ADSL modem and you've got your VoIP phone.

Of course, we cant use USB ADSL modems, so as you need a hardware router (or PC acting as one) to get broadband on RISC OS, it removes this advantage.

Another advantage is that you can combine VoIP with video conferencing - which there is still very little dedicated hardware which does this (and its very expensive) , so your existing PC hardware makes an ideal platform.

Cheers.

spellinn on 7/11/05 11:59AM
[ Reply | Permalink | Report ]

On PCs many database applications offer a dial button next to telephone numbers.

JGZimmerle on 7/11/05 5:06PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

Internationalising RISC OS
Unicode, i18n and more explained

30 comments, latest by caliston2 on 16/7/03 8:57PM. Published: 10 Jul 2003

Random article

New Beeb Angband-like game in 32K
Where's my View ROM of Slaying +4?

Discuss this. Published: 18 Mar 2007

Useful links

News and media:
Iconbar • MyRISCOS • ArcSite • RISCOScode • ANS • C.S.A.Announce • Archive • Qercus • RiscWorld • Drag'n'Drop • GAG-News

Top developers:
RISCOS Ltd • RISC OS Open • MW Software • R-Comp • Advantage Six • VirtualAcorn

Dealers:
CJE Micros • APDL • Castle • a4 • X-Ample • Liquid Silicon • Webmonster

Usergroups:
WROCC • RONE • NKACC • IRUG • SASAUG • ROUGOL • RONWUG • MUG • WAUG • GAG • RISCOS.be

Useful:
RISCOS.org.uk • RISCOS.org • RISCOS.info • Filebase • Chris Why's Acorn/RISC OS collection • NetSurf

Non-RISC OS:
The Register • The Inquirer • Apple Insider • BBC News • Sky News • Google News • xkcd • diodesign