Archive for the 'Mobile VoIP' Category



It’s Official: Mobile Goes Open Source

Well, according to Symbian. I’ve been attending Smartphone Show 2008, because we have an open source Symbian SIP stack.

In the first two hours of the  I’ve been listening to Symbian itself, but also Motorola, Sony Ericcson, and Nokia.

I’ve lost count of how many times ‘open source’ is mentioned. Nigel Clifford, Symbian’s CEO, mentioned a figure of $300m in royalty revenues to be ‘given back’ to the ecosystem.

That’s a really clever way of putting it. He did admit some of them will be ‘pocketed’ instead of being used to ‘innovate’.

Which is another rather overused word during the whole show. One of the main argument for going open source is innovation over control.

Of course, one can always say Apple seemed to be able to out-innovate everyone in the mobile space, by having total and absolute control (Benoit Schillings, Qt CTO, alluded to a ‘dictator’ style of development).

So the strategy to beat Apple (and to a lesser extent Microsoft and Linux) is to club together in the Symbian Foundation, and using open source as the common denominator, a level playing field.

Number of devices already shipped, number of companies involved is frequently cited. It is hoped the ‘ecosystem’ will be large enough to eclipse (pun intended) other mobile platforms. The newly appointed Executive Director Lee Williams, also do not want to put a ‘30% tax’ on the ecosystem.

It worked in the software tools space with Eclipse, but a mobile platform is a different beast altogether.

You can read up other thoughts on this matter from Dean Bubley and Simon Judge. Incidentally I can answer Simon’s wondering about UIQ: It’s officially dead. Patrik Olsson, VP and Head of Software at Sony Ericsson, said ‘you can get ready for Symbian Foundation-based Sony Ericsson phones now by using S60’.

Version 1.0-rc1 is released with new Python SIP, Nokia APS support, and IPP codecs

“Good news, everyone” [Professor Hubert J. Farnsworth, Futurama]

This is an interim release, intended to mark the end of features development in the trunk. From now on, it will be tests and bug fixes only, until we reach 1.0. This will be our first proper stable release, and it will be given a separate branch, to isolate it from bleeding edge developments in the trunk.

Because of that, there has been a bit of “pressure” to stuff in as much features as possible on this release, since this is the last change to include them in 1.0. Here are some of them:

  • Integration of Intel® IPP Codecs.  This brings us with bunch of new codecs into PJMEDIA, such as G.722.1, G.723.1, G.726, G.728, G.729A, AMR NB, and AMR WB. Basically the lot! For more info about this integration, please see here.
  • New Python API. We discussed this on this blog a month ago here, basically it’s a new Python API for PJSUA-LIB, it’s much easier to use, and it also has a more thorough documentation/tutorial. Please check that out.
  • Nokia APS Support. The Nokia Audio Proxy Server is a wrapper to Nokia S60 sound device, it has much lower latency than Symbian MMF API (the traditional sound device that we support), and it also opens up support for device’s native codecs such as AMR, G.729, and iLBC which we can use in the future.  Although this API has been deprecated by Nokia in FP2, still there are lots of S60 and FP1 devices out there, so this is worth supporting.
  • New Echo Suppressor. Good for mobile devices, we discussed this in this blog here.

And some more. For more information regarding this release, please visit the download page.

Enjoy.

New low-complexity echo suppressor for mobile devices

As many have probably experienced it first hand, the echo suppressor (ES) in pjmedia sucks, to put it mildly. And this has made matters worse since ES plays such a major role in PDA’s and/or mobile devices/smartphones, since echoes are heavily present on these devices and we can’t really put the Accoustic Echo Canceller (AEC) on these devices due to the high processing requirements of the AEC (see our results in Evaluating PJMEDIA Performance article).

So we scrapped the old echo suppressor and wrote another one from scratch. And I think this one works quite well.

First of all, it’s low-complexity so it doesn’t require high processing requirements. We tested on a PocketPC 2003 PDA with 312MHz StrongARM CPU, it only uses less than 0.5% (half percent) of CPU. So it’s very affordable for these devices.

And most importantly, I think it works! It suppresses echo significantly, it lets non-echo audio pass through, and also it allows double-talk where both parties are talking at the same time. This is a very important to allow enjoyable conversation between two people, so we’ve made sure that the new echo suppressor supports this.

For those who care with the details, the ES works by comparing the audio level pattern in the input signal from the microphone with the audio level pattern in the playback signal during the learning process. It calculates the correlation values for each tail position up to the configured echo tail length, and finds out which tail position has the best correlation value. This position is then marked as the echo position. While doing this, the ES also notes the gain factors, that is how much de-amplification to be applied to the input signal in order to remove the echo from the input. Once the tail position is found, the ES then applies the appropriate gain factor according to the state of the conversation (e.g. I’m talking you’re silent, you’re silent I’m talking, we’re both talking, etc.).

This works pretty well. On the downside though, we noticed that the ES still seems to let a quiet echo to pass and transmitted back to remote party, depending on the signal level at the time. For now we allow this to happen since the echo level is very low and  doesn’t seem to be too annoying, and lacking enough experience with the new algorithm we don’t want to make it cut signals too aggressively yet since it may inadvertently cut the “good” signal.

The new echo suppressor is available in SVN as pjmedia/echo_suppress.c, and it will be included in the next release.

PJSIP 0.9 is Released: Audio Latency, TURN implementation, IPv6, G.722, and More

Finally, after months of delay, PJSIP version 0.9.0 is released. This has been the longest gap (8 months) between releases, and consequently it has the most modifications in it (there have been 100+ tickets done on this release).

Some of the new features in this release:

  • many improvements in the audio, to reduce audio latency, to have better compatibility with more target platforms (Windows Vista issues have been fixed, as well as sporadic error reports for ALSA), and to maintain the audio quality against impairments such as clock drifts, bursty sound device, and of course, packet loss. Compared to version 0.8, I think we’ve improved audio latency by few hundred milliseconds.
  • support for TURN-07 in PJNATH, either as standalone client/server library, standalone client/server application (for testing purposes), or integrated with ICE-19. Just as we were the first to release open source ICE library, I think this is also the first open source TURN implementation out there. Unfortunately we haven’t had time to update it to TURN-08 as this draft was released late during our QA phase, but we’ll update it as soon as possible.
  • fixed the ICE offer/answer rules.
  • support for IPv6.
  • support for Secure RTP (SRTP)
  • better support for Windows Mobile target. We have new and more usable sample application (PocketPJ) and GSM and Speex codec should now be available for this target.
  • better support for Symbian S60 target. There is a more thorough Symbian tutorial available, and GSM and Speex codec should now be available for this target too.
  • implementation of G.722 codec.
  • support for RTCP Extended Report (XR)
  • and many more.

For more information, start from PJSIP download page. Get it while it’s hot!

Doing it in Stereo

While PJMEDIA have supported stereo audio since day one, it had come with few limitations, for example this capability was not exported in PJSUA-LIB API, and once stereo mode is set, everything must be set to stereo too. These have been fixed in the latest SVN now. There is a new configuration field in pjsua_media_config to set the number of channels configuration for both the sound device and the conference bridge (the default is one of course), and more importantly, the conference bridge can now allow media ports with different channel count setting to be registered to it.

As an example of the new capability, application can instantiate both the sound device and the bridge in stereo. If the call is established with a stereo codec (for stereo we only have L16 codec for now), then transmission will be stereo, and if the call is established with the usual mono codec (G.711, G.722, Speex, etc. And oh yes, we do have G.722 now!), then the bridge will correctly perform the stereo – mono conversion, mixing the audio channels as necessary.

Having said all that, you may ask, why? Why bother with stereo at all?

You’re right, stereo is uncommon in VoIP. But nowadays SIP is used in broader industries than just VoIP. For example, the European Broadcasting Union (EBU) is currently looking to standardize Audio Contribution over IP (N/ACIP) which is based on standard based protocols such as SIP and RTP, and stereo encoding comes as one of the mandatory requirements. Also on different industry, we’re currently looking to integrate PJSIP as a VoIP platform in Virtual World games, in the open source VoIP for Virtual World project. This project is still in its very early stage, as it’s been published literally just couple of weeks ago. Here I guess stereo will play quite an important role, because of the positional audio requirement. And still there are more use cases for stereo, for example in SIP to radio gateways where people do want to transmit different audio in the left and right channel. The last use case probably is niche, but people do ask for that.

So in conclusion, stereo does have a use case. And I’m glad that we have a pretty smooth support for that.

And how can we enable stereo in the application? Well just set pjsua_media_config.channel_count to 2, and that’s just about it! More advanced scenarios are possible of course, but at least it’s very easy to get started with it.

PJSIP on Symbian Phone Works

[pjsip] PJSIP on Symbian Phone Works!:

This announcement is a bit late than planned (I promised to finish the Symbian port before Jan 2008), but we thought we’d give this a more thorough testing before announcing it, hence the delay.

In summary, PJSIP works and tested on Symbian S60 3rd Ed phone. Everything should work, including all SIP features, sound, STUN, and ICE. And we’ve made a tutorial on how to build and debug PJSIP on target device.

There have been some major changes along the way:

  • Carbide is now the preferred IDE rather than CodeWarrior. This is because CW has been deprecated by Nokia anyway.
  • Support for DSO is no longer enabled by default. It’s still supported, but you’d have to edit the MMP files slightly to build DSO outputs.

So what’s left to be done is for someone to create a nice open source Symbian softphone GUI on top of it. 😉

For more info:

Making VoIP on Nintendo DS a reality: new open source SIP client available

SvSIP, a new VoIP client for Nintendo DS is making quite a stir! To name a few, Tom Keating, Engadget and Gizmodo also picked it up.

Congratulations are certainly in order for Samuel Vinson, for porting pjsip to Nintendo DS. I am going to try it out myself, as soon as I reconfigure my wi-fi back to WEP. (Update: Here’s my post on using pjsip on Nintendo DS)

And instead of a screen-shot, I’m going to give you one better: a complete video guide! (video created by therealbiglou) It demonstrates how to set it up, with final thoughts: “sound quality is very good”. The negatives include “low speaker volume” and “hard interface to follow”.

We’ll work with Samuel to tweak the volume The volume can now be controlled through a configuration setting, and regarding the interface… yeah I guess dumping a log file on screen is a million miles away from an iPhone! Oops I mentioned the i-word, I’m sure people will think it’s there for keyword stuffing.

But seriously, some comments on digg already saying it’s an “iPhone killer”. What do you think?


Subscribe to blog updates

View Perry Ismangil's profile on LinkedIn

RSS PJSIP builds

  • An error has occurred; the feed is probably down. Try again later.