RISC OS VoIP client emerges - RISC OS News, Software and Information

RISC OS VoIP client emerges

Published: 7th Oct 2007, 00:48:49GMT Source: drobe.co.uk
By the Drobe news desk

Page 1 of 1

Turn your Iyonix into a dog and bone

A prototype VoIP client allowing users to make phone calls over the Internet will be unveiled next week. Device driver developer Dave Higton says he's ready to demonstrate a partially-complete RISC OS client that can call a PC running open source VoIP package Ekiga. His software, written in BASIC V on his Iyonix, is not ready to receive incoming calls.

VoIP, or Voice-over-IP, breaks conversations up into packets of compressed data and sends them over a network, such as the Internet, allowing conversations to be held in real-time by two or more computer users. Crucially, a VoIP call is usually free, although payment is often required when connecting to a normal landline number.

A VoIP client requires two key components: one to manage and direct incoming and outgoing calls, and another to turn chat audio into data and vice-versa. Dave's software uses SIP for controlling connections and RTP for sending and receiving a conversation's audio. By using standard protocols, his program will be compatible with various VoIP packages available on other computer platforms.

Dave, best known for his USB hamster wheel and ROFS work, said he is prepared to make his client available if he can get it up to scratch.

He said: "If it works well enough, it's definitely something I would release.

"It's a standard SIP client, compatible with any other SIP client. At least, it will be when I've written and debugged more of the SIP interpreter.

"At the moment it's a technology demonstrator, but it can make a call to Ekiga on a computer on the same network. It can't receive calls yet; again, that's just extending the SIP interpreter. Audio is transported via standard RTP, and that very definitely works in both directions."

Dave also found a simple headset with microphone did the job and no other equipment is needed with his Iyonix. The audio-in is connected to the microphone and audio-out to the headphones.

He added: "The Iyonix doesn't require any external audio IO device or preamplifier, or anything like that; just a headset with microphone. I was surprised when I tried it.

"Subject to using the Iyonix's sound input system correctly, and subject to using a capacitor microphone, which is the most common type anyway, there is sufficient gain from the microphone to hold a normal conversation."

• Dave will show off his VoIP work to members of the Southampton Acorn users group on Tuesday October 9. The presentation will run from 7pm to 9pm at the Itchen College, Middle Road, Bitterne, in room S1. Entry is free.

Links
Previous coverage of VoIP on RISC OS

This article has been linked to, or is available in the following formats:

[Printable] [Digg this] [Blog search]

stevek (+1.0) 7/10/07 5:12AM	Fantastic! A good VoIP client is going to make many people happy.
JGZimmerle (+1.0) 7/10/07 8:20AM	Yes, I would happily pay a few dozen bucks for a good one with support.
bluenose (+2.0) 7/10/07 8:59AM	Fantastic news, well done to Dave. I agree with the comments about paying for a supported one. Now if it can be integrated into Grapevine/Parmesan then even better as I think MSN uses SIP. Doug
jess (+2.0) 7/10/07 9:27AM	SIP support wasn't anything I was expecting to see on RISC OS, brilliant news. It would be interesting to know what codecs it supports. (presumably they aren't written in BASIC). (SIP also supports video conferencing and instant messaging). *In reply to bluenose:* It would be good to integrate to Parmesan just to have a unified message program with a nice UI, any MSN voice would be a bonus.
davehigton (+3.0) 7/10/07 11:01AM	*In reply to jess:* Currently it only supports mu-law, which is 64 kb/s but is very widely supported. To support A-law in addition would not be much effort - but again it's 64 kb/s. I don't want to even think about compression until the thing can both make and receive calls, register with a SIP proxy, and use STUN to get through a firewall. Video: currently no chance.
em2ac 7/10/07 12:16PM	*In reply to davehigton:* Thanks! I am very interested in this! sadly without an iyonix (yet) MSN and VoIP in the same year....whats happening to the RISC OS scene? :@P Thanks again!
jess (+2.0) 7/10/07 1:40PM	davehighton: Thanks for the clarification. Have you actually written the codecs from scratch? (If you need any testers, I have a working VOIP system and iyonix)
davehigton (+3.5) 7/10/07 2:18PM	*In reply to jess:* (Check spelling of my name) Yes, the codec is from scratch. Fortunately, I was an audio engineer for some years, and I now work for a company that records telephone calls. Tapping digital lines is my speciality. If I ever get to implement any of the compressing codecs, they probably won't be from scratch, though. I'm just sad for users of earlier RISC OS computers, as they don't have audio input and therefore won't be able to use this client. I have no idea whether the A9 will be able to use it. I imagine that some modification to my audio input code would be needed.
AW (+1.0) 7/10/07 2:40PM	How do you make payment when you call a landline? Also, I take it this would be too slow for anything less than an Iyonix?
jess (+1.0) 7/10/07 3:06PM	*In reply to davehigton:* Presumably the Mico and Riscstation aren't powerful enough, because they both have audio in. Could you make it able to use espeak with an input window as an alternative input source for anyone with no microphone?
jess (+1.0) 7/10/07 3:09PM	*In reply to aw:* You normally buy pay as you go credit from your SIP account provider. www.draytel.org is one such provider
davehigton (+1.0) 7/10/07 5:21PM	In reply to jess (09:27): The mu-law encoder is BASIC at the moment. The mu-law decoder is assembly language - it's easy. In reply to AW: Presumably the exact arrangements for paid calls vary from provider to provider. I've been with sipgate for a while now, and I've only ever used it to call other sipgate numbers, so it's been free. Sipgate (and others, I believe) will allocate conventional telephone numbers; I have a 023 number with them. If I chose to make calls to land lines, then I believe it's similar to PAYG mobiles: you buy credit in advance. In reply to jess (15:06): I have no idea how to do audio input on the Mico or Riscstatiion. I'm not about to buy one to try. I might well buy an A9 if they get RISC OS running properly on it. (Flame war elsewhere please!) It may be possible to use espeak, I don't know, but I can't imagine I would want to do that.
jess (+1.0) 7/10/07 5:50PM	*In reply to davehigton:* Presumably there's no standard API for audio in? Would the 7500 be to low powered anyway? As I understand it, SIP/Simple is an instant message add on to SIP, presumable that would be possible for most RISC OS machines. eSpeak would be a bit horrid, but as a fallback, would be better than no communication.
davehigton (+1.0) 7/10/07 10:01PM	*In reply to jess:* You're right, there is no standard API for audio in, at least as far as I'm aware. It would be helpful to have it across all versions of RISC OS.
jess (+1.0) 7/10/07 10:15PM	*In reply to davehigton:* I would guess that you would be the right person in the right position to define (the start of) one. Would it 'just' be a case of making whatever your program does internally into APIs?
davehigton (+1.0) 8/10/07 10:29PM	*In reply to jess:* No and yes, in that order.
jess (+1.0) 9/10/07 10:36AM	*In reply to davehigton:* With your experience in audio, I'd be very surprised if whatever you chose to do inside the program wasn't a good starting point for an API. It would also mean that any programmer with a different machine could implement the API and you wouldn't have to have every potentially suitable machine. Is it a major job "putting it on the outside"?
davehigton (+1.0) 9/10/07 3:41PM	*In reply to jess:* Experience in audio (and in DSP) qualifies me to understand codecs, especially the simple ones. Devising an API is an entirely different proposition, and requires experience that I don't have - experience of the audio systems of the various RISC OS platforms, and of their drivers. There are other RISC OS hobbyist programmers better qualified than me in that area. I also happened to see something on the RISCOS Ltd site a couple of days ago to the effect that work on a standardised audio API had been abandoned because the systems out there are too different.
jess (+1.0) 9/10/07 8:16PM	*In reply to davehigton:* Sorry, I didn't mean to come over as though I expected you to provide a whole API and drivers etc. What I was getting at is, you obviously know what information your program needs to get from the sound system and how it wants it presented. If it is staight forward to do this as an API rather than internally, this could be the start of a standardised API. (ie your program would be in the form of an Iyonix sound driver that did just* what you want and the main program, rather than all in one.) If other programmers want to use it then they could extend it if needed, if not, at least it would mean your software would be more portable to other RISC OS systems (someone else could write the drivers*).
Christian (+1.0) 11/10/07 12:59PM	The audio input API used is the device driver I designed for the Iyonix. It uses DeviceFS so it's tremendously simple for applications to use. I've now released the source for this driver and its example application driver, along with the specification of the API at http://sudden.recoil.org/others/ - if anyone writes an audio input driver for other machines using this interface then the VoIP client would be able to work with them.
jess (+1.0) 11/10/07 10:07PM	*In reply to christian:* So the situation is several apis exist. (it sounded more like he had to talk at a lower level to the sound system). So what I asked for would be happening naturally anyway. The only difference would be whether the program supported more than one api (a bad idea I think) or a conversion module were written for other machines so they use the same api. Thus making a common api.
davehigton 12/10/07 7:38AM	*In reply to Christian:* Thanks! Also thanks for your help on the AudioIn module recently. In reply to Christian and jess: I was thinking in terms of a unified API for audio in /and/ out. (Currently I'm having more problems with audio out than in.) I still don't think I'm qualified to define a unified RISC OS sound API. Remember, RISCOS Ltd decided it was impossible.
davehigton (+1.0) 12/10/07 7:45AM	More news: the demo on Tuesday at SAUG completely failed. I took a Linux box with Ekiga for the other end. What I hadn't expected was that Ekiga utterly failed to work once it was not connected to the gateway (and possibly the Internet), so, although the Iyonix was sending the INVITE (and I could catch this on the Linux box with Wireshark), Ekiga wasn't listening. A particularly forceful case of The Demo Effect. I've begun adding the code to get my app to accept incoming calls as well as make outgoing ones.
jess (+1.0) 12/10/07 9:53AM	divehigton: Ah I thought you meant unified as in, same sound in api across different machines. I didn't think in terms of sound out, because I would assume sharedsound to be the logical choice. (The fable of blind men describing an elephant from different samples, springs to mind). Is that impossible as in can't get data off a FAT memory stick bigger than 2GB on RISC OS? I notice the odds of my RISC OS system giving problems goes up several hundred fold if I'm demonstrating it.