16 files changed, 2421 insertions, 0 deletions

diff --git a/pjnath/docs/UML-class-diagram.dia b/pjnath/docs/UML-class-diagram.dia
new file mode 100644
index 0000000..4e54231
--- /dev/null
+++ b/pjnath/docs/UML-class-diagram.dia
diff --git a/pjnath/docs/UML-class-diagram.png b/pjnath/docs/UML-class-diagram.png
new file mode 100644
index 0000000..d3c08e9
--- /dev/null
+++ b/pjnath/docs/UML-class-diagram.png
diff --git a/pjnath/docs/doc_ice.h b/pjnath/docs/doc_ice.h
new file mode 100644
index 0000000..6be7ecb
--- /dev/null
+++ b/pjnath/docs/doc_ice.h
@@ -0,0 +1,107 @@
+/* $Id: doc_ice.h 3553 2011-05-05 06:14:19Z nanang $ */
+/* 
+ * Copyright (C) 2008-2011 Teluu Inc. (http://www.teluu.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA 
+ */
+
+/**
+@defgroup PJNATH_ICE ICE: Interactive Connectivity Establishment
+@brief Interactive Connectivity Establishment (ICE)
+@ingroup PJNATH
+*/
+
+/**
+@defgroup PJNATH_ICE_STREAM_TRANSPORT ICE stream transport
+@brief Transport for media streams using ICE
+@ingroup PJNATH_ICE
+ */
+
+/**
+@defgroup PJNATH_ICE_SESSION ICE Session
+@brief Transport Independent ICE Session
+@ingroup PJNATH_ICE
+ */
+
+/**
+@addtogroup PJNATH_ICE
+\section org Library organizations
+
+See <b>Table of Contents</b> below.
+
+\section ice_intro_sec Introduction to ICE
+
+Interactive Connectivity Establishment (ICE) is the ultimate 
+weapon a client can have in its NAT traversal solution arsenals, 
+as it promises that if there is indeed one path for two clients 
+to communicate, then ICE will find this path. And if there are 
+more than one paths which the clients can communicate, ICE will 
+use the best/most efficient one.
+
+ICE works by combining several protocols (such as STUN and TURN) 
+altogether and offering several candidate paths for the communication,
+thereby maximising the chance of success, but at the same time also 
+has the capability to prioritize the candidates, so that the more 
+expensive alternative (namely relay) will only be used as the last
+resort when else fails. ICE negotiation process involves several 
+stages:
+
+ - candidate gathering, where the client finds out all the possible 
+   addresses that it can use for the communication. It may find 
+   three types of candidates: host candidate to represent its 
+   physical NICs, server reflexive candidate for the address that 
+   has been resolved from STUN, and relay candidate for the address 
+   that the client has allocated from a TURN relay.
+ - prioritizing these candidates. Typically the relay candidate will
+   have the lowest priority to use since it's the most expensive.
+ - encoding these candidates, sending it to remote peer, and 
+   negotiating it with offer-answer.
+ - pairing the candidates, where it pairs every local candidates 
+   with every remote candidates that it receives from the remote peer.
+ - checking the connectivity for each candidate pairs.
+ - concluding the result. Since every possible path combinations are 
+   checked, if there is a path to communicate ICE will find it.
+
+
+\section icestrans_sec Using ICE transport
+
+The \ref PJNATH_ICE_STREAM_TRANSPORT is a ready to use object which
+performs the above ICE operations as well as provides application with
+interface to send and receive data using the negotiated path.
+
+Please see \ref PJNATH_ICE_STREAM_TRANSPORT on how to use this object.
+
+
+\section ice_owntransport_sec Creating custom ICE transport
+
+If the \ref PJNATH_ICE_STREAM_TRANSPORT is not suitable for use 
+for some reason, you will need to implement your own ICE transport,
+by combining the \ref PJNATH_ICE_SESSION with your own means to
+send and receive packets. The \ref PJNATH_ICE_STREAM_TRANSPORT 
+provides the best example on how to do this.
+
+
+\section ice_samples_sec Samples
+
+The \ref ice_demo_sample sample demonstrates how to use 
+\ref PJNATH_ICE_STREAM_TRANSPORT <b>without</b> using signaling 
+protocol such as <b>SIP</b>. It provides  interactive user interface
+to create and manage the ICE sessions as well as to exchange SDP 
+with another ice_demo instance.
+
+Also see <b>\ref samples_page</b> for other samples.
+ */
+
+
diff --git a/pjnath/docs/doc_mainpage.h b/pjnath/docs/doc_mainpage.h
new file mode 100644
index 0000000..58f27da
--- /dev/null
+++ b/pjnath/docs/doc_mainpage.h
@@ -0,0 +1,148 @@
+/* $Id: doc_mainpage.h 3553 2011-05-05 06:14:19Z nanang $ */
+/* 
+ * Copyright (C) 2008-2011 Teluu Inc. (http://www.teluu.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA 
+ */
+
+
+/**
+
+@mainpage PJNATH - Open Source ICE, STUN, and TURN Library
+
+PJNATH (PJSIP NAT Helper) is an open source library providing NAT traversal 
+functionalities by using standard based protocols such as STUN, TURN, and ICE.
+
+
+\section background Background
+
+
+Network Address Translation (NAT) is commonly deployed everywhere primarily to
+alleviate the exhaustion of IPv4 address space by allowing multiple hosts to 
+share a public/Internet address. While NAT would work well for typical client 
+server communications (such as web and email), since it's always the client 
+that initiates the conversation and normally client doesn't need to maintain
+the connection for a long time, installation of NAT would cause major problem
+for peer-to-peer communication, such as (and especially) VoIP. 
+
+<strong>\ref nat_intro "Read more.."</strong>
+
+
+\section intro Introduction to PJNATH
+
+PJSIP NAT Helper (PJNATH) is a library which contains the implementation of 
+standard based NAT traversal solutions. PJNATH can be used as a stand-alone 
+library for your software, or you may use PJSUA-LIB library, a very high level
+ library integrating PJSIP, PJMEDIA, and PJNATH into simple to use APIs.
+
+PJNATH has the following features:
+
+ - <strong>STUNbis</strong> implementation,\n
+   providing both ready to use 
+   STUN-aware socket and framework to implement higher level STUN based 
+   protocols such as TURN and ICE. The implementation complies to 
+   <A HREF="http://www.ietf.org/rfc/rfc5389.txt">RFC 5389</A>
+   standard.\n\n
+
+ - <strong>NAT type detection</strong>, \n
+   performs detection of the NAT type in front of the endpoint, according
+   to <A HREF="http://www.ietf.org/rfc/rfc3489.txt">RFC 3489</A>. 
+   While the practice to detect the NAT type to assist NAT 
+   traversal has been deprecated in favor of ICE, the information may still
+   be useful for troubleshooting purposes, hence the utility is provided.\n\n
+
+ - <strong>Traversal Using Relays around NAT (TURN)</strong> implementation.\n
+   TURN is a protocol for relaying communications by means of using relay, 
+   and combined with ICE it provides efficient last effort alternative for 
+   the communication path. The TURN implementation in PJNATH complies to 
+   <A HREF="http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-14.txt">
+   draft-ietf-behave-turn-14</A> draft.\n\n
+
+ - <strong>Interactive Connectivity Establishmen (ICE)</strong> implementation.\n
+   ICE is a protocol for discovering communication path(s) between two 
+   endpoints. The implementation in PJNATH complies to
+   <A HREF="http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-19.txt">
+   draft-ietf-mmusic-ice-19.txt</A> draft
+
+In the future, more protocols will be implemented (such as UPnP IGD, and 
+SOCKS5).
+
+
+\section pjnath_organization_sec Library Organization
+
+The library provides the following main component groups:
+
+ - \ref PJNATH_STUN\n\n
+ - \ref PJNATH_TURN\n\n
+ - \ref PJNATH_ICE\n\n
+ - \ref PJNATH_NAT_DETECT\n\n
+
+Apart from the \ref PJNATH_NAT_DETECT, each component group are further 
+divided into two functionalities:
+
+ - <b>Transport objects</b>\n
+   The transport objects (such as STUN transport, TURN transport, and ICE
+   stream transport) are the implementation of the session object
+   <strong>with</strong> particular transport/sockets. They are provided
+   as ready to use objects for applications.\n\n
+
+ - <b>Transport independent/session layer</b>\n
+   The session objects (such as STUN session, TURN session, and ICE session)
+   are the core object for maintaining the protocol session, and it is
+   independent of transport (i.e. it does not "own" a socket). This way
+   developers can reuse these session objects for any kind of transports,
+   such as UDP, TCP, or TLS, with or without using PJLIB socket API.
+   The session objects provide function and callback to send and receive
+   packets respectively.
+
+For more information about each component groups, please click the component
+link above.
+
+
+\section pjnath_start_sec Getting Started with PJNATH
+
+\subsection dependency Library Dependencies
+
+The PJNATH library depends (and only depends) on PJLIB and PJLIB-UTIL
+libraries. All these libraries should have been packaged together with
+the main PJSIP distribution. You can download the PJSIP distribution
+from <A HREF="http://www.pjsip.org">PJSIP website</A>
+
+
+\subsection pjnath_using_sec Using the libraries
+
+Please click on the appropriate component under \ref pjnath_organization_sec
+section above, which will take you to the documentation on how to use the 
+component.
+
+
+\subsection samples_sec Samples
+
+We attempt to provide simple samples to use each functionality of the PJNATH
+library.
+
+Please see <b>\ref samples_page</b> page for the list of samples.
+
+
+*/
+
+
+
+/**
+@defgroup samples_page PJNATH Samples and screenshots
+@brief Sample applications and screenshots
+ */
+
+
diff --git a/pjnath/docs/doc_nat.h b/pjnath/docs/doc_nat.h
new file mode 100644
index 0000000..1fdda7a
--- /dev/null
+++ b/pjnath/docs/doc_nat.h
@@ -0,0 +1,415 @@
+/* $Id: doc_nat.h 3553 2011-05-05 06:14:19Z nanang $ */
+/* 
+ * Copyright (C) 2008-2011 Teluu Inc. (http://www.teluu.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA 
+ */
+
+
+/**
+
+@defgroup nat_intro Introduction to Network Address Translation (NAT) and NAT Traversal
+@brief This page describes NAT and the problems caused by it and the solutions
+
+
+
+\section into Introduction to NAT
+
+
+NAT (Network Address Translation) is a mechanism where a device performs 
+modifications to the TCP/IP address/port number of a packet and maps the 
+IP address from one realm to another (usually from private IP address to 
+public IP address and vice versa). This works by the NAT device allocating
+a temporary port number on the public side of the NAT upon forwarding 
+outbound packet from the internal host towards the Internet, maintaining
+this mapping for some predefined time, and forwarding the inbound packets
+received from the Internet on this public port back to the internal host.
+
+
+NAT devices are installed primarily to alleviate the exhaustion of IPv4 
+address space by allowing multiple hosts to share a public/Internet address.
+Also due to its mapping nature (i.e. a mapping can only be created by 
+a transmission from an internal host), NAT device is preferred to be 
+installed even when IPv4 address exhaustion is not a problem (for example
+when there is only one host at home), to provide some sort of security/shield
+for the internal hosts against threats from the Internet.
+
+
+Despite the fact that NAT provides some shields for the internal network,
+one must distinguish NAT solution from firewall solution. NAT is not 
+a firewall solution. A firewall is a security solution designed to enforce
+the security policy of an organization, while NAT is a connectivity solution
+to allow multiple hosts to use a single public IP address. Understandably
+both functionalities are difficult to separate at times, since many 
+(typically consumer) products claims to do both with the same device and
+simply label the device a “NAT box”. But we do want to make this distinction
+rather clear, as PJNATH is a NAT traversal helper and not a firewall bypass
+solution (yet).
+
+
+
+\section problems The NAT traversal problems
+
+
+While NAT would work well for typical client server communications (such as
+web and email), since it's always the client that initiates the conversation
+and normally client doesn't need to maintain the connection for a long time,
+installation of NAT would cause major problem for peer-to-peer communication,
+such as (and especially) VoIP. These problems will be explained in more detail
+below.
+
+
+\subsection peer_addr Peer address problem
+
+
+In VoIP, normally we want the media (audio, and video) to flow directly
+between the clients, since relaying is costly (both in terms of bandwidth
+cost for service provider, and additional latency introduced by relaying).
+To do this, each client informs its media transport address to the other
+client , by sending it via the VoIP signaling path, and the other side would
+send its media to this transport address.
+
+
+And there lies the problem. If the client software is not NAT aware, then
+it would send its private IP address to the other client, and the other
+client would not be able to send media to this address.
+
+
+Traditionally this was solved by using STUN. With this mechanism, the client
+first finds out its public IP address/port by querying a STUN server, then
+send sthis public address instead of its private address to the other 
+client. When both sides are using this mechanism, they can then send media 
+packets to these addresses, thereby creating a mapping in the NAT (also 
+called opening a "hole", hence this mechanism is also popularly called 
+"hole punching") and both can then communicate with each other.
+
+
+But this mechanism does not work in all cases, as will be explained below.
+
+
+
+\subsection hairpin Hairpinning behavior
+
+
+Hairpin is a behavior where a NAT device forwards packets from a host in
+internal network (lets call it host A) back to some other host (host B) in
+the same internal network, when it detects that the (public IP address)
+destination of the packet is actually a mapped IP address that was created
+for the internal host (host B). This is a desirable behavior of a NAT, 
+but unfortunately not all NAT devices support this.
+
+
+Lacking this behavior, two (internal) hosts behind the same NAT will not
+be able to communicate with each other if they exchange their public
+addresses (resolved by STUN above) to each other.
+
+
+
+\subsection symmetric Symmetric behavior
+
+
+NAT devices don't behave uniformly and people have been trying to classify
+their behavior into different classes. Traditionally NAT devices are
+classified into Full Cone, Restricted Cone, Port Restricted Cone, and 
+Symmetric types, according to <A HREF="http://www.ietf.org/rfc/rfc3489.txt">RFC 3489</A>
+section 5. A more recent method of classification, as explained by 
+<A HREF="http://www.ietf.org/rfc/rfc4787.txt">RFC 4787</A>, divides 
+the NAT behavioral types into two attributes: the mapping behavior 
+attribute and the filtering behavior attribute. Each attribute can be 
+one of three types: <i>Endpoint-Independent</i>, <i>Address-Dependent</i>,
+or <i>Address and Port-Dependent</i>. With this new classification method,
+a Symmetric NAT actually is an Address and Port-Dependent mapping NAT.
+
+
+Among these types, the Symmetric type is the hardest one to work with. 
+The problem is because the NAT allocates different mapping (of the same
+internal host) for the communication to the STUN server and the 
+communication to the other (external) hosts, so the IP address/port that
+is informed by one host to the other is meaningless for the recipient 
+since this is not the actual IP address/port mapping that the NAT device 
+creates. The result is when the recipient host tries to send a packet to 
+this address, the NAT device would drop the packet since it does not 
+recognize the sender of the packet as the "authorized" hosts to send 
+to this address.
+
+
+There are two solutions for this. The first, we could make the client 
+smarter by switching transmission of the media to the source address of 
+the media packets. This would work since normally clients uses a well 
+known trick called symmetric RTP, where they use one socket for both 
+transmitting and receiving RTP/media packets. We also use this 
+mechanism in PJMEDIA media transport. But this solution only works 
+if a client behind a symmetric NAT is not communicating with other 
+client behind either symmetric NAT or port-restricted NAT.
+
+
+The second solution is to use media relay, but as have been mentioned 
+above, relaying is costly, both in terms of bandwidth cost for service
+provider and additional latency introduced by relaying.
+
+
+
+\subsection binding_timeout Binding timeout
+
+When a NAT device creates a binding (a public-private IP address 
+mapping), it will associate a timer with it. The timer is used to 
+destroy the binding once there is no activity/traffic associated with 
+the binding. Because of this, a NAT aware application that wishes to 
+keep the binding open must periodically send outbound packets, 
+a mechanism known as keep-alive, or otherwise it will ultimately 
+loose the binding and unable to receive incoming packets from Internet.
+
+
+\section solutions The NAT traversal solutions
+
+
+\subsection stun Old STUN (RFC 3489)
+
+The original STUN (Simple Traversal of User Datagram Protocol (UDP) 
+Through Network Address Translators (NATs)) as defined by 
+<A HREF="http://www.ietf.org/rfc/rfc3489.txt">RFC 3489</A>
+(published in 2003, but the work was started as early as 2001) was 
+meant to be a standalone, standard-based solution for the NAT 
+connectivity problems above. It is equipped with NAT type detection 
+algoritm and methods to hole-punch the NAT in order to let traffic 
+to get through and has been proven to be quite successful in 
+traversing many types of NATs, hence it has gained a lot of popularity
+ as a simple and effective NAT traversal solution.
+
+But since then the smart people at IETF has realized that STUN alone 
+is not going to be enough. Besides its nature that STUN solution cannot 
+solve the symmetric-to-symmetric or port-restricted connection, 
+people have also discovered that NAT behavior can change for different 
+traffic (or for the same traffic overtime) hence it was concluded that 
+NAT type detection could produce unreliable results hence one should not 
+rely too much on it.
+
+Because of this, STUN has since moved its efforts to different strategy. 
+Instead of attempting to provide a standalone solution, it's now providing 
+a part solution and framework to build other (STUN based) protocols 
+on top of it, such as TURN and ICE.
+
+
+\subsection stunbis STUN/STUNbis (RFC 5389)
+
+The Session Traversal Utilities for NAT (STUN) is the further development 
+of the old STUN. While it still provides a mechanism for a client to 
+query its public/mapped address to a STUN server, it has deprecated 
+the use of NAT type detection, and now it serves as a framework to build 
+other protocols on top of it (such as TURN and ICE).
+
+
+\subsection midcom_turn Old TURN (draft-rosenberg-midcom-turn)
+
+Traversal Using Relay NAT (TURN), a standard-based effort started as early
+as in November 2001, was meant to be the complementary method for the 
+(old) STUN to complete the solution. The original idea was the host to use 
+STUN to detect the NAT type, and when it has found that the NAT type is 
+symmetric it would use TURN to relay the traffic. But as stated above, 
+this approach was deemed to be unreliable, and now the prefered way to use
+TURN (and it's a new TURN specification as well) is to combine it with ICE.
+
+
+\subsection turn TURN (draft-ietf-behave-turn)
+
+Traversal Using Relays around NAT (TURN) is the latest development of TURN. 
+While the protocol details have changed a lot, the objective is still 
+the same, that is to provide relaying control for the application. 
+As mentioned above, preferably TURN should be used with ICE since relaying 
+is costly in terms of both bandwidth and latency, hence it should be used 
+as the last resort.
+
+
+\subsection b2bua B2BUA approach
+
+A SIP Back to Back User Agents (B2BUA) is a SIP entity that sits in the 
+middle of SIP traffic and acts as SIP user agents on both call legs. 
+The primary motivations to have a B2BUA are to be able to provision 
+the call (e.g. billing, enforcing policy) and to help with NAT traversal 
+for the clients. Normally a B2BUA would be equipped with media relaying 
+or otherwise it wouldn't be very useful.
+
+Products that fall into this category include SIP Session Border 
+Controllers (SBC), and PBXs such as Asterisk are technically a B2BUA 
+as well.
+
+The benefit of B2BUA with regard to helping NAT traversal is it does not 
+require any modifications to the client to make it go through NATs. 
+And since basically it is a relay, it should be able to traverse 
+symmetric NAT successfully.
+
+However, since it is a relay, the usual relaying drawbacks apply, 
+namely the bandwidth and latency issue. More over, since a B2BUA acts 
+as user agent in either call-legs (i.e. it terminates the SIP 
+signaling/call on one leg, albeit it creates another call on the other 
+leg), it may also introduce serious issues with end-to-end SIP signaling.
+
+
+\subsection alg ALG approach
+
+Nowdays many NAT devices (such as consumer ADSL routers) are equipped 
+with intelligence to inspect and fix VoIP traffic in its effort to help 
+it with the NAT traversal. This feature is called Application Layer 
+Gateway (ALG) intelligence. The idea is since the NAT device knows about 
+the mapping, it might as well try to fix the application traffic so that 
+the traffic could better traverse the NAT. Some tricks that are 
+performed include for example replacing the private IP addresses/ports 
+in the SIP/SDP packet with the mapped public address/port of the host 
+that sends the packet.
+
+Despite many claims about its usefullness, in reality this has given us 
+more problems than the fix. Too many devices such as these break the 
+SIP signaling, and in more advanced case, ICE negotiation. Some 
+examples of bad situations that we have encountered in the past:
+
+ - NAT device alters the Via address/port fields in the SIP response 
+   message, making the response fail to pass SIP response verification 
+   as defined by SIP RFC.
+ - In other case, the modifications in the Via headers of the SIP 
+   response hides the important information from the SIP server, 
+   nameny the actual IP address/port of the client as seen by the SIP 
+   server.
+ - Modifications in the Contact URI of REGISTER request/response makes 
+   the client unable to detect it's registered binding.
+ - Modifications in the IP addresses/ports in SDP causes ICE 
+   negotiation to fail with ice-mismatch status.
+ - The complexity of the ALG processing in itself seems to have caused 
+   the device to behave erraticly with managing the address bindings 
+   (e.g. it creates a new binding for the second packet sent by the 
+   client, even when the previous packet was sent just second ago, or
+   it just sends inbound packet to the wrong host).
+
+
+Many man-months efforts have been spent just to troubleshoot issues 
+caused by these ALG (mal)functioning, and as it adds complexity to 
+the problem rather than solving it, in general we do not like this 
+approach at all and would prefer it to go away.
+
+
+\subsection upnp UPnP
+
+The Universal Plug and Play (UPnP) is a set of protocol specifications 
+to control network appliances and one of its specification is to 
+control NAT device. With this protocol, a client can instruct the 
+NAT device to open a port in the NAT's public side and use this port 
+for its communication. UPnP has gained popularity due to its 
+simplicity, and one can expect it to be available on majority of 
+NAT devices.
+
+The drawback of UPnP is since it uses multicast in its communication,
+it will only allow client to control one NAT device that is in the 
+same multicast domain. While this normally is not a problem in 
+household installations (where people normally only have one NAT 
+router), it will not work if the client is behind cascaded routers 
+installation. More over uPnP has serious issues with security due to 
+its lack of authentication, it's probably not the prefered solution 
+for organizations.
+
+\subsection other Other solutions
+
+Other solutions to NAT traversal includes:
+
+ - SOCKS, which supports UDP protocol since SOCKS5.
+
+
+
+\section ice ICE Solution - The Protocol that Works Harder
+
+A new protocol is being standardized (it's in Work Group Last Call/WGLC 
+stage at the time this article was written) by the IETF, called 
+Interactive Connectivity Establishment (ICE). ICE is the ultimate 
+weapon a client can have in its NAT traversal solution arsenals, 
+as it promises that if there is indeed one path for two clients 
+to communicate, then ICE will find this path. And if there are 
+more than one paths which the clients can communicate, ICE will 
+use the best/most efficient one.
+
+ICE works by combining several protocols (such as STUN and TURN) 
+altogether and offering several candidate paths for the communication, 
+thereby maximising the chance of success, but at the same time also 
+has the capability to prioritize the candidates, so that the more 
+expensive alternative (namely relay) will only be used as the last
+resort when else fails. ICE negotiation process involves several 
+stages:
+
+ - candidate gathering, where the client finds out all the possible 
+   addresses that it can use for the communication. It may find 
+   three types of candidates: host candidate to represent its 
+   physical NICs, server reflexive candidate for the address that 
+   has been resolved from STUN, and relay candidate for the address 
+   that the client has allocated from a TURN relay.
+ - prioritizing these candidates. Typically the relay candidate will
+   have the lowest priority to use since it's the most expensive.
+ - encoding these candidates, sending it to remote peer, and 
+   negotiating it with offer-answer.
+ - pairing the candidates, where it pairs every local candidates 
+   with every remote candidates that it receives from the remote peer.
+ - checking the connectivity for each candidate pairs.
+ - concluding the result. Since every possible path combinations are 
+   checked, if there is a path to communicate ICE will find it.
+
+
+There are many benetifs of ICE:
+
+ - it's standard based.
+ - it works where STUN works (and more)
+ - unlike standalone STUN solution, it solves the hairpinning issue, 
+   since it also offers host candidates.
+ - just as relaying solutions, it works with symmetric NATs. But unlike 
+   plain relaying, relay is only used as the last resort, thereby 
+   minimizing the bandwidth and latency issue of relaying.
+ - it offers a generic framework for offering and checking address 
+   candidates. While the ICE core standard only talks about using STUN 
+   and TURN, implementors can add more types of candidates in the ICE 
+   offer, for example UDP over TCP or HTTP relays, or even uPnP 
+   candidates, and this could be done transparently for the remote 
+   peer hence it's compatible and usable even when the remote peer 
+   does not support these.
+ - it also adds some kind of security particularly against DoS attacks, 
+   since media address must be acknowledged before it can be used.
+
+
+Having said that, ICE is a complex protocol to implement, making 
+interoperability an issue, and at this time of writing we don't see 
+many implementations of it yet. Fortunately, PJNATH has been one of 
+the first hence more mature ICE implementation, being first released
+on mid-2007, and we have been testing our implementation at 
+<A HREF="http://www.sipit.net">SIP Interoperability Test (SIPit)</A>
+events regularly, so hopefully we are one of the most stable as well.
+
+
+\section pjnath PJNATH - The building blocks for effective NAT traversal solution
+
+PJSIP NAT Helper (PJNATH) is a library which contains the implementation 
+of standard based NAT traversal solutions. PJNATH can be used as a 
+stand-alone library for your software, or you may use PJSUA-LIB library, 
+a very high level library integrating PJSIP, PJMEDIA, and PJNATH into 
+simple to use APIs.
+
+PJNATH has the following features:
+
+ - STUNbis implementation, providing both ready to use STUN-aware socket 
+   and framework to implement higher level STUN based protocols such as 
+   TURN and ICE.
+ - NAT type detection, useful for troubleshooting purposes.
+ - TURN implementation.
+ - ICE implementation.
+
+
+More protocols will be implemented in the future.
+
+Go back to \ref index.
+
+ */
diff --git a/pjnath/docs/doc_samples.h b/pjnath/docs/doc_samples.h
new file mode 100644
index 0000000..68d4f6f
--- /dev/null
+++ b/pjnath/docs/doc_samples.h
@@ -0,0 +1,93 @@
+/* $Id: doc_samples.h 3553 2011-05-05 06:14:19Z nanang $ */
+/* 
+ * Copyright (C) 2008-2011 Teluu Inc. (http://www.teluu.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA 
+ */
+
+
+/**
+@addtogroup samples_page
+
+Several samples that are included in the PJSIP distributions. The screenshots
+below were taken on a Windows machine, but the library is very portable and
+it is known to run on platforms such as Linux, MacOS X, Windows Mobile,
+Symbian, and so on.
+
+  - @ref ice_demo_sample\n
+    This sample demonstrates how to use \ref PJNATH_ICE_STREAM_TRANSPORT
+    <b>without</b> using signaling protocol such as <b>SIP</b>. It provides 
+    interactive user interface to create and manage the ICE sessions as well
+    as to exchange SDP with another ice_demo instance.\n\n
+    \image html ice_demo.jpg "ice_demo on WinXP"
+
+  - @ref turn_client_sample\n
+    This sample demonstrates how to use \ref PJNATH_TURN_SOCK
+    and also \ref PJNATH_STUN_SOCK. It provides interactive 
+    user interface to manage allocation, permissions, and
+    channel bindings.\n\n
+    \image html pjturn_client.jpg "pjturn_client on WinXP"
+
+  - TURN server sample\n
+    This is a simple sample TURN server application, which
+    we mainly use for testing (as back then there is no TURN
+    server available).\n
+    The source code for this application are in <tt><b>pjnath/src/pjturn-srv</b></tt>
+    directory.
+
+ */
+
+
+/**
+\page turn_client_sample pjturn-client, a sample TURN client
+
+This is a simple, interactive TURN client application, with the 
+following features:
+ - DNS SRV resolution
+ - TCP connection to TURN server
+ - Optional fingerprint
+
+This file is pjnath/src/pjturn-client/client_main.c.
+
+Screenshot on WinXP: \image html pjturn_client.jpg "pjturn_client on WinXP"
+
+\includelineno client_main.c.
+*/
+
+
+/**
+\page ice_demo_sample ice_demo, an interactive ICE endpoint
+
+This sample demonstrates how to use \ref PJNATH_ICE_STREAM_TRANSPORT
+<b>without</b> using signaling protocol such as SIP. It provides
+interactive user interface to create and manage the ICE sessions as well
+as to exchange SDP with another ice_demo instance.
+
+Features of the demo application:
+ - supports host, STUN, and TURN candidates
+ - disabling of host candidates
+ - DNS SRV resolution for STUN and TURN servers
+ - TCP connection to TURN server
+ - Optional use of fingerprint for TURN
+ - prints and parse SDP containing ICE infos
+ - exchange SDP with copy/paste
+
+This file is pjsip-apps/src/samples/icedemo.c
+
+Screenshot on WinXP: \image html ice_demo.jpg "ice_demo on WinXP"
+
+\includelineno icedemo.c.
+*/
+
diff --git a/pjnath/docs/doc_stun.h b/pjnath/docs/doc_stun.h
new file mode 100644
index 0000000..6f4fdb0
--- /dev/null
+++ b/pjnath/docs/doc_stun.h
@@ -0,0 +1,134 @@
+/* $Id: doc_stun.h 3553 2011-05-05 06:14:19Z nanang $ */
+/* 
+ * Copyright (C) 2008-2011 Teluu Inc. (http://www.teluu.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA 
+ */
+
+
+/**
+@defgroup PJNATH_STUN STUN: Session Traversal Utilities for NAT
+@ingroup PJNATH
+@brief Open source STUN library
+ */
+
+/**
+@defgroup PJNATH_STUN_SOCK STUN-aware socket transport
+@brief STUN aware UDP socket transport
+@ingroup PJNATH_STUN
+ */
+
+
+/**
+@defgroup PJNATH_STUN_SESSION STUN session
+@brief STUN client and server session
+@ingroup PJNATH_STUN
+ */
+
+/**
+@defgroup PJNATH_STUN_BASE Base STUN objects
+@ingroup PJNATH_STUN
+@brief STUN data structures, objects, and configurations
+
+These section contains STUN base data structures as well as
+configurations. Among other things it contains STUN message
+representation and parsing, transactions, authentication
+framework, as well as compile-time and run-time configurations.
+*/
+
+
+/**
+@addtogroup PJNATH_STUN
+
+This module contains implementation of STUN library in PJNATH -
+the open source NAT helper containing STUN and ICE.
+
+\section stun_org_sec Library organizations
+
+The STUN part of PJNATH consists of the the following sections (see
+<b>Table of Contents</b> below).
+
+
+\section stun_using_sec Using the STUN transport
+
+The \ref PJNATH_STUN_SOCK is a ready to use object which provides 
+send and receive interface for communicating UDP packets as well as
+means to communicate with the STUN server and manage the STUN mapped
+address.
+
+Some features of the \ref PJNATH_STUN_SOCK:
+ - API to send and receive UDP packets,
+ - interface to query the STUN mapped address info, 
+ - multiplex STUN and non-STUN incoming packets and distinguish between
+   STUN responses that belong to internal requests with application data
+   (the application data may be STUN packets as well),
+ - resolution of the STUN server with DNS SRV query (if wanted), 
+ - maintaining STUN keep-alive, and 
+ - handle changes in STUN mapped address binding.
+
+Please see \ref PJNATH_STUN_SOCK for more information.
+
+
+\section stun_advanced_sec Advanced use of the STUN components
+
+The rest of the STUN part of the library provides lower level objects
+which can be used to build your own STUN based transport or
+protocols (officially called STUN usages). These will be explained 
+briefly below.
+
+
+\subsection stun_sess_sec The STUN session
+
+A STUN session is interactive information exchange between two STUN 
+endpoints that lasts for some period of time. It is typically started by
+an outgoing or incoming request, and consists of several requests, 
+responses, and indications. All requests and responses within the session
+typically share a same credential.
+
+The \ref PJNATH_STUN_SESSION is a transport-independent object to
+manage a client or server STUN session. It is one of the core object in
+PJNATH, and it is used by several higher level objects including the 
+\ref PJNATH_STUN_SOCK, \ref PJNATH_TURN_SESSION, and \ref PJNATH_ICE_SESSION.
+
+The \ref PJNATH_STUN_SESSION has the following features:
+   - transport independent
+   - authentication management
+   - static or dynamic credential
+   - client transaction management
+   - server transaction management
+
+For more information, including how to use it please see 
+\ref PJNATH_STUN_SESSION.
+
+
+\subsection stun_extending_sec Extending STUN to support other usages
+
+At present, the STUN subsystem in PJNATH supports STUN Binding, TURN, and
+ICE usages. If other usages are to be supported, typically you would need
+to add new STUN methods (and the corresponding request and response message
+types), attributes, and error codes to \ref PJNATH_STUN_MSG subsystem of
+PJNATH, as well as implementing the logic for the STUN usage.
+
+
+\section stunsamples_sec STUN samples
+
+The \ref turn_client_sample sample application also contains sample
+code to use \ref PJNATH_STUN_SOCK. 
+
+Also see <b>\ref samples_page</b> for other samples.
+
+
+ */
+
diff --git a/pjnath/docs/doc_turn.h b/pjnath/docs/doc_turn.h
new file mode 100644
index 0000000..e24cfdc
--- /dev/null
+++ b/pjnath/docs/doc_turn.h
@@ -0,0 +1,164 @@
+/* $Id: doc_turn.h 3553 2011-05-05 06:14:19Z nanang $ */
+/* 
+ * Copyright (C) 2008-2011 Teluu Inc. (http://www.teluu.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA 
+ */
+
+
+/**
+@defgroup PJNATH_TURN TURN: Traversal Using Relays around NAT
+@brief TURN protocol implementation
+@ingroup PJNATH
+
+\section turn_intro_sec Introduction to TURN
+
+When a direct communication path cannot be found, it is necessary to
+use the services of an intermediate host that acts as a relay for the
+packets.  This relay typically sits in the public Internet and relays
+packets between two hosts that both sit behind NATs.
+
+TURN allows a host behind a NAT (called the TURN client) to request that 
+another host (called the TURN server) act as a relay.  The client can 
+arrange for the server to relay packets to and from certain other hosts
+(called peers) and can control aspects of how the relaying is done.
+The client does this by obtaining an IP address and port on the
+server, called the relayed-transport-address.  When a peer sends a
+packet to the relayed-transport-address, the server relays the packet
+to the client.  When the client sends a data packet to the server,
+the server relays it to the appropriate peer using the relayed-
+transport-address as the source.
+
+
+\section turn_op_sec Overview of TURN operations
+
+<b>Discovering TURN server</b>.\n
+Client learns the IP address of the TURN
+server either through some privisioning or by querying DNS SRV records
+for TURN service for the specified domain. Client may use UDP or TCP (or
+TLS) to connect to the TURN server.
+
+<b>Authentication</b>.\n
+All TURN operations requires the use of authentication
+(it uses STUN long term autentication method), hence client must be
+configured with the correct credential to use the service.
+
+<b>Allocation</b>.\n
+Client creates one "relay port" (or called <b>relayed-transport-address</b>
+in TURN terminology) in the TURN server by sending TURN \a Allocate request,
+hence this process is called creating allocation. Once the allocation is 
+successful, client will be given the IP address and port of the "relay 
+port" in the Allocate response.
+
+<b>Sending data through the relay</b>.\n
+Once allocation has been created, client may send data to any remote 
+endpoints (called peers in TURN terminology) via the "relay port". It does 
+so by sending Send Indication to the TURN server, giving the peer address 
+in the indication message. But note that at this point peers are not allowed
+to send data towards the client (via the "relay port") before permission is 
+installed for that peer.
+
+<b>Creating permissions</b>.\n
+Permission needs to be created in the TURN server so that a peer can send 
+data to the client via the relay port (a peer in this case is identified by
+its IP address). Without this, when the TURN server receives data from the
+peer in the "relay port", it will drop this data.
+
+<b>Receiving data from peers</b>.\n
+Once permission has been installed for the peer, any data received by the 
+TURN server (from that peer) in the "relay port" will be relayed back to 
+client by using Data Indication.
+
+<b>Using ChannelData</b>.\n
+TURN provides optimized framing to the data by using ChannelData 
+packetization. The client activates this format by sending ChannelBind 
+request to the TURN server, which provides (channel) binding which maps a 
+particular peer address with a channel number. Data sent or received to/for
+this peer will then use ChannelData format instead of Send or Data 
+Indications.
+
+<b>Refreshing the allocation, permissions, and channel bindings</b>.\n
+Allocations, permissions, and channel bindings need to be refreshed
+periodically by client, or otherwise they will expire.
+
+<b>Destroying the allocation</b>.\n
+Once the "relay port" is no longer needed, client destroys the allocation
+by sending Refresh request with LIFETIME attribute set to zero.
+
+
+\section turn_org_sec Library organizations
+
+The TURN functionalities in PJNATH primarily consist of 
+\ref PJNATH_TURN_SOCK and \ref PJNATH_TURN_SESSION. Please see more
+below.
+
+
+\section turn_using_sec Using TURN transport
+
+The \ref PJNATH_TURN_SOCK is a ready to use object for relaying
+application data via a TURN server, by managing all the operations
+above.
+
+Among other things it provides the following features:
+ - resolution of the TURN server with DNS SRV
+ - interface to create allocation, permissions, and channel
+   bindings
+ - interface to send and receive packets through the relay
+ - provides callback to notify the application about incoming data
+ - managing the allocation, permissions, and channel bindings
+
+Please see \ref PJNATH_TURN_SOCK for more documentation about and
+on how to use this object.
+
+
+\section turn_owntransport_sec Creating custom TURN transport
+
+The \ref PJNATH_TURN_SESSION is a transport-independent object to
+manage a client TURN session. It contains the core logic for managing
+the TURN client session as listed in TURN operations above, but
+in transport-independent manner (i.e. it doesn't have a socket), so
+that developer can integrate TURN client functionality into existing
+framework that already has its own means to send and receive data,
+or to support new transport types to TURN, such as TLS.
+
+You can create your own (custom) TURN transport by wrapping this
+into your own object, and provide it with the means to send and
+receive packets.
+
+Please see \ref PJNATH_TURN_SESSION for more information.
+
+
+\section turn_samples_sec Samples
+
+The \ref turn_client_sample is a sample application to use the
+\ref PJNATH_TURN_SOCK. Also there is a sample TURN server in
+the distribution as well. 
+
+Also see <b>\ref samples_page</b> for other samples.
+
+ */
+
+
+/**
+ * @defgroup PJNATH_TURN_SOCK TURN client transport
+ * @brief Client transport utilizing TURN relay
+ * @ingroup PJNATH_TURN
+ */
+
+/**
+ * @defgroup PJNATH_TURN_SESSION TURN client session
+ * @brief Transport independent TURN client session
+ * @ingroup PJNATH_TURN
+ */
diff --git a/pjnath/docs/doxygen.cfg b/pjnath/docs/doxygen.cfg
new file mode 100644
index 0000000..70bf6f7
--- /dev/null
+++ b/pjnath/docs/doxygen.cfg
@@ -0,0 +1,1033 @@
+# Doxyfile 1.3-rc3

+

+# This file describes the settings to be used by the documentation system

+# doxygen (www.doxygen.org) for a project

+#

+# All text after a hash (#) is considered a comment and will be ignored

+# The format is:

+#       TAG = value [value, ...]

+# For lists items can also be appended using:

+#       TAG += value [value, ...]

+# Values that contain spaces should be placed between quotes (" ")

+

+#---------------------------------------------------------------------------

+# General configuration options

+#---------------------------------------------------------------------------

+

+# The PROJECT_NAME tag is a single word (or a sequence of words surrounded 

+# by quotes) that should identify the project.

+

+PROJECT_NAME           =  "PJNATH Reference"

+

+# The PROJECT_NUMBER tag can be used to enter a project or revision number. 

+# This could be handy for archiving the generated documentation or 

+# if some version control system is used.

+

+PROJECT_NUMBER         = $(PJ_VERSION)

+

+# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) 

+# base path where the generated documentation will be put. 

+# If a relative path is entered, it will be relative to the location 

+# where doxygen was started. If left blank the current directory will be used.

+

+OUTPUT_DIRECTORY       = docs/$(PJ_VERSION)

+

+# The OUTPUT_LANGUAGE tag is used to specify the language in which all 

+# documentation generated by doxygen is written. Doxygen will use this 

+# information to generate all constant output in the proper language. 

+# The default language is English, other supported languages are: 

+# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch, 

+# Finnish, French, German, Greek, Hungarian, Italian, Japanese, Japanese-en 

+# (Japanese with english messages), Korean, Norwegian, Polish, Portuguese, 

+# Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish and Ukrainian.

+

+OUTPUT_LANGUAGE        = English

+

+# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in 

+# documentation are documented, even if no documentation was available. 

+# Private class members and static file members will be hidden unless 

+# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES

+

+EXTRACT_ALL            = NO

+

+# If the EXTRACT_PRIVATE tag is set to YES all private members of a class 

+# will be included in the documentation.

+

+EXTRACT_PRIVATE        = NO

+

+# If the EXTRACT_STATIC tag is set to YES all static members of a file 

+# will be included in the documentation.

+

+EXTRACT_STATIC         = NO

+

+# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) 

+# defined locally in source files will be included in the documentation. 

+# If set to NO only classes defined in header files are included.

+

+EXTRACT_LOCAL_CLASSES  = YES

+

+# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all 

+# undocumented members of documented classes, files or namespaces. 

+# If set to NO (the default) these members will be included in the 

+# various overviews, but no documentation section is generated. 

+# This option has no effect if EXTRACT_ALL is enabled.

+

+HIDE_UNDOC_MEMBERS     = NO

+

+# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all 

+# undocumented classes that are normally visible in the class hierarchy. 

+# If set to NO (the default) these class will be included in the various 

+# overviews. This option has no effect if EXTRACT_ALL is enabled.

+

+HIDE_UNDOC_CLASSES     = NO

+

+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all 

+# friend (class|struct|union) declarations. 

+# If set to NO (the default) these declarations will be included in the 

+# documentation.

+

+HIDE_FRIEND_COMPOUNDS  = NO

+

+# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any 

+# documentation blocks found inside the body of a function. 

+# If set to NO (the default) these blocks will be appended to the 

+# function's detailed documentation block.

+

+HIDE_IN_BODY_DOCS      = NO

+

+# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will 

+# include brief member descriptions after the members that are listed in 

+# the file and class documentation (similar to JavaDoc). 

+# Set to NO to disable this.

+

+BRIEF_MEMBER_DESC      = YES

+

+# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend 

+# the brief description of a member or function before the detailed description. 

+# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the 

+# brief descriptions will be completely suppressed.

+

+REPEAT_BRIEF           = NO

+

+# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then 

+# Doxygen will generate a detailed section even if there is only a brief 

+# description.

+

+ALWAYS_DETAILED_SEC    = NO

+

+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all inherited 

+# members of a class in the documentation of that class as if those members were 

+# ordinary class members. Constructors, destructors and assignment operators of 

+# the base classes will not be shown.

+

+INLINE_INHERITED_MEMB  = NO

+

+# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full 

+# path before files name in the file list and in the header files. If set 

+# to NO the shortest path that makes the file name unique will be used.

+

+FULL_PATH_NAMES        = NO

+

+# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag 

+# can be used to strip a user defined part of the path. Stripping is 

+# only done if one of the specified strings matches the left-hand part of 

+# the path. It is allowed to use relative paths in the argument list.

+

+STRIP_FROM_PATH        = "c:\project\pjproject"

+

+# The INTERNAL_DOCS tag determines if documentation 

+# that is typed after a \internal command is included. If the tag is set 

+# to NO (the default) then the documentation will be excluded. 

+# Set it to YES to include the internal documentation.

+

+INTERNAL_DOCS          = NO

+

+# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate 

+# file names in lower case letters. If set to YES upper case letters are also 

+# allowed. This is useful if you have classes or files whose names only differ 

+# in case and if your file system supports case sensitive file names. Windows 

+# users are adviced to set this option to NO.

+

+CASE_SENSE_NAMES       = YES

+

+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter 

+# (but less readable) file names. This can be useful is your file systems 

+# doesn't support long names like on DOS, Mac, or CD-ROM.

+

+SHORT_NAMES            = NO

+

+# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen 

+# will show members with their full class and namespace scopes in the 

+# documentation. If set to YES the scope will be hidden.

+

+HIDE_SCOPE_NAMES       = NO

+

+# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen 

+# will generate a verbatim copy of the header file for each class for 

+# which an include is specified. Set to NO to disable this.

+

+VERBATIM_HEADERS       = YES

+

+# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen 

+# will put list of the files that are included by a file in the documentation 

+# of that file.

+

+SHOW_INCLUDE_FILES     = NO

+

+# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen 

+# will interpret the first line (until the first dot) of a JavaDoc-style 

+# comment as the brief description. If set to NO, the JavaDoc 

+# comments  will behave just like the Qt-style comments (thus requiring an 

+# explict @brief command for a brief description.

+

+JAVADOC_AUTOBRIEF      = NO

+

+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen 

+# treat a multi-line C++ special comment block (i.e. a block of //! or /// 

+# comments) as a brief description. This used to be the default behaviour. 

+# The new default is to treat a multi-line C++ comment block as a detailed 

+# description. Set this tag to YES if you prefer the old behaviour instead.

+

+MULTILINE_CPP_IS_BRIEF = NO

+

+# If the DETAILS_AT_TOP tag is set to YES then Doxygen 

+# will output the detailed description near the top, like JavaDoc.

+# If set to NO, the detailed description appears after the member 

+# documentation.

+

+DETAILS_AT_TOP         = YES

+

+# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented 

+# member inherits the documentation from any documented member that it 

+# reimplements.

+

+INHERIT_DOCS           = YES

+

+# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] 

+# is inserted in the documentation for inline members.

+

+INLINE_INFO            = YES

+

+# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen 

+# will sort the (detailed) documentation of file and class members 

+# alphabetically by member name. If set to NO the members will appear in 

+# declaration order.

+

+SORT_MEMBER_DOCS       = YES

+

+# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC 

+# tag is set to YES, then doxygen will reuse the documentation of the first 

+# member in the group (if any) for the other members of the group. By default 

+# all members of a group must be documented explicitly.

+

+DISTRIBUTE_GROUP_DOC   = NO

+

+# The TAB_SIZE tag can be used to set the number of spaces in a tab. 

+# Doxygen uses this value to replace tabs by spaces in code fragments.

+

+TAB_SIZE               = 8

+

+# The GENERATE_TODOLIST tag can be used to enable (YES) or 

+# disable (NO) the todo list. This list is created by putting \todo 

+# commands in the documentation.

+

+GENERATE_TODOLIST      = YES

+

+# The GENERATE_TESTLIST tag can be used to enable (YES) or 

+# disable (NO) the test list. This list is created by putting \test 

+# commands in the documentation.

+

+GENERATE_TESTLIST      = YES

+

+# The GENERATE_BUGLIST tag can be used to enable (YES) or 

+# disable (NO) the bug list. This list is created by putting \bug 

+# commands in the documentation.

+

+GENERATE_BUGLIST       = YES

+

+# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or 

+# disable (NO) the deprecated list. This list is created by putting 

+# \deprecated commands in the documentation.

+

+GENERATE_DEPRECATEDLIST= YES

+

+# This tag can be used to specify a number of aliases that acts 

+# as commands in the documentation. An alias has the form "name=value". 

+# For example adding "sideeffect=\par Side Effects:\n" will allow you to 

+# put the command \sideeffect (or @sideeffect) in the documentation, which 

+# will result in a user defined paragraph with heading "Side Effects:". 

+# You can put \n's in the value part of an alias to insert newlines.

+

+ALIASES                = 

+

+# The ENABLED_SECTIONS tag can be used to enable conditional 

+# documentation sections, marked by \if sectionname ... \endif.

+

+ENABLED_SECTIONS       = 

+

+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines 

+# the initial value of a variable or define consist of for it to appear in 

+# the documentation. If the initializer consists of more lines than specified 

+# here it will be hidden. Use a value of 0 to hide initializers completely. 

+# The appearance of the initializer of individual variables and defines in the 

+# documentation can be controlled using \showinitializer or \hideinitializer 

+# command in the documentation regardless of this setting.

+

+MAX_INITIALIZER_LINES  = 30

+

+# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources 

+# only. Doxygen will then generate output that is more tailored for C. 

+# For instance some of the names that are used will be different. The list 

+# of all members will be omitted, etc.

+

+OPTIMIZE_OUTPUT_FOR_C  = YES

+

+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java sources 

+# only. Doxygen will then generate output that is more tailored for Java. 

+# For instance namespaces will be presented as packages, qualified scopes 

+# will look different, etc.

+

+OPTIMIZE_OUTPUT_JAVA   = NO

+

+# Set the SHOW_USED_FILES tag to NO to disable the list of files generated 

+# at the bottom of the documentation of classes and structs. If set to YES the 

+# list will mention the files that were used to generate the documentation.

+

+SHOW_USED_FILES        = YES

+TYPEDEF_HIDES_STRUCT	= YES

+

+#---------------------------------------------------------------------------

+# configuration options related to warning and progress messages

+#---------------------------------------------------------------------------

+

+# The QUIET tag can be used to turn on/off the messages that are generated 

+# by doxygen. Possible values are YES and NO. If left blank NO is used.

+

+QUIET                  = NO

+

+# The WARNINGS tag can be used to turn on/off the warning messages that are 

+# generated by doxygen. Possible values are YES and NO. If left blank 

+# NO is used.

+

+WARNINGS               = YES

+

+# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings 

+# for undocumented members. If EXTRACT_ALL is set to YES then this flag will 

+# automatically be disabled.

+

+WARN_IF_UNDOCUMENTED   = YES

+

+# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for 

+# potential errors in the documentation, such as not documenting some 

+# parameters in a documented function, or documenting parameters that 

+# don't exist or using markup commands wrongly.

+

+WARN_IF_DOC_ERROR      = YES

+

+# The WARN_FORMAT tag determines the format of the warning messages that 

+# doxygen can produce. The string should contain the $file, $line, and $text 

+# tags, which will be replaced by the file and line number from which the 

+# warning originated and the warning text.

+

+WARN_FORMAT            = "$file:$line: $text"

+

+# The WARN_LOGFILE tag can be used to specify a file to which warning 

+# and error messages should be written. If left blank the output is written 

+# to stderr.

+

+WARN_LOGFILE           = 

+

+#---------------------------------------------------------------------------

+# configuration options related to the input files

+#---------------------------------------------------------------------------

+

+# The INPUT tag can be used to specify the files and/or directories that contain 

+# documented source files. You may enter file names like "myfile.cpp" or 

+# directories like "/usr/src/myproject". Separate the files or directories 

+# with spaces.

+

+INPUT                  =  docs include/pjnath

+

+# If the value of the INPUT tag contains directories, you can use the 

+# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp 

+# and *.h) to filter out the source-files in the directories. If left 

+# blank the following patterns are tested: 

+# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx *.hpp 

+# *.h++ *.idl *.odl

+

+FILE_PATTERNS          = *.h *.c

+

+# The RECURSIVE tag can be used to turn specify whether or not subdirectories 

+# should be searched for input files as well. Possible values are YES and NO. 

+# If left blank NO is used.

+

+RECURSIVE              = YES

+

+# The EXCLUDE tag can be used to specify files and/or directories that should 

+# excluded from the INPUT source files. This way you can easily exclude a 

+# subdirectory from a directory tree whose root is specified with the INPUT tag.

+

+EXCLUDE                = 

+

+# The EXCLUDE_SYMLINKS tag can be used select whether or not files or directories 

+# that are symbolic links (a Unix filesystem feature) are excluded from the input.

+

+EXCLUDE_SYMLINKS       = NO

+

+# If the value of the INPUT tag contains directories, you can use the 

+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude 

+# certain files from those directories.

+

+EXCLUDE_PATTERNS       = "*_i.h" "*/compat/*"

+

+# The EXAMPLE_PATH tag can be used to specify one or more files or 

+# directories that contain example code fragments that are included (see 

+# the \include command).

+

+EXAMPLE_PATH           = ../pjsip-apps/src/samples src/pjturn-client

+

+# If the value of the EXAMPLE_PATH tag contains directories, you can use the 

+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp 

+# and *.h) to filter out the source-files in the directories. If left 

+# blank all files are included.

+

+EXAMPLE_PATTERNS       = 

+

+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be 

+# searched for input files to be used with the \include or \dontinclude 

+# commands irrespective of the value of the RECURSIVE tag. 

+# Possible values are YES and NO. If left blank NO is used.

+

+EXAMPLE_RECURSIVE      = YES

+

+# The IMAGE_PATH tag can be used to specify one or more files or 

+# directories that contain image that are included in the documentation (see 

+# the \image command).

+

+IMAGE_PATH             =  docs

+

+# The INPUT_FILTER tag can be used to specify a program that doxygen should 

+# invoke to filter for each input file. Doxygen will invoke the filter program 

+# by executing (via popen()) the command <filter> <input-file>, where <filter> 

+# is the value of the INPUT_FILTER tag, and <input-file> is the name of an 

+# input file. Doxygen will then use the output that the filter program writes 

+# to standard output.

+

+INPUT_FILTER           = 

+

+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using 

+# INPUT_FILTER) will be used to filter the input files when producing source 

+# files to browse (i.e. when SOURCE_BROWSER is set to YES).

+

+FILTER_SOURCE_FILES    = NO

+

+#---------------------------------------------------------------------------

+# configuration options related to source browsing

+#---------------------------------------------------------------------------

+

+# If the SOURCE_BROWSER tag is set to YES then a list of source files will 

+# be generated. Documented entities will be cross-referenced with these sources.

+

+SOURCE_BROWSER         = NO

+

+# Setting the INLINE_SOURCES tag to YES will include the body 

+# of functions and classes directly in the documentation.

+

+INLINE_SOURCES         = NO

+

+# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct 

+# doxygen to hide any special comment blocks from generated source code 

+# fragments. Normal C and C++ comments will always remain visible.

+

+STRIP_CODE_COMMENTS    = YES

+

+# If the REFERENCED_BY_RELATION tag is set to YES (the default) 

+# then for each documented function all documented 

+# functions referencing it will be listed.

+

+REFERENCED_BY_RELATION = YES

+

+# If the REFERENCES_RELATION tag is set to YES (the default) 

+# then for each documented function all documented entities 

+# called/used by that function will be listed.

+

+REFERENCES_RELATION    = YES

+

+#---------------------------------------------------------------------------

+# configuration options related to the alphabetical class index

+#---------------------------------------------------------------------------

+

+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index 

+# of all compounds will be generated. Enable this if the project 

+# contains a lot of classes, structs, unions or interfaces.

+

+ALPHABETICAL_INDEX     = NO

+

+# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then 

+# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns 

+# in which this list will be split (can be a number in the range [1..20])

+

+COLS_IN_ALPHA_INDEX    = 5

+

+# In case all classes in a project start with a common prefix, all 

+# classes will be put under the same header in the alphabetical index. 

+# The IGNORE_PREFIX tag can be used to specify one or more prefixes that 

+# should be ignored while generating the index headers.

+

+IGNORE_PREFIX          = 

+

+#---------------------------------------------------------------------------

+# configuration options related to the HTML output

+#---------------------------------------------------------------------------

+

+# If the GENERATE_HTML tag is set to YES (the default) Doxygen will 

+# generate HTML output.

+

+GENERATE_HTML          = YES

+

+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. 

+# If a relative path is entered the value of OUTPUT_DIRECTORY will be 

+# put in front of it. If left blank `html' will be used as the default path.

+

+HTML_OUTPUT            = html

+

+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for 

+# each generated HTML page (for example: .htm,.php,.asp). If it is left blank 

+# doxygen will generate files with .html extension.

+

+HTML_FILE_EXTENSION    = .htm

+

+# The HTML_HEADER tag can be used to specify a personal HTML header for 

+# each generated HTML page. If it is left blank doxygen will generate a 

+# standard header.

+

+HTML_HEADER            = docs/header.html

+

+# The HTML_FOOTER tag can be used to specify a personal HTML footer for 

+# each generated HTML page. If it is left blank doxygen will generate a 

+# standard footer.

+

+HTML_FOOTER            = docs/footer.html

+

+# The HTML_STYLESHEET tag can be used to specify a user defined cascading 

+# style sheet that is used by each HTML page. It can be used to 

+# fine-tune the look of the HTML output. If the tag is left blank doxygen 

+# will generate a default style sheet

+

+HTML_STYLESHEET        = docs/doxygen.css

+

+# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, 

+# files or namespaces will be aligned in HTML using tables. If set to 

+# NO a bullet list will be used.

+

+HTML_ALIGN_MEMBERS     = YES

+

+# If the GENERATE_HTMLHELP tag is set to YES, additional index files 

+# will be generated that can be used as input for tools like the 

+# Microsoft HTML help workshop to generate a compressed HTML help file (.chm) 

+# of the generated HTML documentation.

+

+GENERATE_HTMLHELP      = NO

+

+# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can 

+# be used to specify the file name of the resulting .chm file. You 

+# can add a path in front of the file if the result should not be 

+# written to the html output dir.

+

+CHM_FILE               = 

+

+# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can 

+# be used to specify the location (absolute path including file name) of 

+# the HTML help compiler (hhc.exe). If non empty doxygen will try to run 

+# the html help compiler on the generated index.hhp.

+

+HHC_LOCATION           = 

+

+# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag 

+# controls if a separate .chi index file is generated (YES) or that 

+# it should be included in the master .chm file (NO).

+

+GENERATE_CHI           = NO

+

+# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag 

+# controls whether a binary table of contents is generated (YES) or a 

+# normal table of contents (NO) in the .chm file.

+

+BINARY_TOC             = NO

+

+# The TOC_EXPAND flag can be set to YES to add extra items for group members 

+# to the contents of the Html help documentation and to the tree view.

+

+TOC_EXPAND             = NO

+

+# The DISABLE_INDEX tag can be used to turn on/off the condensed index at 

+# top of each HTML page. The value NO (the default) enables the index and 

+# the value YES disables it.

+

+DISABLE_INDEX          = NO

+

+# This tag can be used to set the number of enum values (range [1..20]) 

+# that doxygen will group on one line in the generated HTML documentation.

+

+ENUM_VALUES_PER_LINE   = 1

+

+# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be

+# generated containing a tree-like index structure (just like the one that 

+# is generated for HTML Help). For this to work a browser that supports 

+# JavaScript, DHTML, CSS and frames is required (for instance Mozilla, 

+# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are 

+# probably better off using the HTML help feature.

+

+GENERATE_TREEVIEW      = NO

+

+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be 

+# used to set the initial width (in pixels) of the frame in which the tree 

+# is shown.

+

+TREEVIEW_WIDTH         = 250

+

+#---------------------------------------------------------------------------

+# configuration options related to the LaTeX output

+#---------------------------------------------------------------------------

+

+# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will 

+# generate Latex output.

+

+GENERATE_LATEX         = NO

+

+# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. 

+# If a relative path is entered the value of OUTPUT_DIRECTORY will be 

+# put in front of it. If left blank `latex' will be used as the default path.

+

+LATEX_OUTPUT           = latex

+

+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be 

+# invoked. If left blank `latex' will be used as the default command name.

+

+LATEX_CMD_NAME         = latex

+

+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to 

+# generate index for LaTeX. If left blank `makeindex' will be used as the 

+# default command name.

+

+MAKEINDEX_CMD_NAME     = makeindex

+

+# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact 

+# LaTeX documents. This may be useful for small projects and may help to 

+# save some trees in general.

+

+COMPACT_LATEX          = NO

+

+# The PAPER_TYPE tag can be used to set the paper type that is used 

+# by the printer. Possible values are: a4, a4wide, letter, legal and 

+# executive. If left blank a4wide will be used.

+

+PAPER_TYPE             = a4wide

+

+# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX 

+# packages that should be included in the LaTeX output.

+

+EXTRA_PACKAGES         = 

+

+# The LATEX_HEADER tag can be used to specify a personal LaTeX header for 

+# the generated latex document. The header should contain everything until 

+# the first chapter. If it is left blank doxygen will generate a 

+# standard header. Notice: only use this tag if you know what you are doing!

+

+LATEX_HEADER           = 

+

+# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated 

+# is prepared for conversion to pdf (using ps2pdf). The pdf file will 

+# contain links (just like the HTML output) instead of page references 

+# This makes the output suitable for online browsing using a pdf viewer.

+

+PDF_HYPERLINKS         = YES

+

+# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of 

+# plain latex in the generated Makefile. Set this option to YES to get a 

+# higher quality PDF documentation.

+

+USE_PDFLATEX           = YES

+

+# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. 

+# command to the generated LaTeX files. This will instruct LaTeX to keep 

+# running if errors occur, instead of asking the user for help. 

+# This option is also used when generating formulas in HTML.

+

+LATEX_BATCHMODE        = NO

+

+#---------------------------------------------------------------------------

+# configuration options related to the RTF output

+#---------------------------------------------------------------------------

+

+# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output 

+# The RTF output is optimised for Word 97 and may not look very pretty with 

+# other RTF readers or editors.

+

+GENERATE_RTF           = NO

+

+# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. 

+# If a relative path is entered the value of OUTPUT_DIRECTORY will be 

+# put in front of it. If left blank `rtf' will be used as the default path.

+

+RTF_OUTPUT             = rtf

+

+# If the COMPACT_RTF tag is set to YES Doxygen generates more compact 

+# RTF documents. This may be useful for small projects and may help to 

+# save some trees in general.

+

+COMPACT_RTF            = NO

+

+# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated 

+# will contain hyperlink fields. The RTF file will 

+# contain links (just like the HTML output) instead of page references. 

+# This makes the output suitable for online browsing using WORD or other 

+# programs which support those fields. 

+# Note: wordpad (write) and others do not support links.

+

+RTF_HYPERLINKS         = NO

+

+# Load stylesheet definitions from file. Syntax is similar to doxygen's 

+# config file, i.e. a series of assigments. You only have to provide 

+# replacements, missing definitions are set to their default value.

+

+RTF_STYLESHEET_FILE    = 

+

+# Set optional variables used in the generation of an rtf document. 

+# Syntax is similar to doxygen's config file.

+

+RTF_EXTENSIONS_FILE    = 

+

+#---------------------------------------------------------------------------

+# configuration options related to the man page output

+#---------------------------------------------------------------------------

+

+# If the GENERATE_MAN tag is set to YES (the default) Doxygen will 

+# generate man pages

+

+GENERATE_MAN           = NO

+

+# The MAN_OUTPUT tag is used to specify where the man pages will be put. 

+# If a relative path is entered the value of OUTPUT_DIRECTORY will be 

+# put in front of it. If left blank `man' will be used as the default path.

+

+MAN_OUTPUT             = man

+

+# The MAN_EXTENSION tag determines the extension that is added to 

+# the generated man pages (default is the subroutine's section .3)

+

+MAN_EXTENSION          = .3

+

+# If the MAN_LINKS tag is set to YES and Doxygen generates man output, 

+# then it will generate one additional man file for each entity 

+# documented in the real man page(s). These additional files 

+# only source the real man page, but without them the man command 

+# would be unable to find the correct page. The default is NO.

+

+MAN_LINKS              = NO

+

+#---------------------------------------------------------------------------

+# configuration options related to the XML output

+#---------------------------------------------------------------------------

+

+# If the GENERATE_XML tag is set to YES Doxygen will 

+# generate an XML file that captures the structure of 

+# the code including all documentation. Note that this 

+# feature is still experimental and incomplete at the 

+# moment.

+

+GENERATE_XML           = NO

+

+# The XML_SCHEMA tag can be used to specify an XML schema, 

+# which can be used by a validating XML parser to check the 

+# syntax of the XML files.

+

+XML_SCHEMA             = 

+

+# The XML_DTD tag can be used to specify an XML DTD, 

+# which can be used by a validating XML parser to check the 

+# syntax of the XML files.

+

+XML_DTD                = 

+

+#---------------------------------------------------------------------------

+# configuration options for the AutoGen Definitions output

+#---------------------------------------------------------------------------

+

+# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will 

+# generate an AutoGen Definitions (see autogen.sf.net) file 

+# that captures the structure of the code including all 

+# documentation. Note that this feature is still experimental 

+# and incomplete at the moment.

+

+GENERATE_AUTOGEN_DEF   = NO

+

+#---------------------------------------------------------------------------

+# configuration options related to the Perl module output

+#---------------------------------------------------------------------------

+

+# If the GENERATE_PERLMOD tag is set to YES Doxygen will 

+# generate a Perl module file that captures the structure of 

+# the code including all documentation. Note that this 

+# feature is still experimental and incomplete at the 

+# moment.

+

+GENERATE_PERLMOD       = NO

+

+# If the PERLMOD_LATEX tag is set to YES Doxygen will generate 

+# the necessary Makefile rules, Perl scripts and LaTeX code to be able 

+# to generate PDF and DVI output from the Perl module output.

+

+PERLMOD_LATEX          = NO

+

+# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be 

+# nicely formatted so it can be parsed by a human reader.  This is useful 

+# if you want to understand what is going on.  On the other hand, if this 

+# tag is set to NO the size of the Perl module output will be much smaller 

+# and Perl will parse it just the same.

+

+PERLMOD_PRETTY         = YES

+

+# The names of the make variables in the generated doxyrules.make file 

+# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. 

+# This is useful so different doxyrules.make files included by the same 

+# Makefile don't overwrite each other's variables.

+

+PERLMOD_MAKEVAR_PREFIX = 

+

+#---------------------------------------------------------------------------

+# Configuration options related to the preprocessor   

+#---------------------------------------------------------------------------

+

+# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will 

+# evaluate all C-preprocessor directives found in the sources and include 

+# files.

+

+ENABLE_PREPROCESSING   = YES

+

+# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro 

+# names in the source code. If set to NO (the default) only conditional 

+# compilation will be performed. Macro expansion can be done in a controlled 

+# way by setting EXPAND_ONLY_PREDEF to YES.

+

+MACRO_EXPANSION        = YES

+

+# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES 

+# then the macro expansion is limited to the macros specified with the 

+# PREDEFINED and EXPAND_AS_PREDEFINED tags.

+

+EXPAND_ONLY_PREDEF     = NO

+

+# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files 

+# in the INCLUDE_PATH (see below) will be search if a #include is found.

+

+SEARCH_INCLUDES        = YES

+

+# The INCLUDE_PATH tag can be used to specify one or more directories that 

+# contain include files that are not input files but should be processed by 

+# the preprocessor.

+

+INCLUDE_PATH           = 

+

+# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard 

+# patterns (like *.h and *.hpp) to filter out the header-files in the 

+# directories. If left blank, the patterns specified with FILE_PATTERNS will 

+# be used.

+

+INCLUDE_FILE_PATTERNS  = 

+

+# The PREDEFINED tag can be used to specify one or more macro names that 

+# are defined before the preprocessor is started (similar to the -D option of 

+# gcc). The argument of the tag is a list of macros of the form: name 

+# or name=definition (no spaces). If the definition and the = are 

+# omitted =1 is assumed.

+

+PREDEFINED             = PJ_DECL(x)=x PJ_DEF(x)=x PJ_IDECL(x)=x \

+			 PJ_IDEF(x)=x PJ_INLINE(x)=x \

+			 PJ_DECL_NO_RETURN(x)=x \

+			 PJ_HAS_HIGH_RES_TIMER=1 \

+			 PJ_LOG_MAX_LEVEL=4 \

+			 PJ_HAS_SEMAPHORE=1 \

+			 PJ_HAS_EVENT_OBJ=1

+

+# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then 

+# this tag can be used to specify a list of macro names that should be expanded. 

+# The macro definition that is found in the sources will be used. 

+# Use the PREDEFINED tag if you want to use a different macro definition.

+

+EXPAND_AS_DEFINED      = 

+

+# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then 

+# doxygen's preprocessor will remove all function-like macros that are alone 

+# on a line, have an all uppercase name, and do not end with a semicolon. Such 

+# function macros are typically used for boiler-plate code, and will confuse the 

+# parser if not removed.

+

+SKIP_FUNCTION_MACROS   = YES

+

+#---------------------------------------------------------------------------

+# Configuration::addtions related to external references   

+#---------------------------------------------------------------------------

+

+# The TAGFILES tag can be used to specify one or more tagfiles.

+

+TAGFILES               = ../pjlib/docs/pjlib.tag=../../../pjlib/docs/html ../pjlib-util/docs/pjlib-util.tag=../../../pjlib-util/docs/html ../pjsip/docs/pjsip.tag=../../../pjsip/docs/html ../pjmedia/docs/pjmedia.tag=../../../pjmedia/docs/html

+

+# When a file name is specified after GENERATE_TAGFILE, doxygen will create 

+# a tag file that is based on the input files it reads.

+

+GENERATE_TAGFILE       = ../pjnath/docs/pjnath.tag

+

+# If the ALLEXTERNALS tag is set to YES all external classes will be listed 

+# in the class index. If set to NO only the inherited external classes 

+# will be listed.

+

+ALLEXTERNALS           = NO

+

+# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed 

+# in the modules index. If set to NO, only the current project's groups will 

+# be listed.

+

+EXTERNAL_GROUPS        = NO

+

+# The PERL_PATH should be the absolute path and name of the perl script 

+# interpreter (i.e. the result of `which perl').

+

+#PERL_PATH              = /usr/bin/perl

+PERL_PATH              = /c/Perl/bin/perl

+

+#---------------------------------------------------------------------------

+# Configuration options related to the dot tool   

+#---------------------------------------------------------------------------

+

+# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will 

+# generate a inheritance diagram (in Html, RTF and LaTeX) for classes with base or 

+# super classes. Setting the tag to NO turns the diagrams off. Note that this 

+# option is superceded by the HAVE_DOT option below. This is only a fallback. It is 

+# recommended to install and use dot, since it yield more powerful graphs.

+

+CLASS_DIAGRAMS         = NO

+

+# If set to YES, the inheritance and collaboration graphs will hide 

+# inheritance and usage relations if the target is undocumented 

+# or is not a class.

+

+HIDE_UNDOC_RELATIONS   = YES

+

+# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is 

+# available from the path. This tool is part of Graphviz, a graph visualization 

+# toolkit from AT&T and Lucent Bell Labs. The other options in this section 

+# have no effect if this option is set to NO (the default)

+

+HAVE_DOT               = NO

+

+# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen 

+# will generate a graph for each documented class showing the direct and 

+# indirect inheritance relations. Setting this tag to YES will force the 

+# the CLASS_DIAGRAMS tag to NO.

+

+CLASS_GRAPH            = YES

+

+# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen 

+# will generate a graph for each documented class showing the direct and 

+# indirect implementation dependencies (inheritance, containment, and 

+# class references variables) of the class with other documented classes.

+

+COLLABORATION_GRAPH    = YES

+

+# If set to YES, the inheritance and collaboration graphs will show the 

+# relations between templates and their instances.

+

+TEMPLATE_RELATIONS     = YES

+

+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT 

+# tags are set to YES then doxygen will generate a graph for each documented 

+# file showing the direct and indirect include dependencies of the file with 

+# other documented files.

+

+INCLUDE_GRAPH          = YES

+

+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and 

+# HAVE_DOT tags are set to YES then doxygen will generate a graph for each 

+# documented header file showing the documented files that directly or 

+# indirectly include this file.

+

+INCLUDED_BY_GRAPH      = YES

+

+# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen 

+# will graphical hierarchy of all classes instead of a textual one.

+

+GRAPHICAL_HIERARCHY    = YES

+

+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images 

+# generated by dot. Possible values are png, jpg, or gif

+# If left blank png will be used.

+

+DOT_IMAGE_FORMAT       = png

+

+# The tag DOT_PATH can be used to specify the path where the dot tool can be 

+# found. If left blank, it is assumed the dot tool can be found on the path.

+

+DOT_PATH               = 

+

+# The DOTFILE_DIRS tag can be used to specify one or more directories that 

+# contain dot files that are included in the documentation (see the 

+# \dotfile command).

+

+DOTFILE_DIRS           = 

+

+# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will 

+# generate a legend page explaining the meaning of the various boxes and 

+# arrows in the dot generated graphs.

+

+GENERATE_LEGEND        = YES

+

+# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will 

+# remove the intermedate dot files that are used to generate 

+# the various graphs.

+

+DOT_CLEANUP            = YES

+

+#---------------------------------------------------------------------------

+# Configuration::addtions related to the search engine   

+#---------------------------------------------------------------------------

+

+# The SEARCHENGINE tag specifies whether or not a search engine should be 

+# used. If set to NO the values of all tags below this one will be ignored.

+

+SEARCHENGINE           = NO

+

+# The CGI_NAME tag should be the name of the CGI script that 

+# starts the search engine (doxysearch) with the correct parameters. 

+# A script with this name will be generated by doxygen.

+

+#CGI_NAME               = search.cgi

+

+# The CGI_URL tag should be the absolute URL to the directory where the 

+# cgi binaries are located. See the documentation of your http daemon for 

+# details.

+

+#CGI_URL                = 

+

+# The DOC_URL tag should be the absolute URL to the directory where the 

+# documentation is located. If left blank the absolute path to the 

+# documentation, with file:// prepended to it, will be used.

+

+#DOC_URL                = 

+

+# The DOC_ABSPATH tag should be the absolute path to the directory where the 

+# documentation is located. If left blank the directory on the local machine 

+# will be used.

+

+#DOC_ABSPATH            = 

+

+# The BIN_ABSPATH tag must point to the directory where the doxysearch binary 

+# is installed.

+

+#BIN_ABSPATH            = /usr/local/bin/

+

+# The EXT_DOC_PATHS tag can be used to specify one or more paths to 

+# documentation generated for other projects. This allows doxysearch to search 

+# the documentation for these projects as well.

+

+#EXT_DOC_PATHS          = 

diff --git a/pjnath/docs/doxygen.css b/pjnath/docs/doxygen.css
new file mode 100644
index 0000000..015c0c2
--- /dev/null
+++ b/pjnath/docs/doxygen.css
@@ -0,0 +1,305 @@
+BODY,H1,H2,H3,H4,H5,H6,P,CENTER,TD,TH,UL,DL,DIV {
+	font-family: Geneva, Arial, Helvetica, sans-serif;
+}
+BODY,TD {
+       font-size: 80%;
+}
+CODE {
+	font-size: 120%;
+       font-family: monospace;
+}
+.fragment, pre {
+	font-size: 110%;
+       font-family: monospace;
+}
+H1 {
+	text-align: center;
+       font-size: 240%;
+}
+H2 {
+       	font-size: 200%;
+	margin-top     : 60px;
+}
+H3 {
+       font-size: 160%;
+}
+H4 {
+       font-size: 120%;
+}
+CAPTION { font-weight: bold }
+DIV.qindex {
+	width: 100%;
+	background-color: #eeeeff;
+	border: 1px solid #b0b0b0;
+	text-align: center;
+	margin: 2px;
+	padding: 2px;
+	line-height: 140%;
+}
+DIV.nav {
+	width: 100%;
+	background-color: #eeeeff;
+	border: 1px solid #b0b0b0;
+	text-align: center;
+	margin: 2px;
+	padding: 2px;
+	line-height: 140%;
+}
+A.qindex {
+       text-decoration: none;
+       font-size: 120%;
+       color: #1A419D;
+}
+A.qindex:visited {
+       text-decoration: none;
+       color: #1A419D
+}
+A.qindex:hover {
+	text-decoration: none;
+	background-color: #ddddff;
+}
+A.qindexHL {
+	text-decoration: none;
+	font-weight: bold;
+	background-color: #6666cc;
+	color: #ffffff;
+	border: 1px double #9295C2;
+}
+A.qindexHL:hover {
+	text-decoration: none;
+	background-color: #6666cc;
+	color: #ffffff;
+}
+A.qindexHL:visited { text-decoration: none; background-color: #6666cc; color: #ffffff }
+A.el { text-decoration: none; font-weight: bold }
+A.elRef { font-weight: bold }
+A.code:link { text-decoration: none; font-weight: normal; color: #0000FF; }
+A.code:visited { text-decoration: none; font-weight: normal; color: #0000FF}
+A.codeRef:link { font-weight: normal; color: #0000FF}
+A.codeRef:visited { font-weight: normal; color: #0000FF}
+A:hover { text-decoration: none; background-color: #f2f2ff }
+DL.el { margin-left: -1cm }
+PRE.fragment {
+	border: 1px solid #CCCCCC;
+	background-color: #f5f5f5;
+	margin-top: 4px;
+	margin-bottom: 4px;
+	margin-left: 2px;
+	margin-right: 8px;
+	padding-left: 6px;
+	padding-right: 6px;
+	padding-top: 4px;
+	padding-bottom: 4px;
+}
+DIV.ah { background-color: black; font-weight: bold; color: #ffffff; margin-bottom: 3px; margin-top: 3px }
+TD.md { background-color: #F4F4FB; font-weight: bold; }
+TD.mdPrefix {
+       background-color: #F4F4FB;
+       color: #606060;
+	font-size: 80%;
+}
+TD.mdname1 { background-color: #F4F4FB; font-weight: bold; color: #602020; }
+TD.mdname { background-color: #F4F4FB; font-weight: bold; color: #602020; width: 600px; }
+DIV.groupHeader {
+       margin-left: 16px;
+       margin-top: 12px;
+       margin-bottom: 6px;
+       font-weight: bold;
+}
+DIV.groupText { margin-left: 16px; font-style: italic; font-size: 90% }
+BODY {
+	background: white;
+	color: black;
+	margin-right: 20px;
+	margin-left: 20px;
+}
+TD.indexkey {
+	background-color: #eeeeff;
+	font-weight: bold;
+	padding-right  : 10px;
+	padding-top    : 2px;
+	padding-left   : 10px;
+	padding-bottom : 2px;
+	margin-left    : 0px;
+	margin-right   : 0px;
+	margin-top     : 2px;
+	margin-bottom  : 2px;
+	border: 1px solid #CCCCCC;
+}
+TD.indexvalue {
+	background-color: #eeeeff;
+	font-style: italic;
+	padding-right  : 10px;
+	padding-top    : 2px;
+	padding-left   : 10px;
+	padding-bottom : 2px;
+	margin-left    : 0px;
+	margin-right   : 0px;
+	margin-top     : 2px;
+	margin-bottom  : 2px;
+	border: 1px solid #CCCCCC;
+}
+TR.memlist {
+   background-color: #f0f0f0; 
+}
+P.formulaDsp { text-align: center; }
+IMG.formulaDsp { }
+IMG.formulaInl { vertical-align: middle; }
+SPAN.keyword       { color: #008000 }
+SPAN.keywordtype   { color: #604020 }
+SPAN.keywordflow   { color: #e08000 }
+SPAN.comment       { color: #800000 }
+SPAN.preprocessor  { color: #806020 }
+SPAN.stringliteral { color: #002080 }
+SPAN.charliteral   { color: #008080 }
+.mdTable {
+	border: 1px solid #868686;
+	background-color: #F4F4FB;
+}
+.mdRow {
+	padding: 8px 10px;
+}
+.mdescLeft {
+       padding: 0px 8px 4px 8px;
+	font-size: 80%;
+	font-style: italic;
+	background-color: #FAFAFA;
+	border-top: 1px none #E0E0E0;
+	border-right: 1px none #E0E0E0;
+	border-bottom: 1px none #E0E0E0;
+	border-left: 1px none #E0E0E0;
+	margin: 0px;
+}
+.mdescRight {
+       padding: 0px 8px 4px 8px;
+	font-size: 80%;
+	font-style: italic;
+	background-color: #FAFAFA;
+	border-top: 1px none #E0E0E0;
+	border-right: 1px none #E0E0E0;
+	border-bottom: 1px none #E0E0E0;
+	border-left: 1px none #E0E0E0;
+	margin: 0px;
+}
+.memItemLeft {
+	padding: 1px 0px 0px 8px;
+	margin: 4px;
+	border-top-width: 1px;
+	border-right-width: 1px;
+	border-bottom-width: 1px;
+	border-left-width: 1px;
+	border-top-color: #E0E0E0;
+	border-right-color: #E0E0E0;
+	border-bottom-color: #E0E0E0;
+	border-left-color: #E0E0E0;
+	border-top-style: solid;
+	border-right-style: none;
+	border-bottom-style: none;
+	border-left-style: none;
+	background-color: #FAFAFA;
+	font-size: 80%;
+}
+.memItemRight {
+	padding: 1px 8px 0px 8px;
+	margin: 4px;
+	border-top-width: 1px;
+	border-right-width: 1px;
+	border-bottom-width: 1px;
+	border-left-width: 1px;
+	border-top-color: #E0E0E0;
+	border-right-color: #E0E0E0;
+	border-bottom-color: #E0E0E0;
+	border-left-color: #E0E0E0;
+	border-top-style: solid;
+	border-right-style: none;
+	border-bottom-style: none;
+	border-left-style: none;
+	background-color: #FAFAFA;
+	font-size: 80%;
+}
+.memTemplItemLeft {
+	padding: 1px 0px 0px 8px;
+	margin: 4px;
+	border-top-width: 1px;
+	border-right-width: 1px;
+	border-bottom-width: 1px;
+	border-left-width: 1px;
+	border-top-color: #E0E0E0;
+	border-right-color: #E0E0E0;
+	border-bottom-color: #E0E0E0;
+	border-left-color: #E0E0E0;
+	border-top-style: none;
+	border-right-style: none;
+	border-bottom-style: none;
+	border-left-style: none;
+	background-color: #FAFAFA;
+	font-size: 80%;
+}
+.memTemplItemRight {
+	padding: 1px 8px 0px 8px;
+	margin: 4px;
+	border-top-width: 1px;
+	border-right-width: 1px;
+	border-bottom-width: 1px;
+	border-left-width: 1px;
+	border-top-color: #E0E0E0;
+	border-right-color: #E0E0E0;
+	border-bottom-color: #E0E0E0;
+	border-left-color: #E0E0E0;
+	border-top-style: none;
+	border-right-style: none;
+	border-bottom-style: none;
+	border-left-style: none;
+	background-color: #FAFAFA;
+	font-size: 80%;
+}
+.memTemplParams {
+	padding: 1px 0px 0px 8px;
+	margin: 4px;
+	border-top-width: 1px;
+	border-right-width: 1px;
+	border-bottom-width: 1px;
+	border-left-width: 1px;
+	border-top-color: #E0E0E0;
+	border-right-color: #E0E0E0;
+	border-bottom-color: #E0E0E0;
+	border-left-color: #E0E0E0;
+	border-top-style: solid;
+	border-right-style: none;
+	border-bottom-style: none;
+	border-left-style: none;
+       color: #606060;
+	background-color: #FAFAFA;
+	font-size: 80%;
+}
+.search     { color: #003399;
+              font-weight: bold;
+}
+FORM.search {
+              margin-bottom: 0px;
+              margin-top: 0px;
+}
+INPUT.search { font-size: 75%;
+               color: #000080;
+               font-weight: normal;
+               background-color: #eeeeff;
+}
+TD.tiny      { font-size: 75%;
+}
+a {
+	color: #252E78;
+}
+a:visited {
+	color: #3D2185;
+}
+.dirtab { padding: 4px;
+          border-collapse: collapse;
+          border: 1px solid #b0b0b0;
+}
+TH.dirtab { background: #eeeeff;
+            font-weight: bold;
+}
+HR { height: 1px;
+     border: none;
+     border-top: 1px solid black;
+}
diff --git a/pjnath/docs/footer.html b/pjnath/docs/footer.html
new file mode 100644
index 0000000..de9b1ec
--- /dev/null
+++ b/pjnath/docs/footer.html
@@ -0,0 +1,12 @@
+	</TD></TD></TABLE>

+<p>&nbsp;</p>

+<hr><center>

+PJNATH - Open Source NAT traversal helper library supporting STUN, TURN, and ICE<br>

+Copyright (C) 2006-2009 Teluu Inc.

+</center>

+

+

+<!--#include virtual="/footer.html" -->

+

+</BODY>

+</HTML>

diff --git a/pjnath/docs/header.html b/pjnath/docs/header.html
new file mode 100644
index 0000000..4d7e263
--- /dev/null
+++ b/pjnath/docs/header.html
@@ -0,0 +1,10 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

+<html><head><meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">

+<title>$title ($projectnumber)</title>

+<link href="/style/style.css" rel="stylesheet" type="text/css">

+</head><body>

+	<!--#include virtual="/header.html" -->

+	<TABLE border=0 width="90%"><TR><TD>

+	<p><A HREF="/">Home</A> --&gt; <A HREF="/docs.htm">Documentations</A> --&gt; <A HREF="/pjnath/docs/html/index.htm">PJNATH Reference</A></p>

+

+

diff --git a/pjnath/docs/ice-arch.jpg b/pjnath/docs/ice-arch.jpg
new file mode 100644
index 0000000..993ce91
--- /dev/null
+++ b/pjnath/docs/ice-arch.jpg
diff --git a/pjnath/docs/ice_demo.jpg b/pjnath/docs/ice_demo.jpg
new file mode 100644
index 0000000..40509ca
--- /dev/null
+++ b/pjnath/docs/ice_demo.jpg
diff --git a/pjnath/docs/pjturn_client.jpg b/pjnath/docs/pjturn_client.jpg
new file mode 100644
index 0000000..250e85d
--- /dev/null
+++ b/pjnath/docs/pjturn_client.jpg
diff --git a/pjnath/docs/stun-arch.jpg b/pjnath/docs/stun-arch.jpg
new file mode 100644
index 0000000..b7b2432
--- /dev/null
+++ b/pjnath/docs/stun-arch.jpg