SIP and Media Features

32bit, 64bit, big/little endian, any OS. 

Windows 95 family (win95/win98/winME)

WinNT family (WinNT/2000/XP/2003/Vista)

Development tools: MSVC 6, VS.NET 2003, VC Express 2005

Please see enabling Windows 95/98/ME support page about specific instructions on enabling Win95/Win98/ME support in the software.

Mingw with gcc, via autoconf.

Cygwin may compile with ./configure-legacy configuration.

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

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.

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

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

• Authorization, Call-ID, Content-Length, CSeq, Contact, Content-Type, Expires, From, Max-Forwards, Proxy-Authenticate, Proxy-Authorization, Record-Route, Route, Retry-After, Supported, To, Via, and WWW-Authenticate.

The following headers are recognized but not necessarily interpreted nor handled (the handling may be left to higher layer):

• Accept, Allow, Min-Expires, Proxy-Require, Require, Unsupported, Warning.

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:

• Accept-Encoding, Accept-Language, Alert-Info, Authentication-Info, Call-Info, Content-Disposition, Content-Encoding, Content-Language, Date, Error-Info, In-Reply-To, MIME-Version, Organization, Priority, Reply-To, Server, Subject, Timestamp, User-Agent.

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

In addition, application can create their own custom SIP headers when sending any requests/responses.

The core SIP stack provides transport layer and extensible transport management, with the following transports are provided:

• UDP
• TCP
• TLS

Upper layer libraries or applications may extend PJSIP with their own custom transport without having to recompile the library.

DNS SRV resolution is implemented in the library.

The SIP core stack fully implement SIP transaction and SIP transaction finite state machine (FSM), which handles:

• matching requests/responses to the appropriate transactions,
• retransmissions for non-reliable transport,
• fail-over to secondary transport destination (according to rules in RFC 3261) when the transport layer fails to deliver a message to current destination.

The SIP core stack (via the user agent layer) implements the core dialog management which will be used by upper layer functionality such as INVITE session and SIP event session (SUBSCRIBE/NOTIFY).

The core dialog framework supports multiple sessions (or dialog usages) in a single dialog, and also handles forked responses.

PJSIP provides high-level INVITE session management in pjsip-ua library, which:

• handles management of INVITE session state,
• handles SDP negotiation,
• utilizes the dialog core framework to enable multiple dialog usages in a single dialog,
• provides mechanism to plug-in SIP extensions related to INVITE session (such as PRACK, UPDATE, or session-timer).

The SIP core stack provides reusable component for performing client authentication and managing client authentication session.

RFC 2327/4566: SDP: Session Description Protocol

Most SDP features are supported by <pjmedia/sdp.h>.

In addition, PJMEDIA also has helper object to automate SDP negotiation process. See RFC 3264 section below.

RFC 2617: HTTP Authentication: Basic and Digest Access Authentication

HTTP digest authentication is supported, and more over, PJSIP has implemented framework to manage client and server authentication session in <pjsip/sip_auth.h>.

The client authentication can be used to authenticate against multiple challenges issued by multiple downstream proxies or servers, and supports multiple credentials for a single request.

RFC 2976: The SIP INFO Method

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.

RFC 3262: Reliability of Provisional Responses in Session Initiation Protocol (SIP)

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.

RFC 3263: Locating SIP Server

PJSIP supports asynchronous DNS SRV and A record resolution as specified in RFC 3263 and RFC 2782. Please see these links for details:

• High Level SIP Resolver
• PJLIB-UTIL DNS Asynchronous/Caching Resolver Engine

Currently PJSIP does not support DNS NAPTR records.

RFC 3264

RFC 4317

RFC 3264: An Offer/Answer Model with Session Description Protocol (SDP)

RFC 4317: Session Description Protocol (SDP) Offer/Answer Examples

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

Links:

• SDP Negotiator State Machine
• High Level SIP INVITE Session containing the SDP negotiator

RFC 3265: Session Initiation Protocol (SIP)-Specific Event Notification

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.

Please find detailed info on PJSIP Event Framework in PJSIP Developer's Guide PDF page.

RFC 3266: Support for IPv6 in Session Description Protocol (SDP)

PJSIP supports IPv6 in SDP

RFC 3310: Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)

RFC 4169: Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2

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.

RFC 3311: The Session Initiation Protocol (SIP) UPDATE Method

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.

RFC 3420 - Internet Media Type message/sipfrag

Support for message/sipfrag message payload is implemented in the call transfer module.

RFC 3428 - Session Initiation Protocol (SIP) Extension for Instant Messaging

Application can send/receive MESSAGE requests inside or outside dialog. The higher layer PJSUA-LIB provides high level API for sending MESSAGE (IM or typing indication) inside dialog or outside any dialogs.

RFC 3489: STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)

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.

Please find more info on STUN client library in PJLIB-UTIL STUN Client reference.

RFC 3515: The Session Initiation Protocol (SIP) Refer Method

PJSIP supports call transfer according to this specification and declares call transfer API in <pjsip-ua/xfer.h>. The PJSIP call transfer functionality uses PJSIP event framework to manage call status reporting via NOTIFY requests.

The PJSIP call transfer module extends PJSIP core and PJSIP-SIMPLE by supporting the following SIP components:

• REFER method to establish event subscription,
• Refer-To header.
• "noresource" event subscription termination reason.

RFC 3581: An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing

PJSIP always generates rport Via parameter for outgoing requests and correctly handles rport in incoming requests. This functionality is implemented in PJSIP transport layer (sip_transport.c).

RFC 3605: Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)

PJMEDIA by default generates RTCP attribute in outgoing SDP, and obeys the RTCP attribute in incoming SDP.

RFC 3608: Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration

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.

RFC 3856: A Presence Event Package for the Session Initiation Protocol (SIP)

PJSIP SIMPLE library (pjsip-simple) supports this RFC by implementing presence management API, which is declared in <pjsip-simple/presence.h>. The presence API uses PJSIP generic event subscription management framework which is declared in <pjsip-simple/evsub.h>.

The PJSIP presence implementation extends PJSIP by supporting the following SIP components:

• "application/pidf+xml" and "application/xpidf+xml" content type.
• "presence" event type in Allow-Events header.

RFC 3863: Presence Information Data Format (PIDF)

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

RFC 3891: The Session Initiation Protocol (SIP) "Replaces" Header

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.

For more information, see Replaces Support in PJSIP reference documentation.

RFC 3892 - The Session Initiation Protocol (SIP) Referred-By Mechanism

PJSIP has limited support for Referred-By header field. The PJSUA-API by default emits Referred-By header when it sends outgoing REFER request, and copies the Referred-By header onto outgoing INVITE request initiated from the REFER request.

The Referred-By header at the moment is treated and parsed as a generic string header.

RFC 3903: Session Initiation Protocol (SIP) Extension for Event State Publication

PJSIP SIMPLE library (pjsip-simple) has API to create, manage, and maintain generic event state publication. This API extends PJSIP by providing support for PUBLISH request.

The API for managing client state event publication is declared in <pjsip-simple/publish.h>.

In addition, PJSUA-LIB has a high level presence event publication, which hide the details of presence publication and presence subscription into a very high level API.

RFC 3966: The tel URI for Telephone Numbers

Tel URI parsing and generation is supported, and application may specify this in relevant SIP headers where appropriate. See <pjsip/sip_tel_uri.h> for details.

RFC 3994: Indication of Message Composition for Instant Messaging

PJSIP SIMPLE library (pjsip-simple) implements API to generate and parse "application/im-iscomposing+xml" content type as defined by this RFC. See <pjsip-simple/iscomposing.h> for details.

In addition, the higher layer PJSUA-LIB provides high level and very easy to use API for sending typing indication inside dialog or outside any dialogs.

RFC 4028: Session Timers in the Session Initiation Protocol (SIP)

Support for SIP Session Timers was added in release 1.4. Application can configure Session Timer on per invite session basis with PJSIP API, or per account basis with PJSUA-LIB API.

RFC 4320: Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction

RFC 4321: Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction

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.

RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)

PJSIP implements subset of RPID for specifying custom presence status text.

RFC 4488: Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription

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.

RFC 5057: Multiple Dialog Usages in the Session Initiation Protocol

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.

Please find detailed info on PJSIP dialog usage management in PJSIP Developer's Guide PDF page.

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.

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.

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).
• GSM.
• G.722
• G.722.1 and G.722.1C licensed from Polycom
• More codecs provided by Intel IPP: G.723.1, G.726, G.728, G.729A, AMR, and AMR-WB
• More codecs provided by Nokia APS/VAS on Nokia handsets: AMR, G.729, iLBC, and PCMU/PCMA
• L16 family of codecs, mono or stereo (good for debugging).

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.

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

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.

Playback of multiple WAV files in a playlist.

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.

A NAT traversal functionality for the media, supporting STUN, TURN, and ICE, is provided by PJNATH - NAT Traversal Helper Library

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.

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.

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

Secure RTP and RTCP (SRTP and SRTCP) is supported. Please see SRTP Support in PJSIP page for more info.

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

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.