Posts Tagged 'SIP'



The Lazy Product Manager’s Way to Release VoIP Products

If you are a product manager wondering how to get into the VoIP market quickly before it moves to Telecom 6.0 or so, Jimmy Atkinson has helpfully provided a comprehensive list of 74 Open Source VoIP Apps & Resources. It’s all nicely categorized, with more than adequate descriptions.

You can just feel the raise you are going to get because it is just made it so easy to assemble and launch your product. Your boss will be amazed at your in-depth knowledge. Your development team will worship you as the Open Source God.

And yes, pjsip is listed as no. 31, by the way, in the category of SIP Protocol Stacks and Libraries. Actually to be a bit pedantic pjmedia should appear as well under RTP Protocol Stacks. And maybe pjnath, the new library for firewall traversal using ICE, listed under Development Stacks. But I digress. Go ahead, with 74 choices like that, is there any other reason NOT to go open source?

Introducing pjnath – Open Source ICE, STUN, and TURN for NAT Traversal

During the past few weeks, I’ve been busy with implementing ICE (Interactive Connectivity Establishment, with the latest draft as of now is draft-ietf-mmusic-ice-15.txt), and I think now at least I have something that’s quite usable and stable to use.

There’s Something about ICE..

For those who are new to ICE, ICE is probably the most comprehensive method for traversing NAT, for multimedia communications. It provides a method to find the best route to use by both endpoints, and it solves various problems with NAT, such as when both endpoints are behind the same NAT box and no hairpin is available, and when both endpoints are behind symmetric NATs (which in this case, a relay will be used). Please see draft-ietf-mmusic-ice-15.txt for more information.

It’s one heck of a protocol though! First of all, ICE doesn’t run on itself, and instead it uses STUN protocol (Session Traversal Utilities for NAT, with the latest draft is draft-ietf-behave-rfc3489bis-06) for doing the connectivity checks. And for relaying, it uses TURN (Obtaining Relay Addresses from Simple Traversal Underneath NAT, with the latest draft is draft-ietf-behave-turn-03). Combined, they amount to 103+61+44=208 worth of pages of protocol specification to follow! I guess that’s probably why the “Simple” word was removed from the STUN acronym. 😉

Anyway, I think the timing is good to support these protocols now. ICE has just got WGLC-ed (Work Group Last Call) a week ago, and STUN draft is also maturing (TURN is a bit farther behind). In fact, the timing is perfect, as we can also contribute to finding bugs in the specs before they got RFC-ed (this is not to say that we’re expert in any kind!). Had we implemented these sooner, we would have been caught with the changes in the protocol, as many projects seem to have found themselves with.

PJNATH – NAT Traversal Helper Library

So here they are, PJNATH – Open Source NAT Traversal Helper supporting STUN, TURN, and ICE (clicking the link will get you to the documentation).

PJNATH is a new library within PJ projects, along side PJLIB, PJSIP, PJMEDIA, etc., and it consists of these:

In the future, maybe we can also put other NAT traversal methods such as UPnP or SOCKS in this library as well.

To accommodate ICE, PJMEDIA and PJSUA libraries have been updated too:

  • In PJMEDIA, we have a new media transport called pjmedia_ice_transport,
  • In PJSUA-LIB, the STUN settings have been moved from transport setting to global settings, and added option to enable ICE in the media settings.

And pjsua, the SIP UA console application, has been updated too. To enable ICE media transport, just add –use-ice in the command line argument, and pjsua will negotiate ICE in the offer/answer (it will fallback to normal media transport if ICE is not available in remote agent, of course).

So Does It Work?

Yes! (or, erm.. I think so!)

I’ve tried with running two pjsua’s behind the same NAT that doesn’t do hairpin, and the local address pair is used. And trying two pjsua’s behind different NATs, the public address pair is used. So it looks like it’s working!

More over, I’ve been testing it since last week, and quite few bugs have been found and fixed. And negotiation is pretty quick, around 100 ms with two endpoints on different ADSL line, even though the SDP answer was delayed in the proxy (ICE is able to start the checks early even when SDP answer hasn’t been received by caller).

But one of the major difficulties with testing ICE these days is practically there is no other freely available ICE implementation out there (I mean, ICE-14/15 compliant ones), so although ICE implementation in PJNATH does seem to work, and it follows ICE-15 closely, we couldn’t be sure that it is compliant until it talks with other implementation. So if any of you know one, please do let me know!


Interested to try them out?

PJNATH is part of 0.6 release and is not available in the stable branch (0.5.10). And unfortunately we haven’t released tarball for 0.6 yet, so for now just grab yourself a SVN client and pull the source from the trunk!

How to start embedded SIP development on Blackfin uClinux

In the process of porting pjsip to Blackfin, you will need an appropriate embedded development board, software tools, and development host.

Embedded development board

  • There’s some choice of development boards, but for simplicity I suggest using the STAMP boards with its audio card.
  • You will need:
    • BF537-STAMP (available at Digi-Key)
    • AD1836A Audio Daughter Board (available at Digi-Key)
      • Again for simplicity, just order both the board and audio card from Digi-Key, even though technically you can contact your local distributor for Analog Devices. Certainly for people living in USA, it’s a no-brainer. I tried several places listed in the local distributor for UK, none have stock and certainly the audio card was hard to find. So I ordered from Digi-Key anyway, it was shipped within 24 hours. But I made the mistake of choosing Global Express Mail, it’s slooow and in the UK handled by ParcelForce. Enough said.
      • Be aware of customs, taxes, and the cost of collecting such taxes. For the UK, HMRC demanded about £55, and ParcelForce added £13.50 collection fee.
    • A straight-thru serial cable that ends in DB9 (9-pin) male. 180px-9_pin_d-sub_connector_male_closeup.jpg The other end depends on the serial port you have on your development host PC, usually you will need a 9-pin female plug. So look for a straight-thru (not null modem) 9-pin male to 9-pin female. In the UK I can recommend CableStar. Clear and fair pricing with fast delivery.
    • A network patch cable:
      • If you connect your Blackfin STAMP board directly to your development PC then you need a cross-over cable. Here’s one example on CableStar.
      • If you connect the board to a hub, then just a normal patch cable.

Software tools

  • All related embedded development tools can be downloaded from Blackfin Linux.
  • You will need:
    • A set of compilers, linkers called the Toolchain.
    • uClinux distribution
    • U-boot bootloader
  • I will detail the experience of setting up the development host with the tools above in another post.
  • Since I use Windows, I will also need coLinux as a host.

Development host

  • PC running Windows with coLinux. The docs/forum seems to suggest there is a Windows port of the tools, but the releases pages of the tools seems to be Linux only.
  • Available serial port. Modern PCs does not have this, so you may have to buy a USB-to-Serial adapter/dongle. Any make will do, I bought mine from eBay.
  • Available Ethernet LAN port if you want to connect the development board directly to your PC, which I recommend as it makes things a bit easier.

That’s all for now. In the next post I will connect them altogether, and hopefully have a running system.

Until then, if you have any suggestions or questions, just leave a comment!

Porting pjsip to embedded Linux on Blackfin DSP

Over the next few posts, I will do a walkthrough on porting pjsip to embedded Linux (specifically uClinux) on the Blackfin Digital Signal Processing (DSP) processors from Analog Devices. Along the way, I hope to give a few insight into programming embedded systems in general.

Blackfin (r) Logo

Why Blackfin Processors?

  • Popular. It can run uClinux as an embedded operating system.
    • uClinux â„¢ Logo
    • There is already the Linphone Blackfin port, so I know SIP and media works.
    • Recently Global IP Solutions (GIPS) has ported and optimized its VoiceEngine Embedded software to Blackfin processors as well.
  • Well documented. The Blackfin on uClinux site has tons of free software and documentation. Most importantly GCC toolchain (compiler, linkers, debuggers) is available and supported.
  • Somewhat exotic. Although probably not as exotic as pure DSP processors such as the TMS320 series from Texas Instruments, but still it is an embedded systems processor. In contrast processors based on x86 are more like small PCs, therefore expensive in terms of cost and power usage.
  • Affordable development board readily available. Relatively speaking, of course.
    • I was able to buy the BF537 STAMP and audio card for a total of £276 from Digi-Key, that includes shipping (to UK), customs, and taxes. I will detail what you need exactly in another post.
    • Here’s a tip if ordering from the UK: Don’t choose the Global Express Mail option. Although it saves about £20, it takes way too long (almost 2 weeks) and the ParcelForce handling here, well… can be improved.

Initial Approach

For this exercise, I have chosen Windows as my development machine. Although using Linux is more straight forward, I am using this porting effort as an excuse to try out new stuff like coLinux. Other than that , I will try to stick as much as possible to the suggested tools.

What next?

I will describe in more detail about getting the goods and preparing your development PC. After that we should be well on our way to start development.

If you have any thoughts on how this should be structured, or any other additional information you’d like to see covered, just leave a comment and I can try to fit it in.

PJSIP version 0.5.10 is released!

After some delay, finally PJSIP version 0.5.10 is released, and it contains new features such as Python language binding for pjsua-api, experimental TLS support, Visual Studio 2005 support, explicit SIP transport binding, and various other enhancements as well as tons of bug fixes.

Download it as usual from http://www.pjsip.org/download.htm.

Python SIP User Agent (Softphone)

Actually pjsip now supports Python abstraction for PJSUA-API, although there don’t seem to be a lot of interests for this (people seem to be more interested with ActiveX abstraction rather than Python abstraction 😀 ).

But why Python?

Well first and foremost, it’s for building a nice GUI!

If you’re looking for tools to build a portable GUI, actually Python fits the bill very well since it’s available on almost every platform (Win32, WinCE, MacOS X, Linux, Unices, and even Symbian, you name it), and many GUI toolkits are available for it (with my favorite being wxPython, although PythonCard also looks very interesting (too bad it doesn’t support sizer though)). And not to mention that the language itself is very powerful for creating this kind of application (read: to create something very quickly).

With the power of Python and the high level SIP and media API provided by PJSUA-API to do SIP calls, multiple accounts, presence, IM/instant messaging, buddy list management, conferencing, etc., this could potentially create a potent combination!

So watch this space, there could be a GUI coming out of pjsip.org soon! (or maybe not, just don’t hold your breath yet 😀 ).

Other reasons for creating Python abstraction for PJSUA-API:

  • it sounds ideal for creating scripting like programs, such as for testing purposes,
  • .. and I always want to learn Python. 🙂

So Python it is!

Mobile SIP service on Symbian gets $24.5m

Recently Vecosys mentioned social mobile network trends in 2007. The mobile trend continues as Truphone announces £12.5 million of venture capital funding. Truphone is creating quite a buzz, with a favorable mention on GigaOM. They got national UK TV coverage as a result.

So is this the start of a good year for the SIP industry, to offset Skype’s (non-SIP) dominance on the desktop? Or do you think Truphone is just another VoIP provider doomed to struggle for real revenue as some people have commented of Vonage or Skype?

I welcome your comments!

UPDATE: Om Malik thinks the investment is laced with a dash of irrationality.

You Cannot Live Without SIP and VoIP Technology in 2007

Anita Campbell picks 10 technology tools no small business owner should be without.

Among them is a Virtual Switchboard and a Smartphone. This is where SIP with media capabilities can help. With presence and VoIP capabilities, you can be located virtually anywhere there is a network connectivity

Oh, and actually if she got a smartphone, there is no need for an iPod Shuffle. I just picked up a 2GB miniSD card for about £20 (US$40 or so). Shove it in, twice the capacity!

So in place of an iPod, I would swap in a hosted CRM account, such as Zoho CRM, which is free for the first three user.

There you have it. If you have any more ideas, or disagree with any of the choices, please leave a comment!

P.S. For UK small businesses, swap Royal Mail for USPS. It can do pretty much the same, including the most useful of all the ability print your own stamps.

Why pjsip is better than other SIP SDKs, stacks, and implementations

One of the questions we get asked a lot is “How does pjsip compares to other SIP implementations?” This would include reSIProcate, Sofia-SIP, OpenSIPStack among others. We have a few more on our links section. Apparently a few other people have also attempted to do comparison of open source SIP implementations, such as Martin van den Berg [PDF file]

The short answer is: We don’t know. Sorry.

The not-so-short answer is: It depends (otherwise known as the software engineer’s cop-out).

We could point out pjsip’s very small footprint, but if it’s going to be deployed on a multi-core system with gigabytes of space, “who cares.”

Or what about the availability of pjmedia, giving a top-to-bottom solution without integration headaches? “Don’t need it, our platform does them all in hardware, thank you very much.”

Or the fact that the same pjsip API can run from the smallest and most barren of platforms (sockets? what are those?) to the aforementioned oodles of RAM multi-core PC with an OS the size of a house. “We’ll pass on that… our solution only requires one end of that long stretch!”

So we can’t really say how pjsip compares, because there will always be different requirements for each application project. As it happens, selecting components for your next killer application is still an inexact art science. Lots of trial and error, and sometimes you just have to close your eyes, take a deep breath and jump in.