SIP, Media, and NAT Traversal Features

Overview

General Features

Open Source	Source is available for public scrutiny.
High Performance	Thousands of calls can be processed per second on a typical Intel P4/2.4GHz desktop machine. More can be expected with proper server hardware and more or higher processor specs.
Small Footprint, Very Scalable	Scale down to low profile/embedded/small footprint SIP devices, or scale up to servers with mutlple processors using the same SIP stack source tree.
Portable	32bit, 64bit, big/little endian, realtime, any operating system, or even no operating system.
Extensive Documentation	There can never be enough documentation, so we try to provide readers with hundreds of pages worth of documentation (some are generated from the source, some are handwritten documents).

Target Platforms

Processor	Operating Systems	Status
alpha	Linux, gcc	Worked once
armv4	Linux/uC-Linux, gcc	Works
armv4	RTEMS, gcc	Supported, and reported to work
armv4	Symbian, gcc	Supported.
armv4	Microsoft Windows Mobile family, Embedded Visual C++ 4 for targets such as Windows CE (WinCE), PocketPC, and SmartPhone. Microsoft Visual Studio 2005 has also been reported to work.	Works (WMME sound)
armv5b	linux-2.6/XScale	Supported, and reported to work
Blackfin	uC-Linux, gcc	underway
i386	Linux, gcc	Works (OSS or ALSA sound)
i386	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.	Works (WMME or DirectSound sound backend)
i386	Mingw with gcc, via autoconf. Cygwin may compile with ./configure-legacy configuration.	Works (WMME sound backend)
i386	BSD/FreeBSD 6.1	Compiles and seems to work (sound disabled with --disable-sound)
i386	Linux kernel mode, gcc	Worked once.
ia64/Itanium II	Debian 3.1/GNU Linux 2.6.8, gcc-3.3.5	Works (media/audio untested)
ia64/Itanium II	BSD/FreeBSD 6.1, gcc-3.4.4, gmake	Compiles and seems to work (using null audio, media untested)
mips	Linux/uC-Linux, gcc, big-endian/little-endian	Works
powerpc	MacOS X 10.2 or later, gcc	Works (CoreAudio sound backend)
powerpc	RTEMS, gcc	Supported, and reported to work
powerpc	uC-Linux, gcc	Reported to work
sparc	SunOS/Sparc, gcc	Worked once
x86_64/AMD64	GNU Linux, gcc	Works (media/audio untested)
Other	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.
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.
C#	SipekSDK is an implementation by pjsip community member Sasa Coh.
Java	Several exists by community members, for example .
C++	There's C++ wrapper for PJLIB (pj++ library), but it's not maintained and probably will be removed in the future.

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:

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

Transports

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.

Transactions

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.

Dialog Core

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.

INVITE Session

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

Authentication

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

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

RFC 2327 (obsoleted by RFC 4566)

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 2543 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. RFC 2617

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

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

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

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

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

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

PJSIP supports IPv6 in SDP RFC 3310 RFC 4169

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

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

RFC 3420 - Internet Media Type message/sipfrag

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 RFC 4321

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

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

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

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

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.

RFC 5768: Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)

Support for ICE option tags was added in version 1.7

xpidf

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.

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).
• 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. 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. NAT Traversal (STUN and ICE)

A NAT traversal functionality for the media, supporting STUN, TURN, and ICE, is provided by PJNATH - NAT Traversal Helper Library Packet Lost Concealment (PLC)

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

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

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.

Media Features by RFCs

Below are the RFCs support for media related features:

RFC 2833

RFC 2833: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals

PJMEDIA supports the generation and parsing of RFC 2833/telephone-events payload in both RTP and SDP. RFC 3550/3551 (RFC 1889/1890)

RFC 3550: A Transport Protocol for Real-Time Applications

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

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 3611

RFC 3611: RTP Control Protocol Extended Reports (RTCP XR)

PJMEDIA implements several RTCP XR report blocks in RTCP XR module. RFC 3711

RFC 3711: The Secure Real-time Transport Protocol (SRTP)

PJMEDIA supports SRTP/SRTCP, please see SRTP Support in PJSIP page for more info. RFC 3951 RFC 3952

RFC 3951: Internet Low Bit Rate Codec (iLBC)

RFC 3952: Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech

Support for iLBC codec is implemented in PJMEDIA-CODEC library. In particular, the implementation correctly performs the negotiation of mode parameter in the SDP. RFC 4568

RFC 4568: Session Description Protocol (SDP) Security Descriptions for Media Streams

PJMEDIA/PJSIP supports SDESC as means for exchanging SRTP keys, please see SRTP Support in PJSIP page for more info. 5389

Session Traversal Utilities for NAT (STUN)

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

Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN)

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

Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer? Protocols

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

Planned Features

We maintain a list on our roadmap of known issues and wish list.

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

Other Features

Other features:

RFC 1035 RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. Asynchronous DNS resolver is implemented in PJLIB-UTIL. RFC 2782 RFC 2782:A DNS RR for specifying the location of services (DNS SRV).