Other people have ported PJSIP to various platforms, including Nintendo DS, iPod Touch, and Texas Instruments DSP.

Note: some PJMEDIA features may not be available or suitable for some
platforms (for example, because of lacks of floating point support).

Language Bindings

C

All libraries are written in C.

C++

There's C++ wrapper for PJLIB (pj++ library), but it's not
maintained and probably will be removed in the future.

Python

The Python binding for PJSUA-LIB has been implemented in 0.5.10 release. The documentation for Python is integrated in PJSUA-API Documentation.

ActiveX

This would open possibility to write SIP User Agents in Visual Basic (VB) or C# .NET. Once we had an experimental ActiveX component for pjsua-lib, but the development has been cancelled. Please see the projects page for open source project that wraps PJSIP as .NET component.

(If you'd like to download the old code, get the revision 492 of pjproject trunk. The ActiveX source code is in pjsip-apps/src/activex-pjsua directory).

Session Initiation Protocol (SIP) Features

Core Session Initiation Protocol (SIP) Features (RFC 3261)

Classification

The core SIP stack (pjsip-core) complies with basic and intermedia feature
classification according to SIPIT UA classification, with the following exception:

redirections are handled by application code (not the stack).

no HTTP basic authentication (deprecated).

Most advanced features are supported by upper layer libraries (or
adjunct libraries such as PJMEDIA) or by applications.

SIP Methods

The core SIP stack has framework to support INVITE, ACK, BYE,
CANCEL, REGISTER, and OPTIONS.

Upper layer libraries will define more methods to support specific SIP
extension. See next section for details.

In addition, application can define their own SIP methods during run-time
without needing to recompile the stack (so probably this means support for INFO
as well).

SIP Headers

The core stack correctly generates, parses, interprets, and
handles the following headers:

The following headers are parsed according to generic header classes (for
example, as generic integer, generic string, generic array of strings, etc.)
and are not interpreted or handled by the core stack. Application can still
generate or handle these headers:

SIP/SDP Features by RFCs

The table below attemps to describe some SIP features/extensions that PJSIP
supports.

But even if the extension is not mentioned in the table, PJSIP
should/may be able to support it since application can always insert/modify any
SIP headers or generate any SIP methods at any stage, and have access to all
message elements in incoming messages.

In general, I only mention the SIP extension in the list when
there's really something useful that PJSIP specificly do to support
it (rather than just the ability to generate/parse some headers).

Although the core library was designed to support this older SIP
specification, this was rarely tested because most SIP software are RFC 3261
compliant anyway. In general, it's not well supported/tested.

SIP does not define specific handling
for INFO, so since PJSIP can generate/handle arbitrary SIP methods, support for
INFO is implicitly there in PJSIP. Application can send/receive INFO inside or
outside dialog context.

Reliable provisional support (100rel and PRACK) is supported since late September 2007 (see ticket 385 for the implementation notes). This support includes the management of offer/answer session related to the use of PRACK request.

SDP offer/answer negotiation is performed automatically by the stack. This
functionality is implemented by negotiator session API as declared by
<pjmedia/sdp_neg.h>, and is embedded in SIP INVITE session
management (pjsip-ua/sip_inv.h).

With the negotiator helps, applications need not to worry about all those SDP
negotiation quirks, and can just receive the final, negotiated SDP to create
the media. Having said that, the negotiator is still flexible enough to be used
to implement applications such as Back to Back User Agents (B2BUA) or
those Session Border Controllers (SBC).

Several (mostly the tricky ones) offer/answer examples in the RFCs were copied
into the negotiator compliance test program
(pjmedia/src/test/sdp_neg_test.c).

SIP event is fully supported, and PJSIP has generic event framework to
manage event subscriptions (client or server side). See
<pjsip-simple/evsub.h> for details. This framework is currently used by
presence and call transfer module.

The PJSIP event framework adds the following supports to PJSIP core:

SUBSCRIBE and NOTIFY methods,

Allow-Events, Event, and Subscription-State headers along with all relevant
parameters are handled automatically by the framework.

Support for HTTP digest AKA version 1 and 2 (AKAv1-MD5 and AKAv2-MD5) for SIP authentication against 3GPP/IMS servers has been implemented in version 0.7.1. Please see PJSIP Digest AKAv1 and AKAv2 Authentication API for more information.

PJSIP fully supports generation and handling of UPDATE request inside invite session, for both early and confirmed dialog (see ticket #5 for the implementation notes). This support includes the management of offer/answer session related to the use of UPDATE request.

PJLIB-UTIL has support to handle subset of STUN transactions, enough to
implement a typical STUN client. The higher layer PJSUA-LIB provides easy to
use API to create SIP or RTP/RTCP media transports with the addresses/ports
resolved through STUN.

Service-Route header processing is done at PJSUA-LIB level. Upon receiving successful REGISTER response, PJSUA-LIB will check the presence of Service-Route header and update the route set for the specified account.

PJSIP SIMPLE library (pjsip-simple)
implements API to generate and parse "application/pidf+xml"
content type as defined by this RFC. The low-level parsing/generation API is
declared in <pjsip-simple/pidf.h>, but application should use the high
level presence management API as declared by <pjsip-simple/presence.h>.

PJSIP UA library (pjsip-ua) implements API to verify incoming INVITE request with Replaces header. Application can use this building block to implement features such as Attended Call Transfer, Call Pickup, etc.

This has been considered in the design, and the stack never tries to be clever and send any responses (provisional or final) on its own. The only exception is 400 (Bad Request) and 481 (Call/Transaction Does Not Exist) responses, which the stack may send when it receives malfunction requests or when it cannot find matching transaction/dialog for incoming request.

Support for "norefersub" is implemented in PJSUA-LIB. Application may
send REFER request with "Refer-Sub: false" header, and incoming REFER with
"Refer-Sub: false" will be obeyed. The "norefersub" tag also is registered
correctly in Supported header.

The core PJSIP dialog (pjsip/sip_dialog.h) has been designed to support dialog
usages, and indeed PJSIP can support multiple usages for single dialog. The
PJSIP high layer INVITE session management <pjsip-ua/sip_inv.h> and PJSIP
event subscription management <pjsip-simple/evsub.h> are implemented as
dialog usages on top of dialog core, thus can reside in a single dialog if
necessary.

draft-rosenberg-impp-pidf-00.txt: A Data Format for
Presence Using XML

PJSIP also supports the old (and deprecated) version of presence data format
(known as "application/xpidf+xml") since this format is still
used by some user agents.

Planned Features

Features that are planned (or not planned) to be supported in the future:

Anything else

Not enough demands/encouragements, or they're just simply too
difficult to implement.

Any feedbacks/hints regarding what features are "hot" and should be
prioritized would be greatly appreciated.

Media Features

Media Features

Any Clock Rate, Any Channels

PJMEDIA components work with any clock rate/sampling rate, where applicable
(i.e. not limited to mere 8KHz narrowband quality).

PJMEDIA supports stereo audio encoding (or even n-channels) all the way
throughout the library, where applicable.

Adaptive Jitter Buffer

An effective jitter buffer implementation with configurable
prefetch settings, which can also be adapted to operate in fixed jitter
mode. The jitter buffer provides sufficient status to trigger Packet
Lost Concealment (PLC) invocation.

Adaptive Silence Detector

Can utilize both VAD feature that provided by codec
(such as Speex's encoder VAD) or PJMEDIA's own adaptive silence detection
implementation for codecs that don't have silence detection (such as G.711,
GSM, or iLBC).

Codecs

PJMEDIA supports:

G.711 family codec (PCMA, PCMU),

Speex/8000 (narrowband), Speex/16000 (wideband), and Speex/32000
(ultra-wideband) with fix bit rate and adjustable quality/complexity settings.
Fixed mode implementation will be used for targets which lack floating point
unit.

iLBC in 20 or 30ms mode, with encoder mode is adjusted based on
remote's SDP (decoder mode is adjustable during initialization only).

The list of codecs are not exhaustive as more codecs will be supported in the
future. All codecs except G.711 are packaged in pjmedia-codec static
library, and the build process should only link the specific codecs that
application explicitly wants (to minimize footprint).

The codec framework recognizes the following features in the codec, and allows
application to override the settings on per call basis:

Voice Activity Detector (VAD),

Comfort Noise Generator (CNG),

Perceptual Enhancement (PENH),

Packet Lost Concealment (PLC).

Applications also can register their own (probably proprietary)
codecs into the framework during run-time.

Conference Bridge

PJMEDIA has powerful conference bridge implementation, with the following
features:

can efficiently/happily hold conference with more than a hundred participants
on Intel P4 systems, with still loads of CPU to spare (note: only PCM
codec is used during the test).

supports participants with different clock rate

supports participants with different frame size/ptime.

supports stereo or even n-channels (note: channel settings must be uniform for
all participants).

DSP Friendly

Media flow is by default driven by the sound card (the behavior
can be changed by application designer). From experience, this is the ideal
design for DSP types of hardware, since media flow is ideally driven by data
capture interrupt (which should be most time accurate).

Echo Cancellation (AEC)

Front-end API/implementation for Speex Acoustic Echo Canceller (AEC) or simple but effective echo suppressor for targets with low processing capability (such as PDAs, smartphones, etc.). The backend algorithm is selectable during both compile-time and run-time.

File Playback and Recording with WAV Files

Playback and recording PCM samples from/to WAV files are supported, and samples will be correctly converted to host endianness.

PJMEDIA also supports playback and recording to memory buffers, for devices without filesystems.

File Playlist

Playback of multiple WAV files in a playlist.

Media Port Framework

PJMEDIA provides extensibility by means of media ports, which is an adaptation
of component based filter (as found for example in DirectShow SDK and
GStreamer) to better suit telephony domain (although of course PJMEDIA is by no
means limited to work only in telephony domain). The adaptation was mainly
designed to better support integration of telephony cards into the framework.

Application designers can create and arrange media ports interconnection to
include specific PJMEDIA features needed to process the media flow.

PJMEDIA can utilize PLC that comes with the codec (e.g. Speex, iLBC) or
its own PLC implementation for codecs that don't have built in PLC (such as
G.711 or GSM).

For targets that has low processing capability, a simple PLC based on frame
replay algorithm can be selected.

Resampling

High quality resampling based from resample-1.8.tar.gz and adapted to
handle frame based resampling. Quality can be tuned to processing
performance availability.

RFC 2833

PJMEDIA supports the generation and parsing of RFC
2833/telephone-events payload in both RTP and SDP.

RTP

The RTP implementation is tiny in
footprint (just a tad bit over 1KB), and is designed only to provide
packetization and parsing only (because sometimes we don't want to transmit RTP
with socket, but rather pass it to another processor (e.g. host processor).
Again, DSP friendly. ;-) ).

RTCP

.. and Media Quality Analysis

PJMEDIA not only generates and parses RTCP packets, but it provides good media
analysis and statistics to both local application and remote peer (via RTCP),
for the following stat:

total packets and bytes,

jitter (min/avg/max),

lost/loss, reordered, duplicate packets,

round-trip delay (min/avg/max).

The media statistic has been tested extensively (including against commercial
high profile testing hardware) and proven to be very accurate (as accurate as
the operating system allows).

Portable sound device abstraction with support for low-delay DirectSound
audio on Win32, or PortAudio for other platforms (Unix, MacOS X, etc.). Support
for OSS and ALSA is available via PortAudio for Linux target.

The sound device abstraction is easy to implement and is suitable for DSP
implementation (with interrupt driven style callback).

Stream

Stream abstraction for managing remote media communication. The stream
integrates codec, jitter buffer, RFC 2833 events, and RTP/RTCP (de)framing and
statistics into an integrated session, and can be created
from SDP negotiation results.

Stream does not directly manage UDP sockets, but instead it communicates to
external endpoints via media transports. This would make the stream processing
independent of the underlying transport.

Tone Generator

Inband tone generation, with some of the features:

can generate single sinusoidal/sine wave or dual
frequency tones,

fixed point or floating point,

can enqueue multiple tones/DTMF digits with single
API call,

configurable on/off duration and volume for
each individual tones/DTMF digits,

programmable digit-map, with default digit mapping
set to DTMF frequencies.

Transport for Media

Application may use their custom transport for transporting
RTP/RTCP packets, or instead just use PJMEDIA's built-in transport.

RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control

PJMEDIA has a highly portable RTP/RTCP implementation which is decoupled from the network/socket operations, making it modular and ideal for supporting any transports.

In addition, PJMEDIA utilizes RTCP to send and retrieve media quality feedback and can display detailed statistical report about stream quality, such as jitter, packet loss/reordered/late, RTT, etc., with the time calculated in sub-milisecond precision.