Open Source | pjsip blog

Archive for the 'Open Source' Category

Recognizing open source community contribution: Champion of the Month Award

At PJSIP we always feel we don’t express our gratitude well enough for all of your contributions to this project, be it comments, criticisms, bug reports, patches, and so on. Especially some people deserves our special thanks for their extra efforts in helping others, or for their perseverance in solving problems (read: bugs) when the going gets though.

Bug of the Month January 2009 Award

This award goes to the most most difficult, most elusive, or perhaps even most silly bug that was found this month. And the award goes to ….

Bug #696

Bug #696. This had caused “RTCP clock skew detected” message to appear every now and then in the log and subsequently causing wrong RTT calculation.

What makes this bug a winner is that this has been so elusive that it had been living in the code for two and half years. We were aware of it but simply didn’t know how to fix it!

So our special thanks goes to Guido Fischer for solving this bug. You are smart. 🙂

Bug of the Year 2008 Award

The winner of Bug of The Year 2008 Award goes to …

Bug #660

Bug #660, INVITE request is not retried with authentication, even when correct credential is available, if the 401/407 response is received after a 100 or provisional response (!).

This bug really deserves a special award. It is so trivial, and yet it had been living with us for as long as I can remember, it had passed so many tests by us and interop tests with so many products by so many people, and it even slip though undetected in two SIPit events. It simply cannot be more silly than this!

So we thank Bug #660 for truly shaming us all.

Champion of The Month Award

Champion of The Month earns our recognition for achieving expertise, participating in community activities, and sharing their knowledge with other community members in the PJSIP mailing list. This month we would like to award this to ..

Gang Liu

Gang Liu, for being actively helping other list members in the past few months, as well as contributing several patches. You have demonstrated your expertise with PJSIP and we as well as I’m sure others have found your contributions to be very valuable. You deserve this award!

Integrating yaSSL with pjsip: anyone interested?

Published 19 January 2009 Open Source , pjsip , Porting 2 Comments

Recently we’ve been in contact with the yaSSL open source SSL project, discussing possibility of supporting CyaSSL as well as the current OpenSSL.

yaSSL is a small footprint and portable SSL implementation

The small footprint and portability of CyaSSL seems a very good match, so anyone interested in kickstarting this? I guess this can be from both ends, so maybe a yaSSL community member can try to see the TLS functionality in pjsip/pjmedia or from the pjsip side, looking into yaSSL stuff.

Let me know if you’re interested, and we can take it from there.

Presenting at CELF Embedded Linux Conference Europe 2008

Published 5 November 2008 Open Source , pjsip , VoIP Closed
Tags: CELF, Consumer Electronics, Embedded Linux

In the world of embedded Linux, one of the players is a group called Consumer Electronics Linux Forum (CELF). CELF was formed five years ago by the big manufacturers: Matsushita, Sony, Hitachi, NEC, Philips, Samsung, Sharp, and Toshiba.

One of the events they run is Embedded Linux Conference (ELC) series, which has been running the past three years and have two version, one in the US and one in Europe.

For the CELF ELC Europe 2008 we’re going to present a session on pjsip as an Open Source Compact SIP and Media Stack.

What’s the connection of pjsip to embedded Linux? Because pjsip is compact and lightweight it runs well in embedded Linux. We’re also going to talk about a recent case where Linux was used as the operating system for an IP Phone, and pjsip as the SIP stack, with pjmedia as the media stack.

Anyway, if you are anywhere near Ede, Netherlands on 6-7 November 2008, look us up!

UPDATE: The presentation is now available: pjsip: Open Source Compact SIP and Media Stack.

It’s Official: Mobile Goes Open Source

Published 23 October 2008 Mobile VoIP , Open Source , pjsip , Symbian 1 Comment
Tags: smartphone, Symbian Foundation

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

Analyzing the PJMEDIA Tone Generator Algorithms Performance

Published 22 September 2008 Open Source , pjmedia , VoIP Closed
Tags: CORDIS, tone generator

We have just finished some refactoring in the PJMEDIA tone generator, due to some problems identified by ticket 619. The main problem was the bad quality tone generated by the fixed-point sine generator algorithm, causing some failed detections by the remote end. While fixing this, we also addressed other problems such as noticeable thump noise at the beginning and the end of a tone, and difference in audio level produced by the fixed point compared to the floating point generator.

The results are these enhancements to the tone generator, implemented by ticket 619:

introduced a new fixed-point sine generator backend, based on the CORDIC algorithm. While this algorithm is generally slower than the existing fixed-point backend (although it is still faster than the floating-point algorithm on platforms that lack FP support), it does produce more precise output, and more importantly, the precision is tuneable so that application can balance between precision and speed.
made the backend algorithm selectable via compile time setting.
added fade-in and fade-out to the tone generation to eliminate/reduce the thump noise.

To verify these, we analyzed the performance (in terms of both speed and precision) of the various backends. To see the result, please see the Analyzing the PJMEDIA Tone Generator Algorithms Performance in our wiki page.

New low-complexity echo suppressor for mobile devices

Published 15 August 2008 Mobile VoIP , Open Source , pjmedia , smartphone , Symbian , Technology , VoIP 2 Comments
Tags: echo suppressor

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.

OpenSER project is dead: Welcome to Kamailio (and OpenSIPS)

Published 4 August 2008 Open Source , SIP Client 8 Comments
Tags: forking, Kamailio, OpenSER, OpenSIPS, SER

As an open source sip client library, pjsip needs to connect to a server (well, P2P SIP is of course a possibility, especially using NAT Traversal, but that’s a topic for another day).

OpenSER is one such server. A quick unscientific trawl through pjsip mailing list archives reveals more than 80 mentions of OpenSER. We’ve used it ourselves for testing purposes.

For the last week or so I’ve been hearing that OpenSER has been “renamed Kamailio”, according to the news at Kamailio website. That seems to be true, because I can see most of the site, logo, footer is still saying openser.org. And the website openser.org will redirect you to kamailio.org.

So, goodbye OpenSER, welcome Kamailio.

All finished? Not quite.

Welcome also to OpenSIPS (Open SIP Server), which is a “a continuation of the OpenSER project”.

Confused? Don’t be. This sometimes happen in an open source project. The same OpenSER code is taken by both Kamailio and OpenSIPS and from now on will take a life of its own. This is called a ‘fork’. In fact both projects will start with release 1.4.0 (with OpenSIPS releasing today, and Kamailio planning for later this week).

For completeness, I will mention that OpenSER itself is based on SIP Express Router (SER) project.

Is this bad? Depends. If for example you have 100 contributors to OpenSER, and assume it is an even split between OpenSIPS and Kamailio, then you will have ‘only’ 50 contributors each. By simple math it would seem each project is for the worse, because less contributors means less feature implementation, less testing, less everything in general.

But look further then in software projects it is often not the raw numbers that matters. If the 100 contributors rarely agree on anything, then the project is stalled anyway. By forking, then maybe each new segment will be more energised, and will release better software.

What about users? It does leave them in a bewildered state for a while. At the initial release, both projects are almost literally the same. Over time each project should take its own trajectory and we can then evaluate each on their merits.

Where does this leave pjsip as a SIP client framework? Well, as long as all the SIP servers adhere to published RFCs, and have commitment to follow the standards (which they all do), we’re fine. We should be able to connect to SER, ~~OpenSER~~ Kamailio, OpenSIPS, and others that may or may not come after these products/projects.

At the end of day, each open source project, including pjsip itself, lives and die by its adoption.

What do you think? Will you use Kamailio or OpenSIP or none of them? Let us know in the comments.

Python SIP Take Two (Part 1)

Published 24 July 2008 Open Source , pjsip , python , VoIP 6 Comments

Python is here again!

More than a year ago I wrote Python binding for PJSIP. It was alright, we can have some Python applications done using this wrapper. But, it’s not really having the impact that I expected. I’m talking about programming experience here and not popularity or things like that.

I mean, Python programming is supposed to be easy, and above all else, fun and enjoyable. But the wrapper is not doing that. I don’t know what it is, maybe it still smells too much like C, or maybe it’s the lack of documentation, or both, or something else. Bottom line I was not too impressed, so I’ve always thought about redoing it.

And now it’s done!

With the new module, we now do the absractions in two layers. The lower layer is the _pjsua C extension which exports PJSUA API to Python. This is similar to how the old Python extension was implemented. But now we also add a higher layer abstraction, object oriented, pure Python module on top of this. And that is the pjsua.py module.

The pjsua module provides high level API for constructing Session Initiation Protocol (SIP) multimedia user agent applications (a.k.a Voice over IP/VoIP softphones). It wraps together the signaling, media, and NAT traversal functionality into easy to use call control API, account management, buddy list management, presence, and instant messaging, along with multimedia features such as local conferencing, file streaming, local playback, and voice recording, and powerful NAT traversal techniques utilizing STUN, TURN, and ICE.

Hopefully it really is easier and more fun to use now.

Ready to go? We’ve also created more thorough documentation this time, start your development from this page: Python SIP Tutorial

And stay tuned for next parts of this post, we may have some interesting applications to publish (hints: I’m thinking about SIP client program for Nokia S60 platform, with PyS60. Wish me luck!).

Evaluating PJMEDIA Performance

Published 8 July 2008 Embedded , Open Source , performance , pjmedia , VoIP 3 Comments
Tags: CPU usage, MIPS, performance, WSOLA

Performance is one of the most common questions that developers asked. We’ve been asked questions like, can I run X on platform Y, or how much MIPS required to run component X, and so far our answer would be I don’t know, or at best, why don’t you try it yourself and see what happens.

So we decided to do a bit of benchmarking for pjmedia for several platforms that we have, and you can see the result here:

http://trac.pjsip.org/repos/wiki/PJMEDIA-MIPS.

The test covers various platforms, and sometimes the same H/W platform but different OS’es (Linux/gcc vs Windows/Visual Studio) to see how they fare, and of course various PJMEDIA components.

As the article says, there are some drawbacks about the test method used, but nevertheless I think it could be useful to see the rough CPU requirements of various PJMEDIA components. Certainly it has been useful to us, and in fact there have been some surprises with the results. For example, we expected that WSOLA (Waveform Similarity Overlap and Add, the algorithm that we use to conceal packet lost and to handle clock drifts) to take large chunks of CPU usage, but turns out it is quite fast. Also resampling with small filter looks to be quite affordable too.

We’ll look forward to measure the performance on more platforms (notably, Symbian), and we’ll keep track of the performance for future releases. In the meantime, enjoy the article.

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

Published 29 June 2008 Mobile VoIP , Open Source , pjmedia , pjnath , pjsip , Releases , smartphone , Symbian , VoIP 2 Comments
Tags: Audio Latency, ICE, RTCP XR, SRTP, TURN

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!

pjsip blog