Archive for the 'pjmedia' Category

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.

Securing VoIP: SRTP Support in PJSIP

PJSIP now has SRTP support in SVN trunk (hurray!). For more information about compatibility, how to use, and what have been done, please see the SRTP wiki in

We’ve tested it against couple of phones that support SRTP and it looks good (apart from SRTCP, which one phone doesn’t support and the other we don’t think it implements SRTCP correctly). If you have phones which support SRTP, it would be great if you could give it a try, I’ll be thrilled to hear your result.

Enjoy it while it’s hot!

You Can Now Make Phone Calls from Your iPod touch

It’s official. The folks at have ported pjsip and released a SIP client for iPod touch.

Breaking changes in source code repository due to IPv6

Dear all,Just want to inform (and give a bit of warning) that the SVN trunk is now “officially” incompatible with the last 0.8 release, due to major work to support IPv6.Unfortunately these changes will affect all applications that are based on the pjsip and pjmedia, regardless whether IPv6 is used. Potentially there shouldn’t be any changes to applications that are based on pjsua-lib.Most of the changes should be trivial though, related to changing pj_sockaddr_in structure, which is IPv4 specific, to pj_sockadr union in few places, and adding “af” (address family) argument to few pjlib functions to select the appropriate address family type.Here’s the declaration of pj_sockaddr union, just to illustrate what change should be required if pj_sockaddr_in is changed to pj_sockaddr:

typedef union pj_sockaddr
  pj_addr_hdr     addr;
  pj_sockaddr_in  ipv4;
  pj_sockaddr_in6 ipv6;
} pj_sockaddr;

Currently pjlib, pjsip, and pjmedia have been patched with IPv6 support.The DNS stuffs in pjlib-util and STUN/ICE stuffs in pjnath are next.

You can track the development of IPv6 support in:

[pjsip] Incompatible changes in SVN repository due to IPv6

Embedded RTP under µClinux on Nios2

I’m working on an application with PJMEDIA under uClinux on Nios2 environment. I have a stream audio with codec L16 48000 stereo and mono.This works good.

[pjsip] Resampling module add

It’s good to hear pjsip and pjmedia being ported on different embedded systems. The quote above relates to Nios II from Altera. Nowadays, running a media stacks such as RTP is very important for embedded processors such as Nios2.

If you have any other experience in using our protocol stacks on other embedded devices, please feel free to share it!

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

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.