Changes between Initial Version and Version 1 of SIP-Media-NAT-Traversal-Features

Timestamp:

Jun 10, 2010 8:42:30 AM (14 years ago)

Author:

ismangil

Comment:

Initial port

SIP-Media-NAT-Traversal-Features

@@ +1 @@
+= SIP, Media, and NAT Traversal Features =
+
+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, any OS. 
+Extensive Documentation         There can never be enough documentation, so we try to provide readers with hundreds of pages worth of documentations (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    As of May 2007, all have been ported except sound device.
+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.
+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:
+
+    * 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.
+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.
+
+ 
+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).
+    * 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.
+draft-ietf-behave-rfc3489bis-15         
+
+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
+draft-ietf-behave-turn-07       
+
+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
+draft-ietf-mmusic-ice-19.txt    
+
+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
+
+ 
+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).