Posts Tagged 'STUN'

PJNATH adds STUN, TURN, ICE to Asterisk for WebRTC support


We added STUN, TURN and ICE support by integrating an open source library called ‘pjnath’ from the PJSIP project.

Digium and WebRTC: An Interview With Steven Sokol :

New release 0.8.0: 3GPP/IMS, PRACK, and new STUN, TURN, and ICE implementation

This latest release was supposed to be 0.7.1 a few months ago. That release was delayed, so more and more features got in. Therefore we have decided to call it 0.8.0. If you are still using 0.5.x series, we urge you download pjsip and upgrade pjsip now.

Here are excerpts from the release notes:


PRACK (ticket #385) and UPDATE (ticket #5) have been implemented on this release, including all the quirks with the management of SDP offer and answer session when these SIP methods are involved.


Symbian support is getting more matured, with the implementation of Symbian sound device abstraction (ticket #2) and support for building the libraries as Dynamic Shared Object (DSO) files, which are needed for building developing for S60 3rd Edition using Code Warrior (ticket #354).

Updated STUN, TURN, and ICE

STUN, TURN, and ICE have been updated to the latest specification (ticket #374, #382). Many bugs have also been fixed.

Custom SIP Presence Status Text

While previously PJSIP only supports basic online/offline status, now PJSIP supports specifying and receiving custom presence status text by implementing subset of RPID (ticket #336)

More robust NAT handling

For SIP, keep-alive mechanism has been implemented for UDP transport at PJSUA-LIB level (ticket #407), and both TCP and TLS transports at the transport level (ticket #95). Because of these the default registration interval is now extended to 5 minutes. The client registration session will also keep the transport open until it is destroyed, so that server can send SIP requests using this transport (mandatory for TLS, and could be useful for TCP) (ticket #390).

For SIP UDP transport, pjsua-lib by default (pjsua_acc_config.auto_update_nat setting) will monitor the STUN mapped address as reported by registrar. When it detects that the mapped SIP transport address has changed, it will unregister previous Contact, create a new Contact based on the new transport address, and restart the registration. This would happen automatically without application assistance (ticket #381).

For media, ICE transport will automatically change its transport address based on the address returned in the STUN keep-alive packets (ticket #372). Also pjsua-lib will now reports to application via a callback when ICE negotiation has failed (ticket #370).

More Robust SIP authentication

PJSIP now supports responding to authentication challenge for any realms, by specifying wildcard (“*”) as the realm in the credential (ticket #231). Although some have commented about security implications of this, a lot of people will find this feature to be very useful.

Basic support for 3GPP/IMS

Ticket #396 adds support for 3GPP/IMS digest AKA authentication (AKAv1-MD5 and AKAv2-MD5). Ticket #400 adds support for Service-Route header processing.

Much improved audio latency on Windows

Audio latency on Windows (Win32) has been improved by several hundreds milliseconds. This should make the echo cancellation (AEC) works better too, so default EC tail length has been decreased from 800 ms to 200 ms.

Ticket #393 changed basic audio frame time, from 20 ms (hard coded as PTIME macro in pjsua_media.c) to 10 ms, and make this configurable. Default PortAudio sound driver backend was also made configurable, with the default is WMME (ticket #384). The default number of sound buffers (PJMEDIA_SOUND_BUFFER_COUNT) has been reduced from 16 to 6 (ticket #394). WMME audio latency buffering in PortAudio is now limited by 100 ms by default (ticket #395).

For more information, please see Audio latency question in PJSIP FAQ.

Milestone release-0.8.0 – PJSIP – Trac

Open source SIP stack, media, STUN, and ICE for Symbian OS

Just yesterday I finished back porting the Symbian branch to the trunk, and I think it’s good to go.

It’s been a roller-coaster way, supporting Symbian. It’s not the most developer friendly OS to port your programs to (see Readers Write about Symbian, OS X, and the iPhone), but we knew that, and I felt that this should make a good challenge for PJLIB, to see if it lives to its extreme portability claim. So we first started the port on May 2006, created a Symbian branch based on, and estimated that the work will need couple of months work. It wasn’t long before we realized we needed more time, and we revised the target to September 2006. But we still missed the target anyway.

Only about two months later, on Nov 2006, where we really had all of the libraries ported (only sound device is missing). But by this time, this branch was lagging waay behind the trunk, so it will take significant efforts (and commitments) to bring the port into the trunk.

But finally we had gathered enough “motivations” to do this, few days back, and it’s here.

Symbian target is officially supported in the trunk. All libraries have been ported. All seems to be running fine. No more panics. No memory leaks. All is good to go. Sound device is still missing, unfortunately.

So what do we have for the Symbian port again? For those new to PJSIP projects, here’s all of them:

  • pjlib, our platform abstraction hero.
  • pjlib-util, an auxiliary library containing parts needed by upper layer libraries (things like text scanning, XML, DNS SRV resolution, and various encryption algorithm),
  • pjnath, a NAT helper library containing the latest STUN, TURN, and ICE,
  • pjmedia, the media stack,
  • pjsip, pjsip-ua, pjsip-simple, libraries containing the bunch of SIP features,
  • pjsua-lib, a library combining SIP, media, and DNS SRV/STUN/ICE into high level API, and
  • symbian_ua, a simple console based SIP user agent for Symbian, based on pjsua-lib.

Some screenshot? Sure:

SIP User Agent on Symbian Emulator

Screenshot of symbian_ua on S60 Emulator

It’s been fun programming on Symbian. Learning curve has been steep. The tools are not perfect. But now I think I’m relatively more comfortable with it, and it becomes just another target for coding.

For more information about using the Symbian port, please see Porting PJ to Symbian OS. The porting effort itself is tracked on this Symbian-Porting Trac page.

Have fun yourself!

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!