diff --git a/jni/pjproject-android/.svn/pristine/c5/c5005fbca1c6a9af3a1ce7ee8a073dc8734b6e32.svn-base b/jni/pjproject-android/.svn/pristine/c5/c5005fbca1c6a9af3a1ce7ee8a073dc8734b6e32.svn-base
new file mode 100644
index 0000000..7e4e549
--- /dev/null
+++ b/jni/pjproject-android/.svn/pristine/c5/c5005fbca1c6a9af3a1ce7ee8a073dc8734b6e32.svn-base
@@ -0,0 +1,26 @@
+# $Id$
+import inc_sip as sip
+import inc_sdp as sdp
+
+sdp = \
+"""
+v=0
+o=- 0 0 IN IP4 127.0.0.1
+s=tester
+c=IN IP4 127.0.0.1
+t=0 0
+m=audio 4000 RTP/AVP 0 101
+a=rtpmap:0 PCMU/8000
+a=sendrecv
+a=rtpmap:101 telephone-event/8000
+a=fmtp:101 0-15
+a=crypto:0 AES_CM_128_HMAC_SHA1_80 inline:WnD7c1ksDGs+dIefCEo8omPg4uO8DYIinNGL5yxQ
+"""
+
+args = "--null-audio --auto-answer 200 --max-calls 1 --use-srtp 1 --srtp-secure 0"
+include = []
+exclude = []
+
+sendto_cfg = sip.SendtoCfg( "caller has used crypto tag zero, callee must accept the call", 
+			    pjsua_args=args, sdp=sdp, resp_code=200, 
+			    resp_inc=include, resp_exc=exclude)
diff --git a/jni/pjproject-android/.svn/pristine/c5/c52c7c648d616276fa97996ffd0bccb670523d07.svn-base b/jni/pjproject-android/.svn/pristine/c5/c52c7c648d616276fa97996ffd0bccb670523d07.svn-base
new file mode 100644
index 0000000..ecc0648
--- /dev/null
+++ b/jni/pjproject-android/.svn/pristine/c5/c52c7c648d616276fa97996ffd0bccb670523d07.svn-base
@@ -0,0 +1,3139 @@
+
+
+
+
+
+
+Network Working Group                                         M. Baugher
+Request for Comments: 3711                                     D. McGrew
+Category: Standards Track                            Cisco Systems, Inc.
+                                                              M. Naslund
+                                                              E. Carrara
+                                                              K. Norrman
+                                                       Ericsson Research
+                                                              March 2004
+
+
+             The Secure Real-time Transport Protocol (SRTP)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document describes the Secure Real-time Transport Protocol
+   (SRTP), a profile of the Real-time Transport Protocol (RTP), which
+   can provide confidentiality, message authentication, and replay
+   protection to the RTP traffic and to the control traffic for RTP, the
+   Real-time Transport Control Protocol (RTCP).
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.1.  Notational Conventions . . . . . . . . . . . . . . . . .  3
+   2.  Goals and Features . . . . . . . . . . . . . . . . . . . . . .  4
+       2.1.  Features . . . . . . . . . . . . . . . . . . . . . . . .  5
+   3.  SRTP Framework . . . . . . . . . . . . . . . . . . . . . . . .  5
+       3.1.  Secure RTP . . . . . . . . . . . . . . . . . . . . . . .  6
+       3.2.  SRTP Cryptographic Contexts. . . . . . . . . . . . . . .  7
+             3.2.1.  Transform-independent parameters . . . . . . . .  8
+             3.2.2.  Transform-dependent parameters . . . . . . . . . 10
+             3.2.3.  Mapping SRTP Packets to Cryptographic Contexts . 10
+       3.3.  SRTP Packet Processing . . . . . . . . . . . . . . . . . 11
+             3.3.1.  Packet Index Determination, and ROC, s_l Update. 13
+             3.3.2.  Replay Protection. . . . . . . . . . . . . . . . 15
+      3.4.  Secure RTCP . . . . . . . . . . . . . . . . . . . . . . . 15
+
+
+
+Baugher, et al.             Standards Track                     [Page 1]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   4.  Pre-Defined Cryptographic Transforms . . . . . . . . . . . . . 19
+       4.1.  Encryption . . . . . . . . . . . . . . . . . . . . . . . 19
+             4.1.1.  AES in Counter Mode. . . . . . . . . . . . . . . 21
+             4.1.2.  AES in f8-mode . . . . . . . . . . . . . . . . . 22
+             4.1.3.  NULL Cipher. . . . . . . . . . . . . . . . . . . 25
+       4.2.  Message Authentication and Integrity . . . . . . . . . . 25
+             4.2.1.  HMAC-SHA1. . . . . . . . . . . . . . . . . . . . 25
+       4.3.  Key Derivation . . . . . . . . . . . . . . . . . . . . . 26
+             4.3.1.  Key Derivation Algorithm . . . . . . . . . . . . 26
+             4.3.2.  SRTCP Key Derivation . . . . . . . . . . . . . . 28
+             4.3.3.  AES-CM PRF . . . . . . . . . . . . . . . . . . . 28
+   5.  Default and mandatory-to-implement Transforms. . . . . . . . . 28
+       5.1.  Encryption: AES-CM and NULL. . . . . . . . . . . . . . . 29
+       5.2.  Message Authentication/Integrity: HMAC-SHA1. . . . . . . 29
+       5.3.  Key Derivation: AES-CM PRF . . . . . . . . . . . . . . . 29
+   6.  Adding SRTP Transforms . . . . . . . . . . . . . . . . . . . . 29
+   7.  Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
+       7.1.  Key derivation . . . . . . . . . . . . . . . . . . . . . 30
+       7.2.  Salting key. . . . . . . . . . . . . . . . . . . . . . . 30
+       7.3.  Message Integrity from Universal Hashing . . . . . . . . 31
+       7.4.  Data Origin Authentication Considerations. . . . . . . . 31
+       7.5.  Short and Zero-length Message Authentication . . . . . . 32
+   8.  Key Management Considerations. . . . . . . . . . . . . . . . . 33
+       8.1.  Re-keying  . . . . . . . . . . . . . . . . . . . . . . . 34
+             8.1.1.  Use of the <From, To> for re-keying. . . . . . . 34
+       8.2.  Key Management parameters. . . . . . . . . . . . . . . . 35
+   9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 37
+       9.1.  SSRC collision and two-time pad. . . . . . . . . . . . . 37
+       9.2.  Key Usage. . . . . . . . . . . . . . . . . . . . . . . . 38
+       9.3.  Confidentiality of the RTP Payload . . . . . . . . . . . 39
+       9.4.  Confidentiality of the RTP Header. . . . . . . . . . . . 40
+       9.5.  Integrity of the RTP payload and header. . . . . . . . . 40
+             9.5.1. Risks of Weak or Null Message Authentication. . . 42
+             9.5.2.  Implicit Header Authentication . . . . . . . . . 43
+   10.  Interaction with Forward Error Correction mechanisms. . . . . 43
+   11.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 43
+       11.1. Unicast. . . . . . . . . . . . . . . . . . . . . . . . . 43
+       11.2. Multicast (one sender) . . . . . . . . . . . . . . . . . 44
+       11.3. Re-keying and access control . . . . . . . . . . . . . . 45
+       11.4. Summary of basic scenarios . . . . . . . . . . . . . . . 46
+   12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 46
+   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
+   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
+       14.1. Normative References . . . . . . . . . . . . . . . . . . 47
+       14.2. Informative References . . . . . . . . . . . . . . . . . 48
+   Appendix A: Pseudocode for Index Determination . . . . . . . . . . 51
+   Appendix B: Test Vectors . . . . . . . . . . . . . . . . . . . . . 51
+       B.1.  AES-f8 Test Vectors. . . . . . . . . . . . . . . . . . . 51
+
+
+
+Baugher, et al.             Standards Track                     [Page 2]
+
+RFC 3711                          SRTP                        March 2004
+
+
+       B.2.  AES-CM Test Vectors. . . . . . . . . . . . . . . . . . . 52
+       B.3.  Key Derivation Test Vectors. . . . . . . . . . . . . . . 53
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 56
+
+1.  Introduction
+
+   This document describes the Secure Real-time Transport Protocol
+   (SRTP), a profile of the Real-time Transport Protocol (RTP), which
+   can provide confidentiality, message authentication, and replay
+   protection to the RTP traffic and to the control traffic for RTP,
+   RTCP (the Real-time Transport Control Protocol) [RFC3350].
+
+   SRTP provides a framework for encryption and message authentication
+   of RTP and RTCP streams (Section 3).  SRTP defines a set of default
+   cryptographic transforms (Sections 4 and 5), and it allows new
+   transforms to be introduced in the future (Section 6).  With
+   appropriate key management (Sections 7 and 8), SRTP is secure
+   (Sections 9) for unicast and multicast RTP applications (Section 11).
+
+   SRTP can achieve high throughput and low packet expansion.  SRTP
+   proves to be a suitable protection for heterogeneous environments
+   (mix of wired and wireless networks).  To get such features, default
+   transforms are described, based on an additive stream cipher for
+   encryption, a keyed-hash based function for message authentication,
+   and an "implicit" index for sequencing/synchronization based on the
+   RTP sequence number for SRTP and an index number for Secure RTCP
+   (SRTCP).
+
+1.1.  Notational Conventions
+
+   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].  The
+   terminology conforms to [RFC2828] with the following exception.  For
+   simplicity we use the term "random" throughout the document to denote
+   randomly or pseudo-randomly generated values.  Large amounts of
+   random bits may be difficult to obtain, and for the security of SRTP,
+   pseudo-randomness is sufficient [RFC1750].
+
+   By convention, the adopted representation is the network byte order,
+   i.e., the left most bit (octet) is the most significant one.  By XOR
+   we mean bitwise addition modulo 2 of binary strings, and || denotes
+   concatenation.  In other words, if C = A || B, then the most
+   significant bits of C are the bits of A, and the least significant
+   bits of C equal the bits of B.  Hexadecimal numbers are prefixed by
+   0x.
+
+
+
+
+Baugher, et al.             Standards Track                     [Page 3]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   The word "encryption" includes also use of the NULL algorithm (which
+   in practice does leave the data in the clear).
+
+   With slight abuse of notation, we use the terms "message
+   authentication" and "authentication tag" as is common practice, even
+   though in some circumstances, e.g., group communication, the service
+   provided is actually only integrity protection and not data origin
+   authentication.
+
+2.  Goals and Features
+
+   The security goals for SRTP are to ensure:
+
+   *  the confidentiality of the RTP and RTCP payloads, and
+
+   *  the integrity of the entire RTP and RTCP packets, together with
+      protection against replayed packets.
+
+   These security services are optional and independent from each other,
+   except that SRTCP integrity protection is mandatory (malicious or
+   erroneous alteration of RTCP messages could otherwise disrupt the
+   processing of the RTP stream).
+
+   Other, functional, goals for the protocol are:
+
+   *  a framework that permits upgrading with new cryptographic
+      transforms,
+
+   *  low bandwidth cost, i.e., a framework preserving RTP header
+      compression efficiency,
+
+   and, asserted by the pre-defined transforms:
+
+   *  a low computational cost,
+
+   *  a small footprint (i.e., small code size and data memory for
+      keying information and replay lists),
+
+   *  limited packet expansion to support the bandwidth economy goal,
+
+   *  independence from the underlying transport, network, and physical
+      layers used by RTP, in particular high tolerance to packet loss
+      and re-ordering.
+
+   These properties ensure that SRTP is a suitable protection scheme for
+   RTP/RTCP in both wired and wireless scenarios.
+
+
+
+
+
+Baugher, et al.             Standards Track                     [Page 4]
+
+RFC 3711                          SRTP                        March 2004
+
+
+2.1.  Features
+
+   Besides the above mentioned direct goals, SRTP provides for some
+   additional features.  They have been introduced to lighten the burden
+   on key management and to further increase security.  They include:
+
+   *  A single "master key" can provide keying material for
+      confidentiality and integrity protection, both for the SRTP stream
+      and the corresponding SRTCP stream.  This is achieved with a key
+      derivation function (see Section 4.3), providing "session keys"
+      for the respective security primitive, securely derived from the
+      master key.
+
+   *  In addition, the key derivation can be configured to periodically
+      refresh the session keys, which limits the amount of ciphertext
+      produced by a fixed key, available for an adversary to
+      cryptanalyze.
+
+   *  "Salting keys" are used to protect against pre-computation and
+      time-memory tradeoff attacks [MF00] [BS00].
+
+   Detailed rationale for these features can be found in Section 7.
+
+3.  SRTP Framework
+
+   RTP is the Real-time Transport Protocol [RFC3550].  We define SRTP as
+   a profile of RTP.  This profile is an extension to the RTP
+   Audio/Video Profile [RFC3551].  Except where explicitly noted, all
+   aspects of that profile apply, with the addition of the SRTP security
+   features.  Conceptually, we consider SRTP to be a "bump in the stack"
+   implementation which resides between the RTP application and the
+   transport layer.  SRTP intercepts RTP packets and then forwards an
+   equivalent SRTP packet on the sending side, and intercepts SRTP
+   packets and passes an equivalent RTP packet up the stack on the
+   receiving side.
+
+   Secure RTCP (SRTCP) provides the same security services to RTCP as
+   SRTP does to RTP.  SRTCP message authentication is MANDATORY and
+   thereby protects the RTCP fields to keep track of membership, provide
+   feedback to RTP senders, or maintain packet sequence counters.  SRTCP
+   is described in Section 3.4.
+
+
+
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                     [Page 5]
+
+RFC 3711                          SRTP                        March 2004
+
+
+3.1.  Secure RTP
+
+      The format of an SRTP packet is illustrated in Figure 1.
+
+        0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
+     |V=2|P|X|  CC   |M|     PT      |       sequence number         | |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+     |                           timestamp                           | |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+     |           synchronization source (SSRC) identifier            | |
+     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
+     |            contributing source (CSRC) identifiers             | |
+     |                               ....                            | |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+     |                   RTP extension (OPTIONAL)                    | |
+   +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+   | |                          payload  ...                         | |
+   | |                               +-------------------------------+ |
+   | |                               | RTP padding   | RTP pad count | |
+   +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
+   | ~                     SRTP MKI (OPTIONAL)                       ~ |
+   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+   | :                 authentication tag (RECOMMENDED)              : |
+   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+   |                                                                   |
+   +- Encrypted Portion*                      Authenticated Portion ---+
+
+   Figure 1.  The format of an SRTP packet.  *Encrypted Portion is the
+   same size as the plaintext for the Section 4 pre-defined transforms.
+
+   The "Encrypted Portion" of an SRTP packet consists of the encryption
+   of the RTP payload (including RTP padding when present) of the
+   equivalent RTP packet.  The Encrypted Portion MAY be the exact size
+   of the plaintext or MAY be larger.  Figure 1 shows the RTP payload
+   including any possible padding for RTP [RFC3550].
+
+   None of the pre-defined encryption transforms uses any padding; for
+   these, the RTP and SRTP payload sizes match exactly.  New transforms
+   added to SRTP (following Section 6) may require padding, and may
+   hence produce larger payloads.  RTP provides its own padding format
+   (as seen in Fig. 1), which due to the padding indicator in the RTP
+   header has merits in terms of compactness relative to paddings using
+   prefix-free codes.  This RTP padding SHALL be the default method for
+   transforms requiring padding.  Transforms MAY specify other padding
+   methods, and MUST then specify the amount, format, and processing of
+   their padding.  It is important to note that encryption transforms
+
+
+
+Baugher, et al.             Standards Track                     [Page 6]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   that use padding are vulnerable to subtle attacks, especially when
+   message authentication is not used [V02].  Each specification for a
+   new encryption transform needs to carefully consider and describe the
+   security implications of the padding that it uses.  Message
+   authentication codes define their own padding, so this default does
+   not apply to authentication transforms.
+
+   The OPTIONAL MKI and the RECOMMENDED authentication tag are the only
+   fields defined by SRTP that are not in RTP.  Only 8-bit alignment is
+   assumed.
+
+      MKI (Master Key Identifier): configurable length, OPTIONAL.  The
+              MKI is defined, signaled, and used by key management.  The
+              MKI identifies the master key from which the session
+              key(s) were derived that authenticate and/or encrypt the
+              particular packet.  Note that the MKI SHALL NOT identify
+              the SRTP cryptographic context, which is identified
+              according to Section 3.2.3.  The MKI MAY be used by key
+              management for the purposes of re-keying, identifying a
+              particular master key within the cryptographic context
+              (Section 3.2.1).
+
+      Authentication tag: configurable length, RECOMMENDED.  The
+              authentication tag is used to carry message authentication
+              data.  The Authenticated Portion of an SRTP packet
+              consists of the RTP header followed by the Encrypted
+              Portion of the SRTP packet.  Thus, if both encryption and
+              authentication are applied, encryption SHALL be applied
+              before authentication on the sender side and conversely on
+              the receiver side.  The authentication tag provides
+              authentication of the RTP header and payload, and it
+              indirectly provides replay protection by authenticating
+              the sequence number.  Note that the MKI is not integrity
+              protected as this does not provide any extra protection.
+
+3.2.  SRTP Cryptographic Contexts
+
+   Each SRTP stream requires the sender and receiver to maintain
+   cryptographic state information.  This information is called the
+   "cryptographic context".
+
+   SRTP uses two types of keys: session keys and master keys.  By a
+   "session key", we mean a key which is used directly in a
+   cryptographic transform (e.g., encryption or message authentication),
+   and by a "master key", we mean a random bit string (given by the key
+   management protocol) from which session keys are derived in a
+
+
+
+
+
+Baugher, et al.             Standards Track                     [Page 7]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   cryptographically secure way.  The master key(s) and other parameters
+   in the cryptographic context are provided by key management
+   mechanisms external to SRTP, see Section 8.
+
+3.2.1.  Transform-independent parameters
+
+   Transform-independent parameters are present in the cryptographic
+   context independently of the particular encryption or authentication
+   transforms that are used.  The transform-independent parameters of
+   the cryptographic context for SRTP consist of:
+
+   *  a 32-bit unsigned rollover counter (ROC), which records how many
+      times the 16-bit RTP sequence number has been reset to zero after
+      passing through 65,535.  Unlike the sequence number (SEQ), which
+      SRTP extracts from the RTP packet header, the ROC is maintained by
+      SRTP as described in Section 3.3.1.
+
+      We define the index of the SRTP packet corresponding to a given
+      ROC and RTP sequence number to be the 48-bit quantity
+
+            i = 2^16 * ROC + SEQ.
+
+   *  for the receiver only, a 16-bit sequence number s_l, which can be
+      thought of as the highest received RTP sequence number (see
+      Section 3.3.1 for its handling), which SHOULD be authenticated
+      since message authentication is RECOMMENDED,
+
+   *  an identifier for the encryption algorithm, i.e., the cipher and
+      its mode of operation,
+
+   *  an identifier for the message authentication algorithm,
+
+   *  a replay list, maintained by the receiver only (when
+      authentication and replay protection are provided), containing
+      indices of recently received and authenticated SRTP packets,
+
+   *  an MKI indicator (0/1) as to whether an MKI is present in SRTP and
+      SRTCP packets,
+
+   *  if the MKI indicator is set to one, the length (in octets) of the
+      MKI field, and (for the sender) the actual value of the currently
+      active MKI (the value of the MKI indicator and length MUST be kept
+      fixed for the lifetime of the context),
+
+   *  the master key(s), which MUST be random and kept secret,
+
+
+
+
+
+
+Baugher, et al.             Standards Track                     [Page 8]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   *  for each master key, there is a counter of the number of SRTP
+      packets that have been processed (sent) with that master key
+      (essential for security, see Sections 3.3.1 and 9),
+
+   *  non-negative integers n_e, and n_a, determining the length of the
+      session keys for encryption, and message authentication.
+
+   In addition, for each master key, an SRTP stream MAY use the
+   following associated values:
+
+   *  a master salt, to be used in the key derivation of session keys.
+      This value, when used, MUST be random, but MAY be public.  Use of
+      master salt is strongly RECOMMENDED, see Section 9.2.  A "NULL"
+      salt is treated as 00...0.
+
+   *  an integer in the set {1,2,4,...,2^24}, the "key_derivation_rate",
+      where an unspecified value is treated as zero.  The constraint to
+      be a power of 2 simplifies the session-key derivation
+      implementation, see Section 4.3.
+
+   *  an MKI value,
+
+   *  <From, To> values, specifying the lifetime for a master key,
+      expressed in terms of the two 48-bit index values inside whose
+      range (including the range end-points) the master key is valid.
+      For the use of <From, To>, see Section 8.1.1.  <From, To> is an
+      alternative to the MKI and assumes that a master key is in one-
+      to-one correspondence with the SRTP session key on which the
+      <From, To> range is defined.
+
+   SRTCP SHALL by default share the crypto context with SRTP, except:
+
+   *  no rollover counter and s_l-value need to be maintained as the
+      RTCP index is explicitly carried in each SRTCP packet,
+
+   *  a separate replay list is maintained (when replay protection is
+      provided),
+
+   *  SRTCP maintains a separate counter for its master key (even if the
+      master key is the same as that for SRTP, see below), as a means to
+      maintain a count of the number of SRTCP packets that have been
+      processed with that key.
+
+   Note in particular that the master key(s) MAY be shared between SRTP
+   and the corresponding SRTCP, if the pre-defined transforms (including
+   the key derivation) are used but the session key(s) MUST NOT be so
+   shared.
+
+
+
+
+Baugher, et al.             Standards Track                     [Page 9]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   In addition, there can be cases (see Sections 8 and 9.1) where
+   several SRTP streams within a given RTP session, identified by their
+   synchronization source (SSRCs, which is part of the RTP header),
+   share most of the crypto context parameters (including possibly
+   master and session keys).  In such cases, just as in the normal
+   SRTP/SRTCP parameter sharing above, separate replay lists and packet
+   counters for each stream (SSRC) MUST still be maintained.  Also,
+   separate SRTP indices MUST then be maintained.
+
+   A summary of parameters, pre-defined transforms, and default values
+   for the above parameters (and other SRTP parameters) can be found in
+   Sections 5 and 8.2.
+
+3.2.2.  Transform-dependent parameters
+
+   All encryption, authentication/integrity, and key derivation
+   parameters are defined in the transforms section (Section 4).
+   Typical examples of such parameters are block size of ciphers,
+   session keys, data for the Initialization Vector (IV) formation, etc.
+   Future SRTP transform specifications MUST include a section to list
+   the additional cryptographic context's parameters for that transform,
+   if any.
+
+3.2.3.  Mapping SRTP Packets to Cryptographic Contexts
+
+   Recall that an RTP session for each participant is defined [RFC3550]
+   by a pair of destination transport addresses (one network address
+   plus a port pair for RTP and RTCP), and that a multimedia session is
+   defined as a collection of RTP sessions.  For example, a particular
+   multimedia session could include an audio RTP session, a video RTP
+   session, and a text RTP session.
+
+   A cryptographic context SHALL be uniquely identified by the triplet
+   context identifier:
+
+   context id = <SSRC, destination network address, destination
+   transport port number>
+
+   where the destination network address and the destination transport
+   port are the ones in the SRTP packet.  It is assumed that, when
+   presented with this information, the key management returns a context
+   with the information as described in Section 3.2.
+
+   As noted above, SRTP and SRTCP by default share the bulk of the
+   parameters in the cryptographic context.  Thus, retrieving the crypto
+   context parameters for an SRTCP stream in practice may imply a
+   binding to the correspondent SRTP crypto context.  It is up to the
+   implementation to assure such binding, since the RTCP port may not be
+
+
+
+Baugher, et al.             Standards Track                    [Page 10]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   directly deducible from the RTP port only.  Alternatively, the key
+   management may choose to provide separate SRTP- and SRTCP- contexts,
+   duplicating the common parameters (such as master key(s)).  The
+   latter approach then also enables SRTP and SRTCP to use, e.g.,
+   distinct transforms, if so desired.  Similar considerations arise
+   when multiple SRTP streams, forming part of one single RTP session,
+   share keys and other parameters.
+
+   If no valid context can be found for a packet corresponding to a
+   certain context identifier, that packet MUST be discarded.
+
+3.3.  SRTP Packet Processing
+
+   The following applies to SRTP.  SRTCP is described in Section 3.4.
+
+   Assuming initialization of the cryptographic context(s) has taken
+   place via key management, the sender SHALL do the following to
+   construct an SRTP packet:
+
+   1. Determine which cryptographic context to use as described in
+      Section 3.2.3.
+
+   2. Determine the index of the SRTP packet using the rollover counter,
+      the highest sequence number in the cryptographic context, and the
+      sequence number in the RTP packet, as described in Section 3.3.1.
+
+   3. Determine the master key and master salt.  This is done using the
+      index determined in the previous step or the current MKI in the
+      cryptographic context, according to Section 8.1.
+
+   4. Determine the session keys and session salt (if they are used by
+      the transform) as described in Section 4.3, using master key,
+      master salt, key_derivation_rate, and session key-lengths in the
+      cryptographic context with the index, determined in Steps 2 and 3.
+
+   5. Encrypt the RTP payload to produce the Encrypted Portion of the
+      packet (see Section 4.1, for the defined ciphers).  This step uses
+      the encryption algorithm indicated in the cryptographic context,
+      the session encryption key and the session salt (if used) found in
+      Step 4 together with the index found in Step 2.
+
+   6. If the MKI indicator is set to one, append the MKI to the packet.
+
+   7. For message authentication, compute the authentication tag for the
+      Authenticated Portion of the packet, as described in Section 4.2.
+      This step uses the current rollover counter, the authentication
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 11]
+
+RFC 3711                          SRTP                        March 2004
+
+
+      algorithm indicated in the cryptographic context, and the session
+      authentication key found in Step 4.  Append the authentication tag
+      to the packet.
+
+   8. If necessary, update the ROC as in Section 3.3.1, using the packet
+      index determined in Step 2.
+
+   To authenticate and decrypt an SRTP packet, the receiver SHALL do the
+   following:
+
+   1. Determine which cryptographic context to use as described in
+      Section 3.2.3.
+
+   2. Run the algorithm in Section 3.3.1 to get the index of the SRTP
+      packet.  The algorithm uses the rollover counter and highest
+      sequence number in the cryptographic context with the sequence
+      number in the SRTP packet, as described in Section 3.3.1.
+
+   3. Determine the master key and master salt.  If the MKI indicator in
+      the context is set to one, use the MKI in the SRTP packet,
+      otherwise use the index from the previous step, according to
+      Section 8.1.
+
+   4. Determine the session keys, and session salt (if used by the
+      transform) as described in Section 4.3, using master key, master
+      salt, key_derivation_rate and session key-lengths in the
+      cryptographic context with the index, determined in Steps 2 and 3.
+
+   5. For message authentication and replay protection, first check if
+      the packet has been replayed (Section 3.3.2), using the Replay
+      List and the index as determined in Step 2.  If the packet is
+      judged to be replayed, then the packet MUST be discarded, and the
+      event SHOULD be logged.
+
+      Next, perform verification of the authentication tag, using the
+      rollover counter from Step 2, the authentication algorithm
+      indicated in the cryptographic context, and the session
+      authentication key from Step 4.  If the result is "AUTHENTICATION
+      FAILURE" (see Section 4.2), the packet MUST be discarded from
+      further processing and the event SHOULD be logged.
+
+   6. Decrypt the Encrypted Portion of the packet (see Section 4.1, for
+      the defined ciphers), using the decryption algorithm indicated in
+      the cryptographic context, the session encryption key and salt (if
+      used) found in Step 4 with the index from Step 2.
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 12]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   7. Update the rollover counter and highest sequence number, s_l, in
+      the cryptographic context as in Section 3.3.1, using the packet
+      index estimated in Step 2.  If replay protection is provided, also
+      update the Replay List as described in Section 3.3.2.
+
+   8. When present, remove the MKI and authentication tag fields from
+      the packet.
+
+3.3.1.  Packet Index Determination, and ROC, s_l Update
+
+   SRTP implementations use an "implicit" packet index for sequencing,
+   i.e., not all of the index is explicitly carried in the SRTP packet.
+   For the pre-defined transforms, the index i is used in replay
+   protection (Section 3.3.2), encryption (Section 4.1), message
+   authentication (Section 4.2), and for the key derivation (Section
+   4.3).
+
+   When the session starts, the sender side MUST set the rollover
+   counter, ROC, to zero.  Each time the RTP sequence number, SEQ, wraps
+   modulo 2^16, the sender side MUST increment ROC by one, modulo 2^32
+   (see security aspects below).  The sender's packet index is then
+   defined as
+
+      i = 2^16 * ROC + SEQ.
+
+   Receiver-side implementations use the RTP sequence number to
+   determine the correct index of a packet, which is the location of the
+   packet in the sequence of all SRTP packets.  A robust approach for
+   the proper use of a rollover counter requires its handling and use to
+   be well defined.  In particular, out-of-order RTP packets with
+   sequence numbers close to 2^16 or zero must be properly handled.
+
+   The index estimate is based on the receiver's locally maintained ROC
+   and s_l values.  At the setup of the session, the ROC MUST be set to
+   zero.  Receivers joining an on-going session MUST be given the
+   current ROC value using out-of-band signaling such as key-management
+   signaling.  Furthermore, the receiver SHALL initialize s_l to the RTP
+   sequence number (SEQ) of the first observed SRTP packet (unless the
+   initial value is provided by out of band signaling such as key
+   management).
+
+   On consecutive SRTP packets, the receiver SHOULD estimate the index
+   as
+         i = 2^16 * v + SEQ,
+
+   where v is chosen from the set { ROC-1, ROC, ROC+1 } (modulo 2^32)
+   such that i is closest (in modulo 2^48 sense) to the value 2^16 * ROC
+   + s_l (see Appendix A for pseudocode).
+
+
+
+Baugher, et al.             Standards Track                    [Page 13]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   After the packet has been processed and authenticated (when enabled
+   for SRTP packets for the session), the receiver MUST use v to
+   conditionally update its s_l and ROC variables as follows.  If
+   v=(ROC-1) mod 2^32, then there is no update to s_l or ROC.  If v=ROC,
+   then s_l is set to SEQ if and only if SEQ is larger than the current
+   s_l; there is no change to ROC.  If v=(ROC+1) mod 2^32, then s_l is
+   set to SEQ and ROC is set to v.
+
+   After a re-keying occurs (changing to a new master key), the rollover
+   counter always maintains its sequence of values, i.e., it MUST NOT be
+   reset to zero.
+
+   As the rollover counter is 32 bits long and the sequence number is 16
+   bits long, the maximum number of packets belonging to a given SRTP
+   stream that can be secured with the same key is 2^48 using the pre-
+   defined transforms.  After that number of SRTP packets have been sent
+   with a given (master or session) key, the sender MUST NOT send any
+   more packets with that key.  (There exists a similar limit for SRTCP,
+   which in practice may be more restrictive, see Section 9.2.)  This
+   limitation enforces a security benefit by providing an upper bound on
+   the amount of traffic that can pass before cryptographic keys are
+   changed.  Re-keying (see Section 8.1) MUST be triggered, before this
+   amount of traffic, and MAY be triggered earlier, e.g., for increased
+   security and access control to media.  Recurring key derivation by
+   means of a non-zero key_derivation_rate (see Section 4.3), also gives
+   stronger security but does not change the above absolute maximum
+   value.
+
+   On the receiver side, there is a caveat to updating s_l and ROC: if
+   message authentication is not present, neither the initialization of
+   s_l, nor the ROC update can be made completely robust.  The
+   receiver's "implicit index" approach works for the pre-defined
+   transforms as long as the reorder and loss of the packets are not too
+   great and bit-errors do not occur in unfortunate ways.  In
+   particular, 2^15 packets would need to be lost, or a packet would
+   need to be 2^15 packets out of sequence before synchronization is
+   lost.  Such drastic loss or reorder is likely to disrupt the RTP
+   application itself.
+
+   The algorithm for the index estimate and ROC update is a matter of
+   implementation, and should take into consideration the environment
+   (e.g., packet loss rate) and the cases when synchronization is likely
+   to be lost, e.g., when the initial sequence number (randomly chosen
+   by RTP) is not known in advance (not sent in the key management
+   protocol) but may be near to wrap modulo 2^16.
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 14]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   A more elaborate and more robust scheme than the one given above is
+   the handling of RTP's own "rollover counter", see Appendix A.1 of
+   [RFC3550].
+
+3.3.2.  Replay Protection
+
+   Secure replay protection is only possible when integrity protection
+   is present.  It is RECOMMENDED to use replay protection, both for RTP
+   and RTCP, as integrity protection alone cannot assure security
+   against replay attacks.
+
+   A packet is "replayed" when it is stored by an adversary, and then
+   re-injected into the network.  When message authentication is
+   provided, SRTP protects against such attacks through a Replay List.
+   Each SRTP receiver maintains a Replay List, which conceptually
+   contains the indices of all of the packets which have been received
+   and authenticated.  In practice, the list can use a "sliding window"
+   approach, so that a fixed amount of storage suffices for replay
+   protection.  Packet indices which lag behind the packet index in the
+   context by more than SRTP-WINDOW-SIZE can be assumed to have been
+   received, where SRTP-WINDOW-SIZE is a receiver-side, implementation-
+   dependent parameter and MUST be at least 64, but which MAY be set to
+   a higher value.
+
+   The receiver checks the index of an incoming packet against the
+   replay list and the window.  Only packets with index ahead of the
+   window, or, inside the window but not already received, SHALL be
+   accepted.
+
+   After the packet has been authenticated (if necessary the window is
+   first moved ahead), the replay list SHALL be updated with the new
+   index.
+
+   The Replay List can be efficiently implemented by using a bitmap to
+   represent which packets have been received, as described in the
+   Security Architecture for IP [RFC2401].
+
+3.4.  Secure RTCP
+
+   Secure RTCP follows the definition of Secure RTP.  SRTCP adds three
+   mandatory new fields (the SRTCP index, an "encrypt-flag", and the
+   authentication tag) and one optional field (the MKI) to the RTCP
+   packet definition.  The three mandatory fields MUST be appended to an
+   RTCP packet in order to form an equivalent SRTCP packet.  The added
+   fields follow any other profile-specific extensions.
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 15]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   According to Section 6.1 of [RFC3550], there is a REQUIRED packet
+   format for compound packets.  SRTCP MUST be given packets according
+   to that requirement in the sense that the first part MUST be a sender
+   report or a receiver report.  However, the RTCP encryption prefix (a
+   random 32-bit quantity) specified in that Section MUST NOT be used
+   since, as is stated there, it is only applicable to the encryption
+   method specified in [RFC3550] and is not needed by the cryptographic
+   mechanisms used in SRTP.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
+     |V=2|P|    RC   |   PT=SR or RR   |             length          | |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+     |                         SSRC of sender                        | |
+   +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
+   | ~                          sender info                          ~ |
+   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+   | ~                         report block 1                        ~ |
+   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+   | ~                         report block 2                        ~ |
+   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+   | ~                              ...                              ~ |
+   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+   | |V=2|P|    SC   |  PT=SDES=202  |             length            | |
+   | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
+   | |                          SSRC/CSRC_1                          | |
+   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+   | ~                           SDES items                          ~ |
+   | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
+   | ~                              ...                              ~ |
+   +>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
+   | |E|                         SRTCP index                         | |
+   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
+   | ~                     SRTCP MKI (OPTIONAL)                      ~ |
+   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+   | :                     authentication tag                        : |
+   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+   |                                                                   |
+   +-- Encrypted Portion                    Authenticated Portion -----+
+
+
+   Figure 2.  An example of the format of a Secure RTCP packet,
+   consisting of an underlying RTCP compound packet with a Sender Report
+   and SDES packet.
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 16]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   The Encrypted Portion of an SRTCP packet consists of the encryption
+   (Section 4.1) of the RTCP payload of the equivalent compound RTCP
+   packet, from the first RTCP packet, i.e., from the ninth (9) octet to
+   the end of the compound packet.  The Authenticated Portion of an
+   SRTCP packet consists of the entire equivalent (eventually compound)
+   RTCP packet, the E flag, and the SRTCP index (after any encryption
+   has been applied to the payload).
+
+   The added fields are:
+
+   E-flag: 1 bit, REQUIRED
+            The E-flag indicates if the current SRTCP packet is
+            encrypted or unencrypted.  Section 9.1 of [RFC3550] allows
+            the split of a compound RTCP packet into two lower-layer
+            packets, one to be encrypted and one to be sent in the
+            clear.  The E bit set to "1" indicates encrypted packet, and
+            "0" indicates non-encrypted packet.
+
+   SRTCP index: 31 bits, REQUIRED
+            The SRTCP index is a 31-bit counter for the SRTCP packet.
+            The index is explicitly included in each packet, in contrast
+            to the "implicit" index approach used for SRTP.  The SRTCP
+            index MUST be set to zero before the first SRTCP packet is
+            sent, and MUST be incremented by one, modulo 2^31, after
+            each SRTCP packet is sent.  In particular, after a re-key,
+            the SRTCP index MUST NOT be reset to zero again.
+
+   Authentication Tag: configurable length, REQUIRED
+            The authentication tag is used to carry message
+            authentication data.
+
+   MKI: configurable length, OPTIONAL
+            The MKI is the Master Key Indicator, and functions according
+            to the MKI definition in Section 3.
+
+   SRTCP uses the cryptographic context parameters and packet processing
+   of SRTP by default, with the following changes:
+
+   *  The receiver does not need to "estimate" the index, as it is
+      explicitly signaled in the packet.
+
+   *  Pre-defined SRTCP encryption is as specified in Section 4.1, but
+      using the definition of the SRTCP Encrypted Portion given in this
+      section, and using the SRTCP index as the index i.  The encryption
+      transform and related parameters SHALL by default be the same
+      selected for the protection of the associated SRTP stream(s),
+      while the NULL algorithm SHALL be applied to the RTCP packets not
+      to be encrypted.  SRTCP may have a different encryption transform
+
+
+
+Baugher, et al.             Standards Track                    [Page 17]
+
+RFC 3711                          SRTP                        March 2004
+
+
+      than the one used by the corresponding SRTP.  The expected use for
+      this feature is when the former has NULL-encryption and the latter
+      has a non NULL-encryption.
+
+   The E-flag is assigned a value by the sender depending on whether the
+   packet was encrypted or not.
+
+   *  SRTCP decryption is performed as in Section 4, but only if the E
+      flag is equal to 1.  If so, the Encrypted Portion is decrypted,
+      using the SRTCP index as the index i.  In case the E-flag is 0,
+      the payload is simply left unmodified.
+
+   *  SRTCP replay protection is as defined in Section 3.3.2, but using
+      the SRTCP index as the index i and a separate Replay List that is
+      specific to SRTCP.
+
+   *  The pre-defined SRTCP authentication tag is specified as in
+      Section 4.2, but with the Authenticated Portion of the SRTCP
+      packet given in this section (which includes the index).  The
+      authentication transform and related parameters (e.g., key size)
+      SHALL by default be the same as selected for the protection of the
+      associated SRTP stream(s).
+
+   *  In the last step of the processing, only the sender needs to
+      update the value of the SRTCP index by incrementing it modulo 2^31
+      and for security reasons the sender MUST also check the number of
+      SRTCP packets processed, see Section 9.2.
+
+   Message authentication for RTCP is REQUIRED, as it is the control
+   protocol (e.g., it has a BYE packet) for RTP.
+
+   Precautions must be taken so that the packet expansion in SRTCP (due
+   to the added fields) does not cause SRTCP messages to use more than
+   their share of RTCP bandwidth.  To avoid this, the following two
+   measures MUST be taken:
+
+   1. When initializing the RTCP variable "avg_rtcp_size" defined in
+      chapter 6.3 of [RFC3550], it MUST include the size of the fields
+      that will be added by SRTCP (index, E-bit, authentication tag, and
+      when present, the MKI).
+
+   2. When updating the "avg_rtcp_size" using the variable "packet_size"
+      (section 6.3.3 of [RFC3550]), the value of "packet_size" MUST
+      include the size of the additional fields added by SRTCP.
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 18]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   With these measures in place the SRTCP messages will not use more
+   than the allotted bandwidth.  The effect of the size of the added
+   fields on the SRTCP traffic will be that messages will be sent with
+   longer packet intervals.  The increase in the intervals will be
+   directly proportional to size of the added fields.  For the pre-
+   defined transforms, the size of the added fields will be at least 14
+   octets, and upper bounded depending on MKI and the authentication tag
+   sizes.
+
+4.  Pre-Defined Cryptographic Transforms
+
+   While there are numerous encryption and message authentication
+   algorithms that can be used in SRTP, below we define default
+   algorithms in order to avoid the complexity of specifying the
+   encodings for the signaling of algorithm and parameter identifiers.
+   The defined algorithms have been chosen as they fulfill the goals
+   listed in Section 2.  Recommendations on how to extend SRTP with new
+   transforms are given in Section 6.
+
+4.1.  Encryption
+
+   The following parameters are common to both pre-defined, non-NULL,
+   encryption transforms specified in this section.
+
+   *  BLOCK_CIPHER-MODE indicates the block cipher used and its mode of
+      operation
+   *  n_b is the bit-size of the block for the block cipher
+   *  k_e is the session encryption key
+   *  n_e is the bit-length of k_e
+   *  k_s is the session salting key
+   *  n_s is the bit-length of k_s
+   *  SRTP_PREFIX_LENGTH is the octet length of the keystream prefix, a
+      non-negative integer, specified by the message authentication code
+      in use.
+
+   The distinct session keys and salts for SRTP/SRTCP are by default
+   derived as specified in Section 4.3.
+
+   The encryption transforms defined in SRTP map the SRTP packet index
+   and secret key into a pseudo-random keystream segment.  Each
+   keystream segment encrypts a single RTP packet.  The process of
+   encrypting a packet consists of generating the keystream segment
+   corresponding to the packet, and then bitwise exclusive-oring that
+   keystream segment onto the payload of the RTP packet to produce the
+   Encrypted Portion of the SRTP packet.  In case the payload size is
+   not an integer multiple of n_b bits, the excess (least significant)
+   bits of the keystream are simply discarded.  Decryption is done the
+   same way, but swapping the roles of the plaintext and ciphertext.
+
+
+
+Baugher, et al.             Standards Track                    [Page 19]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   +----+   +------------------+---------------------------------+
+   | KG |-->| Keystream Prefix |          Keystream Suffix       |---+
+   +----+   +------------------+---------------------------------+   |
+                                                                     |
+                               +---------------------------------+   v
+                               |     Payload of RTP Packet       |->(*)
+                               +---------------------------------+   |
+                                                                     |
+                               +---------------------------------+   |
+                               | Encrypted Portion of SRTP Packet|<--+
+                               +---------------------------------+
+
+   Figure 3: Default SRTP Encryption Processing.  Here KG denotes the
+   keystream generator, and (*) denotes bitwise exclusive-or.
+
+   The definition of how the keystream is generated, given the index,
+   depends on the cipher and its mode of operation.  Below, two such
+   keystream generators are defined.  The NULL cipher is also defined,
+   to be used when encryption of RTP is not required.
+
+   The SRTP definition of the keystream is illustrated in Figure 3.  The
+   initial octets of each keystream segment MAY be reserved for use in a
+   message authentication code, in which case the keystream used for
+   encryption starts immediately after the last reserved octet.  The
+   initial reserved octets are called the "keystream prefix" (not to be
+   confused with the "encryption prefix" of [RFC3550, Section 6.1]), and
+   the remaining octets are called the "keystream suffix".  The
+   keystream prefix MUST NOT be used for encryption.  The process is
+   illustrated in Figure 3.
+
+   The number of octets in the keystream prefix is denoted as
+   SRTP_PREFIX_LENGTH.  The keystream prefix is indicated by a positive,
+   non-zero value of SRTP_PREFIX_LENGTH.  This means that, even if
+   confidentiality is not to be provided, the keystream generator output
+   may still need to be computed for packet authentication, in which
+   case the default keystream generator (mode) SHALL be used.
+
+   The default cipher is the Advanced Encryption Standard (AES) [AES],
+   and we define two modes of running AES, (1) Segmented Integer Counter
+   Mode AES and (2) AES in f8-mode.  In the remainder of this section,
+   let E(k,x) be AES applied to key k and input block x.
+
+
+
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 20]
+
+RFC 3711                          SRTP                        March 2004
+
+
+4.1.1.  AES in Counter Mode
+
+   Conceptually, counter mode [AES-CTR] consists of encrypting
+   successive integers.  The actual definition is somewhat more
+   complicated, in order to randomize the starting point of the integer
+   sequence.  Each packet is encrypted with a distinct keystream
+   segment, which SHALL be computed as follows.
+
+   A keystream segment SHALL be the concatenation of the 128-bit output
+   blocks of the AES cipher in the encrypt direction, using key k = k_e,
+   in which the block indices are in increasing order.  Symbolically,
+   each keystream segment looks like
+
+      E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ...
+
+   where the 128-bit integer value IV SHALL be defined by the SSRC, the
+   SRTP packet index i, and the SRTP session salting key k_s, as below.
+
+      IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)
+
+   Each of the three terms in the XOR-sum above is padded with as many
+   leading zeros as needed to make the operation well-defined,
+   considered as a 128-bit value.
+
+   The inclusion of the SSRC allows the use of the same key to protect
+   distinct SRTP streams within the same RTP session, see the security
+   caveats in Section 9.1.
+
+   In the case of SRTCP, the SSRC of the first header of the compound
+   packet MUST be used, i SHALL be the 31-bit SRTCP index and k_e, k_s
+   SHALL be replaced by the SRTCP encryption session key and salt.
+
+   Note that the initial value, IV, is fixed for each packet and is
+   formed by "reserving" 16 zeros in the least significant bits for the
+   purpose of the counter.  The number of blocks of keystream generated
+   for any fixed value of IV MUST NOT exceed 2^16 to avoid keystream
+   re-use, see below.  The AES has a block size of 128 bits, so 2^16
+   output blocks are sufficient to generate the 2^23 bits of keystream
+   needed to encrypt the largest possible RTP packet (except for IPv6
+   "jumbograms" [RFC2675], which are not likely to be used for RTP-based
+   multimedia traffic).  This restriction on the maximum bit-size of the
+   packet that can be encrypted ensures the security of the encryption
+   method by limiting the effectiveness of probabilistic attacks [BDJR].
+
+   For a particular Counter Mode key, each IV value used as an input
+   MUST be distinct, in order to avoid the security exposure of a two-
+   time pad situation (Section 9.1).  To satisfy this constraint, an
+   implementation MUST ensure that the combination of the SRTP packet
+
+
+
+Baugher, et al.             Standards Track                    [Page 21]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   index of ROC || SEQ, and the SSRC used in the construction of the IV
+   are distinct for any particular key.  The failure to ensure this
+   uniqueness could be catastrophic for Secure RTP.  This is in contrast
+   to the situation for RTP itself, which may be able to tolerate such
+   failures.  It is RECOMMENDED that, if a dedicated security module is
+   present, the RTP sequence numbers and SSRC either be generated or
+   checked by that module (i.e., sequence-number and SSRC processing in
+   an SRTP system needs to be protected as well as the key).
+
+4.1.2.  AES in f8-mode
+
+   To encrypt UMTS (Universal Mobile Telecommunications System, as 3G
+   networks) data, a solution (see [f8-a] [f8-b]) known as the f8-
+   algorithm has been developed.  On a high level, the proposed scheme
+   is a variant of Output Feedback Mode (OFB) [HAC], with a more
+   elaborate initialization and feedback function.  As in normal OFB,
+   the core consists of a block cipher.  We also define here the use of
+   AES as a block cipher to be used in what we shall call "f8-mode of
+   operation" RTP encryption.  The AES f8-mode SHALL use the same
+   default sizes for session key and salt as AES counter mode.
+
+   Figure 4 shows the structure of block cipher, E, running in f8-mode.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 22]
+
+RFC 3711                          SRTP                        March 2004
+
+
+                    IV
+                    |
+                    v
+                +------+
+                |      |
+           +--->|  E   |
+           |    +------+
+           |        |
+     m -> (*)       +-----------+-------------+--  ...     ------+
+           |    IV' |           |             |                  |
+           |        |   j=1 -> (*)    j=2 -> (*)   ...  j=L-1 ->(*)
+           |        |           |             |                  |
+           |        |      +-> (*)       +-> (*)   ...      +-> (*)
+           |        |      |    |        |    |             |    |
+           |        v      |    v        |    v             |    v
+           |    +------+   | +------+    | +------+         | +------+
+    k_e ---+--->|  E   |   | |  E   |    | |  E   |         | |  E   |
+                |      |   | |      |    | |      |         | |      |
+                +------+   | +------+    | +------+         | +------+
+                    |      |    |        |    |             |    |
+                    +------+    +--------+    +--  ...  ----+    |
+                    |           |             |                  |
+                    v           v             v                  v
+                   S(0)        S(1)          S(2)  . . .       S(L-1)
+
+   Figure 4.  f8-mode of operation (asterisk, (*), denotes bitwise XOR).
+   The figure represents the KG in Figure 3, when AES-f8 is used.
+
+4.1.2.1.  f8 Keystream Generation
+
+   The Initialization Vector (IV) SHALL be determined as described in
+   Section 4.1.2.2 (and in Section 4.1.2.3 for SRTCP).
+
+   Let IV', S(j), and m denote n_b-bit blocks.  The keystream,
+   S(0) ||... || S(L-1), for an N-bit message SHALL be defined by
+   setting IV' = E(k_e XOR m, IV), and S(-1) = 00..0.  For
+   j = 0,1,..,L-1 where L = N/n_b (rounded up to nearest integer if it
+   is not already an integer) compute
+
+            S(j) = E(k_e, IV' XOR j XOR S(j-1))
+
+   Notice that the IV is not used directly.  Instead it is fed through E
+   under another key to produce an internal, "masked" value (denoted
+   IV') to prevent an attacker from gaining known input/output pairs.
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 23]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   The role of the internal counter, j, is to prevent short keystream
+   cycles.  The value of the key mask m SHALL be
+
+           m = k_s || 0x555..5,
+
+   i.e., the session salting key, appended by the binary pattern 0101..
+   to fill out the entire desired key size, n_e.
+
+   The sender SHOULD NOT generate more than 2^32 blocks, which is
+   sufficient to generate 2^39 bits of keystream.  Unlike counter mode,
+   there is no absolute threshold above (below) which f8 is guaranteed
+   to be insecure (secure).  The above bound has been chosen to limit,
+   with sufficient security margin, the probability of degenerative
+   behavior in the f8 keystream generation.
+
+4.1.2.2.  f8 SRTP IV Formation
+
+   The purpose of the following IV formation is to provide a feature
+   which we call implicit header authentication (IHA), see Section 9.5.
+
+   The SRTP IV for 128-bit block AES-f8 SHALL be formed in the following
+   way:
+
+        IV = 0x00 || M || PT || SEQ || TS || SSRC || ROC
+
+   M, PT, SEQ, TS, SSRC SHALL be taken from the RTP header; ROC is from
+   the cryptographic context.
+
+   The presence of the SSRC as part of the IV allows AES-f8 to be used
+   when a master key is shared between multiple streams within the same
+   RTP session, see Section 9.1.
+
+4.1.2.3.  f8 SRTCP IV Formation
+
+   The SRTCP IV for 128-bit block AES-f8 SHALL be formed in the
+   following way:
+
+   IV= 0..0 || E || SRTCP index || V || P || RC || PT || length || SSRC
+
+   where V, P, RC, PT, length, SSRC SHALL be taken from the first header
+   in the RTCP compound packet.  E and SRTCP index are the 1-bit and
+   31-bit fields added to the packet.
+
+
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 24]
+
+RFC 3711                          SRTP                        March 2004
+
+
+4.1.3.  NULL Cipher
+
+   The NULL cipher is used when no confidentiality for RTP/RTCP is
+   requested.  The keystream can be thought of as "000..0", i.e., the
+   encryption SHALL simply copy the plaintext input into the ciphertext
+   output.
+
+4.2.  Message Authentication and Integrity
+
+   Throughout this section, M will denote data to be integrity
+   protected.  In the case of SRTP, M SHALL consist of the Authenticated
+   Portion of the packet (as specified in Figure 1) concatenated with
+   the ROC, M = Authenticated Portion || ROC; in the case of SRTCP, M
+   SHALL consist of the Authenticated Portion (as specified in Figure 2)
+   only.
+
+   Common parameters:
+
+   *  AUTH_ALG is the authentication algorithm
+   *  k_a is the session message authentication key
+   *  n_a is the bit-length of the authentication key
+   *  n_tag is the bit-length of the output authentication tag
+   *  SRTP_PREFIX_LENGTH is the octet length of the keystream prefix as
+      defined above, a parameter of AUTH_ALG
+
+   The distinct session authentication keys for SRTP/SRTCP are by
+   default derived as specified in Section 4.3.
+
+   The values of n_a, n_tag, and SRTP_PREFIX_LENGTH MUST be fixed for
+   any particular fixed value of the key.
+
+   We describe the process of computing authentication tags as follows.
+   The sender computes the tag of M and appends it to the packet.  The
+   SRTP receiver verifies a message/authentication tag pair by computing
+   a new authentication tag over M using the selected algorithm and key,
+   and then compares it to the tag associated with the received message.
+   If the two tags are equal, then the message/tag pair is valid;
+   otherwise, it is invalid and the error audit message "AUTHENTICATION
+   FAILURE" MUST be returned.
+
+4.2.1.  HMAC-SHA1
+
+   The pre-defined authentication transform for SRTP is HMAC-SHA1
+   [RFC2104].  With HMAC-SHA1, the SRTP_PREFIX_LENGTH (Figure 3) SHALL
+   be 0.  For SRTP (respectively SRTCP), the HMAC SHALL be applied to
+   the session authentication key and M as specified above, i.e.,
+   HMAC(k_a, M).  The HMAC output SHALL then be truncated to the n_tag
+   left-most bits.
+
+
+
+Baugher, et al.             Standards Track                    [Page 25]
+
+RFC 3711                          SRTP                        March 2004
+
+
+4.3.  Key Derivation
+
+4.3.1.  Key Derivation Algorithm
+
+   Regardless of the encryption or message authentication transform that
+   is employed (it may be an SRTP pre-defined transform or newly
+   introduced according to Section 6), interoperable SRTP
+   implementations MUST use the SRTP key derivation to generate session
+   keys.  Once the key derivation rate is properly signaled at the start
+   of the session, there is no need for extra communication between the
+   parties that use SRTP key derivation.
+
+                         packet index ---+
+                                         |
+                                         v
+               +-----------+ master  +--------+ session encr_key
+               | ext       | key     |        |---------->
+               | key mgmt  |-------->|  key   | session auth_key
+               | (optional |         | deriv  |---------->
+               | rekey)    |-------->|        | session salt_key
+               |           | master  |        |---------->
+               +-----------+ salt    +--------+
+
+   Figure 5: SRTP key derivation.
+
+   At least one initial key derivation SHALL be performed by SRTP, i.e.,
+   the first key derivation is REQUIRED.  Further applications of the
+   key derivation MAY be performed, according to the
+   "key_derivation_rate" value in the cryptographic context.  The key
+   derivation function SHALL initially be invoked before the first
+   packet and then, when r > 0, a key derivation is performed whenever
+   index mod r equals zero.  This can be thought of as "refreshing" the
+   session keys.  The value of "key_derivation_rate" MUST be kept fixed
+   for the lifetime of the associated master key.
+
+   Interoperable SRTP implementations MAY also derive session salting
+   keys for encryption transforms, as is done in both of the pre-
+   defined transforms.
+
+   Let m and n be positive integers.  A pseudo-random function family is
+   a set of keyed functions {PRF_n(k,x)} such that for the (secret)
+   random key k, given m-bit x, PRF_n(k,x) is an n-bit string,
+   computationally indistinguishable from random n-bit strings, see
+   [HAC].  For the purpose of key derivation in SRTP, a secure PRF with
+   m = 128 (or more) MUST be used, and a default PRF transform is
+   defined in Section 4.3.3.
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 26]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   Let "a DIV t" denote integer division of a by t, rounded down, and
+   with the convention that "a DIV 0 = 0" for all a.  We also make the
+   convention of treating "a DIV t" as a bit string of the same length
+   as a, and thus "a DIV t" will in general have leading zeros.
+
+   Key derivation SHALL be defined as follows in terms of <label>, an
+   8-bit constant (see below), master_salt and key_derivation_rate, as
+   determined in the cryptographic context, and index, the packet index
+   (i.e., the 48-bit ROC || SEQ for SRTP):
+
+   *  Let r = index DIV key_derivation_rate (with DIV as defined above).
+
+   *  Let key_id = <label> || r.
+
+   *  Let x = key_id XOR master_salt, where key_id and master_salt are
+      aligned so that their least significant bits agree (right-
+      alignment).
+
+   <label> MUST be unique for each type of key to be derived.  We
+   currently define <label> 0x00 to 0x05 (see below), and future
+   extensions MAY specify new values in the range 0x06 to 0xff for other
+   purposes.  The n-bit SRTP key (or salt) for this packet SHALL then be
+   derived from the master key, k_master as follows:
+
+      PRF_n(k_master, x).
+
+   (The PRF may internally specify additional formatting and padding of
+   x, see e.g., Section 4.3.3 for the default PRF.)
+
+   The session keys and salt SHALL now be derived using:
+
+   - k_e (SRTP encryption): <label> = 0x00, n = n_e.
+
+   - k_a (SRTP message authentication): <label> = 0x01, n = n_a.
+
+   - k_s (SRTP salting key): <label> = 0x02, n = n_s.
+
+   where n_e, n_s, and n_a are from the cryptographic context.
+
+   The master key and master salt MUST be random, but the master salt
+   MAY be public.
+
+   Note that for a key_derivation_rate of 0, the application of the key
+   derivation SHALL take place exactly once.
+
+   The definition of DIV above is purely for notational convenience.
+   For a non-zero t among the set of allowed key derivation rates, "a
+   DIV t" can be implemented as a right-shift by the base-2 logarithm of
+
+
+
+Baugher, et al.             Standards Track                    [Page 27]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   t.  The derivation operation is further facilitated if the rates are
+   chosen to be powers of 256, but that granularity was considered too
+   coarse to be a requirement of this specification.
+
+   The upper limit on the number of packets that can be secured using
+   the same master key (see Section 9.2) is independent of the key
+   derivation.
+
+4.3.2.  SRTCP Key Derivation
+
+   SRTCP SHALL by default use the same master key (and master salt) as
+   SRTP.  To do this securely, the following changes SHALL be done to
+   the definitions in Section 4.3.1 when applying session key derivation
+   for SRTCP.
+
+   Replace the SRTP index by the 32-bit quantity: 0 || SRTCP index
+   (i.e., excluding the E-bit, replacing it with a fixed 0-bit), and use
+   <label> = 0x03 for the SRTCP encryption key, <label> = 0x04 for the
+   SRTCP authentication key, and, <label> = 0x05 for the SRTCP salting
+   key.
+
+4.3.3.  AES-CM PRF
+
+   The currently defined PRF, keyed by 128, 192, or 256 bit master key,
+   has input block size m = 128 and can produce n-bit outputs for n up
+   to 2^23.  PRF_n(k_master,x) SHALL be AES in Counter Mode as described
+   in Section 4.1.1, applied to key k_master, and IV equal to (x*2^16),
+   and with the output keystream truncated to the n first (left-most)
+   bits.  (Requiring n/128, rounded up, applications of AES.)
+
+5.  Default and mandatory-to-implement Transforms
+
+   The default transforms also are mandatory-to-implement transforms in
+   SRTP.  Of course, "mandatory-to-implement" does not imply
+   "mandatory-to-use".  Table 1 summarizes the pre-defined transforms.
+   The default values below are valid for the pre-defined transforms.
+
+                         mandatory-to-impl.   optional     default
+
+   encryption            AES-CM, NULL         AES-f8       AES-CM
+   message integrity     HMAC-SHA1              -          HMAC-SHA1
+   key derivation (PRF)  AES-CM                 -          AES-CM
+
+   Table 1: Mandatory-to-implement, optional and default transforms in
+   SRTP and SRTCP.
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 28]
+
+RFC 3711                          SRTP                        March 2004
+
+
+5.1.  Encryption: AES-CM and NULL
+
+   AES running in Segmented Integer Counter Mode, as defined in Section
+   4.1.1, SHALL be the default encryption algorithm.  The default key
+   lengths SHALL be 128-bit for the session encryption key (n_e).  The
+   default session salt key-length (n_s) SHALL be 112 bits.
+
+   The NULL cipher SHALL also be mandatory-to-implement.
+
+5.2.  Message Authentication/Integrity: HMAC-SHA1
+
+   HMAC-SHA1, as defined in Section 4.2.1, SHALL be the default message
+   authentication code.  The default session authentication key-length
+   (n_a) SHALL be 160 bits, the default authentication tag length
+   (n_tag) SHALL be 80 bits, and the SRTP_PREFIX_LENGTH SHALL be zero
+   for HMAC-SHA1.  In addition, for SRTCP, the pre-defined HMAC-SHA1
+   MUST NOT be applied with a value of n_tag, nor n_a, that are smaller
+   than these defaults.  For SRTP, smaller values are NOT RECOMMENDED,
+   but MAY be used after careful consideration of the issues in Section
+   7.5 and 9.5.
+
+5.3.  Key Derivation: AES-CM PRF
+
+   The AES Counter Mode based key derivation and PRF defined in Sections
+   4.3.1 to 4.3.3, using a 128-bit master key, SHALL be the default
+   method for generating session keys.  The default master salt length
+   SHALL be 112 bits and the default key-derivation rate SHALL be zero.
+
+6.  Adding SRTP Transforms
+
+   Section 4 provides examples of the level of detail needed for
+   defining transforms.  Whenever a new transform is to be added to
+   SRTP, a companion standard track RFC MUST be written to exactly
+   define how the new transform can be used with SRTP (and SRTCP).  Such
+   a companion RFC SHOULD avoid overlap with the SRTP protocol document.
+   Note however, that it MAY be necessary to extend the SRTP or SRTCP
+   cryptographic context definition with new parameters (including fixed
+   or default values), add steps to the packet processing, or even add
+   fields to the SRTP/SRTCP packets.  The companion RFC SHALL explain
+   any known issues regarding interactions between the transform and
+   other aspects of SRTP.
+
+   Each new transform document SHOULD specify its key attributes, e.g.,
+   size of keys (minimum, maximum, recommended), format of keys,
+   recommended/required processing of input keying material,
+   requirements/recommendations on key lifetime, re-keying and key
+   derivation, whether sharing of keys between SRTP and SRTCP is allowed
+   or not, etc.
+
+
+
+Baugher, et al.             Standards Track                    [Page 29]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   An added message integrity transform SHOULD define a minimum
+   acceptable key/tag size for SRTCP, equivalent in strength to the
+   minimum values as defined in Section 5.2.
+
+7.  Rationale
+
+   This section explains the rationale behind several important features
+   of SRTP.
+
+7.1.  Key derivation
+
+   Key derivation reduces the burden on the key establishment.  As many
+   as six different keys are needed per crypto context (SRTP and SRTCP
+   encryption keys and salts, SRTP and SRTCP authentication keys), but
+   these are derived from a single master key in a cryptographically
+   secure way.  Thus, the key management protocol needs to exchange only
+   one master key (plus master salt when required), and then SRTP itself
+   derives all the necessary session keys (via the first, mandatory
+   application of the key derivation function).
+
+   Multiple applications of the key derivation function are optional,
+   but will give security benefits when enabled.  They prevent an
+   attacker from obtaining large amounts of ciphertext produced by a
+   single fixed session key.  If the attacker was able to collect a
+   large amount of ciphertext for a certain session key, he might be
+   helped in mounting certain attacks.
+
+   Multiple applications of the key derivation function provide
+   backwards and forward security in the sense that a compromised
+   session key does not compromise other session keys derived from the
+   same master key.  This means that the attacker who is able to recover
+   a certain session key, is anyway not able to have access to messages
+   secured under previous and later session keys (derived from the same
+   master key).  (Note that, of course, a leaked master key reveals all
+   the session keys derived from it.)
+
+   Considerations arise with high-rate key refresh, especially in large
+   multicast settings, see Section 11.
+
+7.2.  Salting key
+
+   The master salt guarantees security against off-line key-collision
+   attacks on the key derivation that might otherwise reduce the
+   effective key size [MF00].
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 30]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   The derived session salting key used in the encryption, has been
+   introduced to protect against some attacks on additive stream
+   ciphers, see Section 9.2.  The explicit inclusion method of the salt
+   in the IV has been selected for ease of hardware implementation.
+
+7.3.  Message Integrity from Universal Hashing
+
+   The particular definition of the keystream given in Section 4.1 (the
+   keystream prefix) is to give provision for particular universal hash
+   functions, suitable for message authentication in the Wegman-Carter
+   paradigm [WC81].  Such functions are provably secure, simple, quick,
+   and especially appropriate for Digital Signal Processors and other
+   processors with a fast multiply operation.
+
+   No authentication transforms are currently provided in SRTP other
+   than HMAC-SHA1.  Future transforms, like the above mentioned
+   universal hash functions, MAY be added following the guidelines in
+   Section 6.
+
+7.4.  Data Origin Authentication Considerations
+
+   Note that in pair-wise communications, integrity and data origin
+   authentication are provided together.  However, in group scenarios
+   where the keys are shared between members, the MAC tag only proves
+   that a member of the group sent the packet, but does not prevent
+   against a member impersonating another.  Data origin authentication
+   (DOA) for multicast and group RTP sessions is a hard problem that
+   needs a solution; while some promising proposals are being
+   investigated [PCST1] [PCST2], more work is needed to rigorously
+   specify these technologies.  Thus SRTP data origin authentication in
+   groups is for further study.
+
+   DOA can be done otherwise using signatures.  However, this has high
+   impact in terms of bandwidth and processing time, therefore we do not
+   offer this form of authentication in the pre-defined packet-integrity
+   transform.
+
+   The presence of mixers and translators does not allow data origin
+   authentication in case the RTP payload and/or the RTP header are
+   manipulated.  Note that these types of middle entities also disrupt
+   end-to-end confidentiality (as the IV formation depends e.g., on the
+   RTP header preservation).  A certain trust model may choose to trust
+   the mixers/translators to decrypt/re-encrypt the media (this would
+   imply breaking the end-to-end security, with related security
+   implications).
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 31]
+
+RFC 3711                          SRTP                        March 2004
+
+
+7.5.  Short and Zero-length Message Authentication
+
+   As shown in Figure 1, the authentication tag is RECOMMENDED in SRTP.
+   A full 80-bit authentication-tag SHOULD be used, but a shorter tag or
+   even a zero-length tag (i.e., no message authentication) MAY be used
+   under certain conditions to support either of the following two
+   application environments.
+
+      1. Strong authentication can be impractical in environments where
+         bandwidth preservation is imperative.  An important special
+         case is wireless communication systems, in which bandwidth is a
+         scarce and expensive resource.  Studies have shown that for
+         certain applications and link technologies, additional bytes
+         may result in a significant decrease in spectrum efficiency
+         [SWO].  Considerable effort has been made to design IP header
+         compression techniques to improve spectrum efficiency
+         [RFC3095].  A typical voice application produces 20 byte
+         samples, and the RTP, UDP and IP headers need to be jointly
+         compressed to one or two bytes on average in order to obtain
+         acceptable wireless bandwidth economy [RFC3095].  In this case,
+         strong authentication would impose nearly fifty percent
+         overhead.
+
+      2. Authentication is impractical for applications that use data
+         links with fixed-width fields that cannot accommodate the
+         expansion due to the authentication tag.  This is the case for
+         some important existing wireless channels.  For example, zero-
+         byte header compression is used to adapt EVRC/SMV voice with
+         the legacy IS-95 bearer channel in CDMA2000 VoIP services.  It
+         was found that not a single additional octet could be added to
+         the data, which motivated the creation of a zero-byte profile
+         for ROHC [RFC3242].
+
+   A short tag is secure for a restricted set of applications.  Consider
+   a voice telephony application, for example, such as a G.729 audio
+   codec with a 20-millisecond packetization interval, protected by a
+   32-bit message authentication tag.  The likelihood of any given
+   packet being successfully forged is only one in 2^32.  Thus an
+   adversary can control no more than 20 milliseconds of audio output
+   during a 994-day period, on average.  In contrast, the effect of a
+   single forged packet can be much larger if the application is
+   stateful.  A codec that uses relative or predictive compression
+   across packets will propagate the maliciously generated state,
+   affecting a longer duration of output.
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 32]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   Certainly not all SRTP or telephony applications meet the criteria
+   for short or zero-length authentication tags.  Section 9.5.1
+   discusses the risks of weak or no message authentication, and section
+   9.5 describes the circumstances when it is acceptable and when it is
+   unacceptable.
+
+8.  Key Management Considerations
+
+   There are emerging key management standards [MIKEY] [KEYMGT] [SDMS]
+   for establishing an SRTP cryptographic context (e.g., an SRTP master
+   key).  Both proprietary and open-standard key management methods are
+   likely to be used for telephony applications [MIKEY] [KINK] and
+   multicast applications [GDOI].  This section provides guidance for
+   key management systems that service SRTP session.
+
+   For initialization, an interoperable SRTP implementation SHOULD be
+   given the SSRC and MAY be given the initial RTP sequence number for
+   the RTP stream by key management (thus, key management has a
+   dependency on RTP operational parameters).  Sending the RTP sequence
+   number in the key management may be useful e.g., when the initial
+   sequence number is close to wrapping (to avoid synchronization
+   problems), and to communicate the current sequence number to a
+   joining endpoint (to properly initialize its replay list).
+
+   If the pre-defined transforms are used, SRTP allows sharing of the
+   same master key between SRTP/SRTCP streams belonging to the same RTP
+   session.
+
+   First, sharing between SRTP streams belonging to the same RTP session
+   is secure if the design of the synchronization mechanism, i.e., the
+   IV, avoids keystream re-use (the two-time pad, Section 9.1).  This is
+   taken care of by the fact that RTP provides for unique SSRCs for
+   streams belonging to the same RTP session.  See Section 9.1 for
+   further discussion.
+
+   Second, sharing between SRTP and the corresponding SRTCP is secure.
+   The fact that an SRTP stream and its associated SRTCP stream both
+   carry the same SSRC does not constitute a problem for the two-time
+   pad due to the key derivation.  Thus, SRTP and SRTCP corresponding to
+   one RTP session MAY share master keys (as they do by default).
+
+   Note that message authentication also has a dependency on SSRC
+   uniqueness that is unrelated to the problem of keystream reuse: SRTP
+   streams authenticated under the same key MUST have a distinct SSRC in
+   order to identify the sender of the message.  This requirement is
+   needed because the SSRC is the cryptographically authenticated field
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 33]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   used to distinguish between different SRTP streams.  Were two streams
+   to use identical SSRC values, then an adversary could substitute
+   messages from one stream into the other without detection.
+
+   SRTP/SRTCP MUST NOT share master keys under any other circumstances
+   than the ones given above, i.e., between SRTP and its corresponding
+   SRTCP, and, between streams belonging to the same RTP session.
+
+8.1.  Re-keying
+
+   The recommended way for a particular key management system to provide
+   re-key within SRTP is by associating a master key in a crypto context
+   with an MKI.
+
+   This provides for easy master key retrieval (see Scenarios in Section
+   11), but has the disadvantage of adding extra bits to each packet.
+   As noted in Section 7.5, some wireless links do not cater for added
+   bits, therefore SRTP also defines a more economic way of triggering
+   re-keying, via use of <From, To>, which works in some specific,
+   simple scenarios (see Section 8.1.1).
+
+   SRTP senders SHALL count the amount of SRTP and SRTCP traffic being
+   used for a master key and invoke key management to re-key if needed
+   (Section 9.2).  These interactions are defined by the key management
+   interface to SRTP and are not defined by this protocol specification.
+
+8.1.1.  Use of the <From, To> for re-keying
+
+   In addition to the use of the MKI, SRTP defines another optional
+   mechanism for master key retrieval, the <From, To>.  The <From, To>
+   specifies the range of SRTP indices (a pair of sequence number and
+   ROC) within which a certain master key is valid, and is (when used)
+   part of the crypto context.  By looking at the 48-bit SRTP index of
+   the current SRTP packet, the corresponding master key can be found by
+   determining which From-To interval it belongs to.  For SRTCP, the
+   most recently observed/used SRTP index (which can be obtained from
+   the cryptographic context) is used for this purpose, even though
+   SRTCP has its own (31-bit) index (see caveat below).
+
+   This method, compared to the MKI, has the advantage of identifying
+   the master key and defining its lifetime without adding extra bits to
+   each packet.  This could be useful, as already noted, for some
+   wireless links that do not cater for added bits.  However, its use
+   SHOULD be limited to specific, very simple scenarios.  We recommend
+   to limit its use when the RTP session is a simple unidirectional or
+   bi-directional stream.  This is because in case of multiple streams,
+   it is difficult to trigger the re-key based on the <From, To> of a
+   single RTP stream. For example, if several streams share a master
+
+
+
+Baugher, et al.             Standards Track                    [Page 34]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   key, there is no simple one-to-one correspondence between the index
+   sequence space of a certain stream, and the index sequence space on
+   which the <From, To> values are based.  Consequently, when a master
+   key is shared between streams, one of these streams MUST be
+   designated by key management as the one whose index space defines the
+   re-keying points.  Also, the re-key triggering on SRTCP is based on
+   the correspondent SRTP stream, i.e., when the SRTP stream changes the
+   master key, so does the correspondent SRTCP.  This becomes obviously
+   more and more complex with multiple streams.
+
+   The default values for the <From, To> are "from the first observed
+   packet" and "until further notice".  However, the maximum limit of
+   SRTP/SRTCP packets that are sent under each given master/session key
+   (Section 9.2) MUST NOT be exceeded.
+
+   In case the <From, To> is used as key retrieval, then the MKI is not
+   inserted in the packet (and its indicator in the crypto context is
+   zero).  However, using the MKI does not exclude using <From, To> key
+   lifetime simultaneously.  This can for instance be useful to signal
+   at the sender side at which point in time an MKI is to be made
+   active.
+
+8.2.  Key Management parameters
+
+   The table below lists all SRTP parameters that key management can
+   supply.  For reference, it also provides a summary of the default and
+   mandatory-to-support values for an SRTP implementation as described
+   in Section 5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 35]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   Parameter                     Mandatory-to-support    Default
+   ---------                     --------------------    -------
+
+   SRTP and SRTCP encr transf.       AES_CM, NULL         AES_CM
+   (Other possible values: AES_f8)
+
+   SRTP and SRTCP auth transf.       HMAC-SHA1           HMAC-SHA1
+
+   SRTP and SRTCP auth params:
+     n_tag (tag length)                 80                 80
+     SRTP prefix_length                  0                  0
+
+   Key derivation PRF                 AES_CM              AES_CM
+
+   Key material params
+   (for each master key):
+     master key length                 128                128
+     n_e (encr session key length)     128                128
+     n_a (auth session key length)     160                160
+     master salt key
+     length of the master salt         112                112
+     n_s (session salt key length)     112                112
+     key derivation rate                 0                  0
+
+     key lifetime
+        SRTP-packets-max-lifetime      2^48               2^48
+        SRTCP-packets-max-lifetime     2^31               2^31
+        from-to-lifetime <From, To>
+     MKI indicator                       0                 0
+     length of the MKI                   0                 0
+     value of the MKI
+
+   Crypto context index params:
+     SSRC value
+     ROC
+     SEQ
+     SRTCP Index
+     Transport address
+     Port number
+
+   Relation to other RTP profiles:
+     sender's order between FEC and SRTP FEC-SRTP      FEC-SRTP
+     (see Section 10)
+
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 36]
+
+RFC 3711                          SRTP                        March 2004
+
+
+9. Security Considerations
+
+9.1.  SSRC collision and two-time pad
+
+   Any fixed keystream output, generated from the same key and index
+   MUST only be used to encrypt once.  Re-using such keystream (jokingly
+   called a "two-time pad" system by cryptographers), can seriously
+   compromise security.  The NSA's VENONA project [C99] provides a
+   historical example of such a compromise.  It is REQUIRED that
+   automatic key management be used for establishing and maintaining
+   SRTP and SRTCP keying material; this requirement is to avoid
+   keystream reuse, which is more likely to occur with manual key
+   management.  Furthermore, in SRTP, a "two-time pad" is avoided by
+   requiring the key, or some other parameter of cryptographic
+   significance, to be unique per RTP/RTCP stream and packet.  The pre-
+   defined SRTP transforms accomplish packet-uniqueness by including the
+   packet index and stream-uniqueness by inclusion of the SSRC.
+
+   The pre-defined transforms (AES-CM and AES-f8) allow master keys to
+   be shared across streams belonging to the same RTP session by the
+   inclusion of the SSRC in the IV.  A master key MUST NOT be shared
+   among different RTP sessions.
+
+   Thus, the SSRC MUST be unique between all the RTP streams within the
+   same RTP session that share the same master key.  RTP itself provides
+   an algorithm for detecting SSRC collisions within the same RTP
+   session.  Thus, temporary collisions could lead to temporary two-time
+   pad, in the unfortunate event that SSRCs collide at a point in time
+   when the streams also have identical sequence numbers (occurring with
+   probability roughly 2^(-48)).  Therefore, the key management SHOULD
+   take care of avoiding such SSRC collisions by including the SSRCs to
+   be used in the session as negotiation parameters, proactively
+   assuring their uniqueness.  This is a strong requirements in
+   scenarios where for example, there are multiple senders that can
+   start to transmit simultaneously, before SSRC collision are detected
+   at the RTP level.
+
+   Note also that even with distinct SSRCs, extensive use of the same
+   key might improve chances of probabilistic collision and time-
+   memory-tradeoff attacks succeeding.
+
+   As described, master keys MAY be shared between streams belonging to
+   the same RTP session, but it is RECOMMENDED that each SSRC have its
+   own master key.  When master keys are shared among SSRC participants
+   and SSRCs are managed by a key management module as recommended
+   above, the RECOMMENDED policy for an SSRC collision error is for the
+   participant to leave the SRTP session as it is a sign of malfunction.
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 37]
+
+RFC 3711                          SRTP                        March 2004
+
+
+9.2.  Key Usage
+
+   The effective key size is determined (upper bounded) by the size of
+   the master key and, for encryption, the size of the salting key.  Any
+   additive stream cipher is vulnerable to attacks that use statistical
+   knowledge about the plaintext source to enable key collision and
+   time-memory tradeoff attacks [MF00] [H80] [BS00].  These attacks take
+   advantage of commonalities among plaintexts, and provide a way for a
+   cryptanalyst to amortize the computational effort of decryption over
+   many keys, or over many bytes of output, thus reducing the effective
+   key size of the cipher.  A detailed analysis of these attacks and
+   their applicability to the encryption of Internet traffic is provided
+   in [MF00].  In summary, the effective key size of SRTP when used in a
+   security system in which m distinct keys are used, is equal to the
+   key size of the cipher less the logarithm (base two) of m.
+   Protection against such attacks can be provided simply by increasing
+   the size of the keys used, which here can be accomplished by the use
+   of the salting key.  Note that the salting key MUST be random but MAY
+   be public.  A salt size of (the suggested) size 112 bits protects
+   against attacks in scenarios where at most 2^112 keys are in use.
+   This is sufficient for all practical purposes.
+
+   Implementations SHOULD use keys that are as large as possible.
+   Please note that in many cases increasing the key size of a cipher
+   does not affect the throughput of that cipher.
+
+   The use of the SRTP and SRTCP indices in the pre-defined transforms
+   fixes the maximum number of packets that can be secured with the same
+   key.  This limit is fixed to 2^48 SRTP packets for an SRTP stream,
+   and 2^31 SRTCP packets, when SRTP and SRTCP are considered
+   independently.  Due to for example re-keying, reaching this limit may
+   or may not coincide with wrapping of the indices, and thus the sender
+   MUST keep packet counts.  However, when the session keys for related
+   SRTP and SRTCP streams are derived from the same master key (the
+   default behavior, Section 4.3), the upper bound that has to be
+   considered is in practice the minimum of the two quantities.  That
+   is, when 2^48 SRTP packets or 2^31 SRTCP packets have been secured
+   with the same key (whichever occurs before), the key management MUST
+   be called to provide new master key(s) (previously stored and used
+   keys MUST NOT be used again), or the session MUST be terminated.  If
+   a sender of RTCP discovers that the sender of SRTP (or SRTCP) has not
+   updated the master or session key prior to sending 2^48 SRTP (or 2^31
+   SRTCP) packets belonging to the same SRTP (SRTCP) stream, it is up to
+   the security policy of the RTCP sender how to behave, e.g., whether
+   an RTCP BYE-packet should be sent and/or if the event should be
+   logged.
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 38]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   Note: in most typical applications (assuming at least one RTCP packet
+   for every 128,000 RTP packets), it will be the SRTCP index that first
+   reaches the upper limit, although the time until this occurs is very
+   long: even at 200 SRTCP packets/sec, the 2^31 index space of SRTCP is
+   enough to secure approximately 4 months of communication.
+
+   Note that if the master key is to be shared between SRTP streams
+   within the same RTP session (Section 9.1), although the above bounds
+   are on a per stream (i.e., per SSRC) basis, the sender MUST base re-
+   key decision on the stream whose sequence number space is the first
+   to be exhausted.
+
+   Key derivation limits the amount of plaintext that is encrypted with
+   a fixed session key, and made available to an attacker for analysis,
+   but key derivation does not extend the master key's lifetime.  To see
+   this, simply consider our requirements to avoid two-time pad:  two
+   distinct packets MUST either be processed with distinct IVs, or with
+   distinct session keys, and both the distinctness of IV and of the
+   session keys are (for the pre-defined transforms) dependent on the
+   distinctness of the packet indices.
+
+   Note that with the key derivation, the effective key size is at most
+   that of the master key, even if the derived session key is
+   considerably longer.  With the pre-defined authentication transform,
+   the session authentication key is 160 bits, but the master key by
+   default is only 128 bits.  This design choice was made to comply with
+   certain recommendations in [RFC2104] so that an existing HMAC
+   implementation can be plugged into SRTP without problems.  Since the
+   default tag size is 80 bits, it is, for the applications in mind,
+   also considered acceptable from security point of view.  Users having
+   concerns about this are RECOMMENDED to instead use a 192 bit master
+   key in the key derivation.  It was, however, chosen not to mandate
+   192-bit keys since existing AES implementations to be used in the
+   key-derivation may not always support key-lengths other than 128
+   bits.  Since AES is not defined (or properly analyzed) for use with
+   160 bit keys it is NOT RECOMMENDED that ad-hoc key-padding schemes
+   are used to pad shorter keys to 192 or 256 bits.
+
+9.3.  Confidentiality of the RTP Payload
+
+   SRTP's pre-defined ciphers are "seekable" stream ciphers, i.e.,
+   ciphers able to efficiently seek to arbitrary locations in their
+   keystream (so that the encryption or decryption of one packet does
+   not depend on preceding packets).  By using seekable stream ciphers,
+   SRTP avoids the denial of service attacks that are possible on stream
+   ciphers that lack this property.  It is important to be aware that,
+   as with any stream cipher, the exact length of the payload is
+   revealed by the encryption.  This means that it may be possible to
+
+
+
+Baugher, et al.             Standards Track                    [Page 39]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   deduce certain "formatting bits" of the payload, as the length of the
+   codec output might vary due to certain parameter settings etc.  This,
+   in turn, implies that the corresponding bit of the keystream can be
+   deduced.  However, if the stream cipher is secure (counter mode and
+   f8 are provably secure under certain assumptions [BDJR] [KSYH] [IK]),
+   knowledge of a few bits of the keystream will not aid an attacker in
+   predicting subsequent keystream bits.  Thus, the payload length (and
+   information deducible from this) will leak, but nothing else.
+
+   As some RTP packet could contain highly predictable data, e.g., SID,
+   it is important to use a cipher designed to resist known plaintext
+   attacks (which is the current practice).
+
+9.4.  Confidentiality of the RTP Header
+
+   In SRTP, RTP headers are sent in the clear to allow for header
+   compression.  This means that data such as payload type,
+   synchronization source identifier, and timestamp are available to an
+   eavesdropper.  Moreover, since RTP allows for future extensions of
+   headers, we cannot foresee what kind of possibly sensitive
+   information might also be "leaked".
+
+   SRTP is a low-cost method, which allows header compression to reduce
+   bandwidth.  It is up to the endpoints' policies to decide about the
+   security protocol to employ.  If one really needs to protect headers,
+   and is allowed to do so by the surrounding environment, then one
+   should also look at alternatives, e.g., IPsec [RFC2401].
+
+9.5.  Integrity of the RTP payload and header
+
+   SRTP messages are subject to attacks on their integrity and source
+   identification, and these risks are discussed in Section 9.5.1.  To
+   protect against these attacks, each SRTP stream SHOULD be protected
+   by HMAC-SHA1 [RFC2104] with an 80-bit output tag and a 160-bit key,
+   or a message authentication code with equivalent strength.  Secure
+   RTP SHOULD NOT be used without message authentication, except under
+   the circumstances described in this section.  It is important to note
+   that encryption algorithms, including AES Counter Mode and f8, do not
+   provide message authentication.  SRTCP MUST NOT be used with weak (or
+   NULL) authentication.
+
+   SRTP MAY be used with weak authentication (e.g., a 32-bit
+   authentication tag), or with no authentication (the NULL
+   authentication algorithm).  These options allow SRTP to be used to
+   provide confidentiality in situations where
+
+    * weak or null authentication is an acceptable security risk, and
+    * it is impractical to provide strong message authentication.
+
+
+
+Baugher, et al.             Standards Track                    [Page 40]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   These conditions are described below and in Section 7.5.  Note that
+   both conditions MUST hold in order for weak or null authentication to
+   be used.  The risks associated with exercising the weak or null
+   authentication options need to be considered by a security audit
+   prior to their use for a particular application or environment given
+   the risks, which are discussed in Section 9.5.1.
+
+   Weak authentication is acceptable when the RTP application is such
+   that the effect of a small fraction of successful forgeries is
+   negligible.  If the application is stateless, then the effect of a
+   single forged RTP packet is limited to the decoding of that
+   particular packet.  Under this condition, the size of the
+   authentication tag MUST ensure that only a negligible fraction of the
+   packets passed to the RTP application by the SRTP receiver can be
+   forgeries.  This fraction is negligible when an adversary, if given
+   control of the forged packets, is not able to make a significant
+   impact on the output of the RTP application (see the example of
+   Section 7.5).
+
+   Weak or null authentication MAY be acceptable when it is unlikely
+   that an adversary can modify ciphertext so that it decrypts to an
+   intelligible value.  One important case is when it is difficult for
+   an adversary to acquire the RTP plaintext data, since for many
+   codecs, an adversary that does not know the input signal cannot
+   manipulate the output signal in a controlled way.  In many cases it
+   may be difficult for the adversary to determine the actual value of
+   the plaintext.  For example, a hidden snooping device might be
+   required in order to know a live audio or video signal.  The
+   adversary's signal must have a quality equivalent to or greater than
+   that of the signal under attack, since otherwise the adversary would
+   not have enough information to encode that signal with the codec used
+   by the victim.  Plaintext prediction may also be especially difficult
+   for an interactive application such as a telephone call.
+
+   Weak or null authentication MUST NOT be used when the RTP application
+   makes data forwarding or access control decisions based on the RTP
+   data.  In such a case, an attacker may be able to subvert
+   confidentiality by causing the receiver to forward data to an
+   attacker.  See Section 3 of [B96] for a real-life example of such
+   attacks.
+
+   Null authentication MUST NOT be used when a replay attack, in which
+   an adversary stores packets then replays them later in the session,
+   could have a non-negligible impact on the receiver.  An example of a
+   successful replay attack is the storing of the output of a
+   surveillance camera for a period of time, later followed by the
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 41]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   injection of that output to the monitoring station to avoid
+   surveillance.  Encryption does not protect against this attack, and
+   non-null authentication is REQUIRED in order to defeat it.
+
+   If existential message forgery is an issue, i.e., when the accuracy
+   of the received data is of non-negligible importance, null
+   authentication MUST NOT be used.
+
+9.5.1.  Risks of Weak or Null Message Authentication
+
+   During a security audit considering the use of weak or null
+   authentication, it is important to keep in mind the following attacks
+   which are possible when no message authentication algorithm is used.
+
+   An attacker who cannot predict the plaintext is still always able to
+   modify the message sent between the sender and the receiver so that
+   it decrypts to a random plaintext value, or to send a stream of bogus
+   packets to the receiver that will decrypt to random plaintext values.
+   This attack is essentially a denial of service attack, though in the
+   absence of message authentication, the RTP application will have
+   inputs that are bit-wise correlated with the true value.  Some
+   multimedia codecs and common operating systems will crash when such
+   data are accepted as valid video data.  This denial of service attack
+   may be a much larger threat than that due to an attacker dropping,
+   delaying, or re-ordering packets.
+
+   An attacker who cannot predict the plaintext can still replay a
+   previous message with certainty that the receiver will accept it.
+   Applications with stateless codecs might be robust against this type
+   of attack, but for other, more complex applications these attacks may
+   be far more grave.
+
+   An attacker who can predict the plaintext can modify the ciphertext
+   so that it will decrypt to any value of her choosing.  With an
+   additive stream cipher, an attacker will always be able to change
+   individual bits.
+
+   An attacker may be able to subvert confidentiality due to the lack of
+   authentication when a data forwarding or access control decision is
+   made on decrypted but unauthenticated plaintext.  This is because the
+   receiver may be fooled into forwarding data to an attacker, leading
+   to an indirect breach of confidentiality (see Section 3 of [B96]).
+   This is because data-forwarding decisions are made on the decrypted
+   plaintext; information in the plaintext will determine to what subnet
+   (or process) the plaintext is forwarded in ESP [RFC2401] tunnel mode
+   (respectively, transport mode).  When Secure RTP is used without
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 42]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   message authentication, it should be verified that the application
+   does not make data forwarding or access control decisions based on
+   the decrypted plaintext.
+
+   Some cipher modes of operation that require padding, e.g., standard
+   cipher block chaining (CBC) are very sensitive to attacks on
+   confidentiality if certain padding types are used in the absence of
+   integrity.  The attack [V02] shows that this is indeed the case for
+   the standard RTP padding as discussed in reference to Figure 1, when
+   used together with CBC mode.  Later transform additions to SRTP MUST
+   therefore carefully consider the risk of using this padding without
+   proper integrity protection.
+
+9.5.2.  Implicit Header Authentication
+
+   The IV formation of the f8-mode gives implicit authentication (IHA)
+   of the RTP header, even when message authentication is not used.
+   When IHA is used, an attacker that modifies the value of the RTP
+   header will cause the decryption process at the receiver to produce
+   random plaintext values.  While this protection is not equivalent to
+   message authentication, it may be useful for some applications.
+
+10.  Interaction with Forward Error Correction mechanisms
+
+   The default processing when using Forward Error Correction (e.g., RFC
+   2733) processing with SRTP SHALL be to perform FEC processing prior
+   to SRTP processing on the sender side and to perform SRTP processing
+   prior to FEC processing on the receiver side.  Any change to this
+   ordering (reversing it, or, placing FEC between SRTP encryption and
+   SRTP authentication) SHALL be signaled out of band.
+
+11.  Scenarios
+
+   SRTP can be used as security protocol for the RTP/RTCP traffic in
+   many different scenarios.  SRTP has a number of configuration
+   options, in particular regarding key usage, and can have impact on
+   the total performance of the application according to the way it is
+   used.  Hence, the use of SRTP is dependent on the kind of scenario
+   and application it is used with.  In the following, we briefly
+   illustrate some use cases for SRTP, and give some guidelines for
+   recommended setting of its options.
+
+11.1.  Unicast
+
+   A typical example would be a voice call or video-on-demand
+   application.
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 43]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   Consider one bi-directional RTP stream, as one RTP session.  It is
+   possible for the two parties to share the same master key in the two
+   directions according to the principles of Section 9.1.  The first
+   round of the key derivation splits the master key into any or all of
+   the following session keys (according to the provided security
+   functions):
+
+   SRTP_encr_key, SRTP_auth_key, SRTCP_encr_key, and SRTCP_auth key.
+
+   (For simplicity, we omit discussion of the salts, which are also
+   derived.)  In this scenario, it will in most cases suffice to have a
+   single master key with the default lifetime.  This guarantees
+   sufficiently long lifetime of the keys and a minimum set of keys in
+   place for most practical purposes.  Also, in this case RTCP
+   protection can be applied smoothly.  Under these assumptions, use of
+   the MKI can be omitted.  As the key-derivation in combination with
+   large difference in the packet rate in the respective directions may
+   require simultaneous storage of several session keys, if storage is
+   an issue, we recommended to use low-rate key derivation.
+
+   The same considerations can be extended to the unicast scenario with
+   multiple RTP sessions, where each session would have a distinct
+   master key.
+
+11.2.  Multicast (one sender)
+
+   Just as with (unprotected) RTP, a scalability issue arises in big
+   groups due to the possibly very large amount of SRTCP Receiver
+   Reports that the sender might need to process.  In SRTP, the sender
+   may have to keep state (the cryptographic context) for each receiver,
+   or more precisely, for the SRTCP used to protect Receiver Reports.
+   The overhead increases proportionally to the size of the group.  In
+   particular, re-keying requires special concern, see below.
+
+   Consider first a small group of receivers.  There are a few possible
+   setups with the distribution of master keys among the receivers.
+   Given a single RTP session, one possibility is that the receivers
+   share the same master key as per Section 9.1 to secure all their
+   respective RTCP traffic.  This shared master key could then be the
+   same one used by the sender to protect its outbound SRTP traffic.
+   Alternatively, it could be a master key shared only among the
+   receivers and used solely for their SRTCP traffic.  Both alternatives
+   require the receivers to trust each other.
+
+   Considering SRTCP and key storage, it is recommended to use low-rate
+   (or zero) key_derivation (except the mandatory initial one), so that
+   the sender does not need to store too many session keys (each SRTCP
+   stream might otherwise have a different session key at a given point
+
+
+
+Baugher, et al.             Standards Track                    [Page 44]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   in time, as the SRTCP sources send at different times).  Thus, in
+   case key derivation is wanted for SRTP, the cryptographic context for
+   SRTP can be kept separate from the SRTCP crypto context, so that it
+   is possible to have a key_derivation_rate of 0 for SRTCP and a non-
+   zero value for SRTP.
+
+   Use of the MKI for re-keying is RECOMMENDED for most applications
+   (see Section 8.1).
+
+   If there are more than one SRTP/SRTCP stream (within the same RTP
+   session) that share the master key, the upper limit of 2^48 SRTP
+   packets / 2^31 SRTCP packets means that, before one of the streams
+   reaches its maximum number of packets, re-keying MUST be triggered on
+   ALL streams sharing the master key.  (From strict security point of
+   view, only the stream reaching the maximum would need to be re-keyed,
+   but then the streams would no longer be sharing master key, which is
+   the intention.)  A local policy at the sender side should force
+   rekeying in a way that the maximum packet limit is not reached on any
+   of the streams.  Use of the MKI for re-keying is RECOMMENDED.
+
+   In large multicast with one sender, the same considerations as for
+   the small group multicast hold.  The biggest issue in this scenario
+   is the additional load placed at the sender side, due to the state
+   (cryptographic contexts) that has to be maintained for each receiver,
+   sending back RTCP Receiver Reports.  At minimum, a replay window
+   might need to be maintained for each RTCP source.
+
+11.3.  Re-keying and access control
+
+   Re-keying may occur due to access control (e.g., when a member is
+   removed during a multicast RTP session), or for pure cryptographic
+   reasons (e.g., the key is at the end of its lifetime).  When using
+   SRTP default transforms, the master key MUST be replaced before any
+   of the index spaces are exhausted for any of the streams protected by
+   one and the same master key.
+
+   How key management re-keys SRTP implementations is out of scope, but
+   it is clear that there are straightforward ways to manage keys for a
+   multicast group.  In one-sender multicast, for example, it is
+   typically the responsibility of the sender to determine when a new
+   key is needed.  The sender is the one entity that can keep track of
+   when the maximum number of packets has been sent, as receivers may
+   join and leave the session at any time, there may be packet loss and
+   delay etc.  In scenarios other than one-sender multicast, other
+   methods can be used.  Here, one must take into consideration that key
+   exchange can be a costly operation, taking several seconds for a
+   single exchange.  Hence, some time before the master key is
+   exhausted/expires, out-of-band key management is initiated, resulting
+
+
+
+Baugher, et al.             Standards Track                    [Page 45]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   in a new master key that is shared with the receiver(s).  In any
+   event, to maintain synchronization when switching to the new key,
+   group policy might choose between using the MKI and the <From, To>,
+   as described in Section 8.1.
+
+   For access control purposes, the <From, To> periods are set at the
+   desired granularity, dependent on the packet rate.  High rate re-
+   keying can be problematic for SRTCP in some large-group scenarios.
+   As mentioned, there are potential problems in using the SRTP index,
+   rather than the SRTCP index, for determining the master key.  In
+   particular, for short periods during switching of master keys, it may
+   be the case that SRTCP packets are not under the current master key
+   of the correspondent SRTP.  Therefore, using the MKI for re-keying in
+   such scenarios will produce better results.
+
+11.4.  Summary of basic scenarios
+
+   The description of these scenarios highlights some recommendations on
+   the use of SRTP, mainly related to re-keying and large scale
+   multicast:
+
+   - Do not use fast re-keying with the <From, To> feature.  It may, in
+     particular, give problems in retrieving the correct SRTCP key, if
+     an SRTCP packet arrives close to the re-keying time.  The MKI
+     SHOULD be used in this case.
+
+   - If multiple SRTP streams in the same RTP session share the same
+     master key, also moderate rate re-keying MAY have the same
+     problems, and the MKI SHOULD be used.
+
+   - Though offering increased security, a non-zero key_derivation_rate
+     is NOT RECOMMENDED when trying to minimize the number of keys in
+     use with multiple streams.
+
+12.  IANA Considerations
+
+   The RTP specification establishes a registry of profile names for use
+   by higher-level control protocols, such as the Session Description
+   Protocol (SDP), to refer to transport methods.  This profile
+   registers the name "RTP/SAVP".
+
+   SRTP uses cryptographic transforms which a key management protocol
+   signals.  It is the task of each particular key management protocol
+   to register the cryptographic transforms or suites of transforms with
+   IANA.  The key management protocol conveys these protocol numbers,
+   not SRTP, and each key management protocol chooses the numbering
+   scheme and syntax that it requires.
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 46]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   Specification of a key management protocol for SRTP is out of scope
+   here.  Section 8.2, however, provides guidance on the parameters that
+   need to be defined for the default and mandatory transforms.
+
+13.  Acknowledgements
+
+   David Oran (Cisco) and Rolf Blom (Ericsson) are co-authors of this
+   document but their valuable contributions are acknowledged here to
+   keep the length of the author list down.
+
+   The authors would in addition like to thank Magnus Westerlund, Brian
+   Weis, Ghyslain Pelletier, Morgan Lindqvist, Robert Fairlie-
+   Cuninghame, Adrian Perrig, the AVT WG and in particular the chairmen
+   Colin Perkins and Stephen Casner, the Transport and Security Area
+   Directors, and Eric Rescorla for their reviews and support.
+
+14.  References
+
+14.1.  Normative References
+
+   [AES]     NIST, "Advanced Encryption Standard (AES)", FIPS PUB 197,
+             http://www.nist.gov/aes/
+
+   [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
+             Hashing for Message Authentication", RFC 2104, February
+             1997.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
+             Internet Protocol", RFC 2401, November 1998.
+
+   [RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828,
+             May 2000.
+
+   [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
+             "RTP: A Transport Protocol for Real-time Applications", RFC
+             3550, July 2003.
+
+   [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
+             Video Conferences with Minimal Control",  RFC 3551, July
+             2003.
+
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 47]
+
+RFC 3711                          SRTP                        March 2004
+
+
+14.2.  Informative References
+
+   [AES-CTR] Lipmaa, H., Rogaway, P. and D. Wagner, "CTR-Mode
+             Encryption", NIST, http://csrc.nist.gov/encryption/modes/
+             workshop1/papers/lipmaa-ctr.pdf
+
+   [B96]     Bellovin, S., "Problem Areas for the IP Security
+             Protocols," in Proceedings of the Sixth Usenix Unix
+             Security Symposium, pp. 1-16, San Jose, CA, July 1996
+             (http://www.research.att.com/~smb/papers/index.html).
+
+   [BDJR]    Bellare, M., Desai, A., Jokipii, E. and P. Rogaway, "A
+             Concrete Treatment of Symmetric Encryption: Analysis of DES
+             Modes of Operation", Proceedings 38th IEEE FOCS, pp. 394-
+             403, 1997.
+
+   [BS00]    Biryukov, A. and A. Shamir, "Cryptanalytic Time/Memory/Data
+             Tradeoffs for Stream Ciphers", Proceedings, ASIACRYPT 2000,
+             LNCS 1976, pp. 1-13, Springer Verlag.
+
+   [C99]     Crowell, W. P., "Introduction to the VENONA Project",
+             http://www.nsa.gov:8080/docs/venona/index.html.
+
+   [CTR]     Dworkin, M., NIST Special Publication 800-38A,
+             "Recommendation for Block Cipher Modes of Operation:
+             Methods and Techniques", 2001.
+             http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-
+             38a.pdf.
+
+   [f8-a]    3GPP TS 35.201 V4.1.0 (2001-12) Technical Specification 3rd
+             Generation Partnership Project; Technical Specification
+             Group Services and System Aspects; 3G Security;
+             Specification of the 3GPP Confidentiality and Integrity
+             Algorithms; Document 1: f8 and f9 Specification (Release
+             4).
+
+   [f8-b]    3GPP TR 33.908 V4.0.0 (2001-09) Technical Report 3rd
+             Generation Partnership Project; Technical Specification
+             Group Services and System Aspects; 3G Security; General
+             Report on the Design, Specification and Evaluation of 3GPP
+             Standard Confidentiality and Integrity Algorithms (Release
+             4).
+
+   [GDOI]    Baugher, M., Weis, B., Hardjono, T. and H. Harney, "The
+             Group Domain of Interpretation, RFC 3547, July 2003.
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 48]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   [HAC]     Menezes, A., Van Oorschot, P. and  S. Vanstone, "Handbook
+             of Applied Cryptography", CRC Press, 1997, ISBN 0-8493-
+             8523-7.
+
+   [H80]     Hellman, M. E., "A cryptanalytic time-memory trade-off",
+             IEEE Transactions on Information Theory, July 1980, pp.
+             401-406.
+
+   [IK]      T. Iwata and T. Kohno: "New Security Proofs for the 3GPP
+             Confidentiality and Integrity Algorithms", Proceedings of
+             FSE 2004.
+
+   [KINK]    Thomas, M. and J. Vilhuber, "Kerberized Internet
+             Negotiation of Keys (KINK)", Work in Progress.
+
+   [KEYMGT]  Arrko, J., et al., "Key Management Extensions for Session
+             Description Protocol (SDP) and Real Time Streaming Protocol
+             (RTSP)", Work in Progress.
+
+   [KSYH]    Kang, J-S., Shin, S-U., Hong, D. and O. Yi, "Provable
+             Security of KASUMI and 3GPP Encryption Mode f8",
+             Proceedings Asiacrypt 2001, Springer Verlag LNCS 2248, pp.
+             255-271, 2001.
+
+   [MIKEY]   Arrko, J., et. al., "MIKEY: Multimedia Internet KEYing",
+             Work in Progress.
+
+   [MF00]    McGrew, D. and S. Fluhrer, "Attacks on Encryption of
+             Redundant Plaintext and Implications on Internet Security",
+             the Proceedings of the Seventh Annual Workshop on Selected
+             Areas in Cryptography (SAC 2000), Springer-Verlag.
+
+   [PCST1]   Perrig, A., Canetti, R., Tygar, D. and D.  Song, "Efficient
+             and Secure Source Authentication for Multicast", in Proc.
+             of Network and Distributed System Security Symposium NDSS
+             2001, pp. 35-46, 2001.
+
+   [PCST2]   Perrig, A., Canetti, R., Tygar, D. and D. Song, "Efficient
+             Authentication and Signing of Multicast Streams over Lossy
+             Channels", in Proc. of IEEE Security and Privacy Symposium
+             S&P2000, pp. 56-73, 2000.
+
+   [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+             Recommendations for Security", RFC 1750, December 1994.
+
+   [RFC2675] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms",
+             RFC 2675, August 1999.
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 49]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukuhsima, H.,
+             Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
+             Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,
+             T., Yoshimura, T. and H. Zheng, "RObust Header Compression:
+             Framework and Four Profiles: RTP, UDP, ESP, and
+             uncompressed (ROHC)", RFC 3095, July 2001.
+
+   [RFC3242] Jonsson, L-E. and G. Pelletier, "RObust Header Compression
+             (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP ", RFC
+             3242, April 2002.
+
+   [SDMS]    Andreasen, F., Baugher, M. and D. Wing, "Session
+             Description Protocol Security Descriptions for Media
+             Streams", Work in Progress.
+
+   [SWO]     Svanbro, K., Wiorek, J. and B. Olin, "Voice-over-IP-over-
+             wireless", Proc.  PIMRC 2000, London, Sept. 2000.
+
+   [V02]     Vaudenay, S., "Security Flaws Induced by CBC Padding -
+             Application to SSL, IPsec, WTLS...", Advances in
+             Cryptology, EUROCRYPT'02, LNCS 2332, pp. 534-545.
+
+   [WC81]    Wegman, M. N., and  J.L. Carter, "New Hash Functions and
+             Their Use in Authentication and Set Equality", JCSS 22,
+             265-279, 1981.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 50]
+
+RFC 3711                          SRTP                        March 2004
+
+
+Appendix A: Pseudocode for Index Determination
+
+   The following is an example of pseudo-code for the algorithm to
+   determine the index i of an SRTP packet with sequence number SEQ.  In
+   the following, signed arithmetic is assumed.
+
+         if (s_l < 32,768)
+            if (SEQ - s_l > 32,768)
+               set v to (ROC-1) mod 2^32
+            else
+               set v to ROC
+            endif
+         else
+            if (s_l - 32,768 > SEQ)
+               set v to (ROC+1) mod 2^32
+            else
+               set v to ROC
+            endif
+         endif
+         return SEQ + v*65,536
+
+Appendix B: Test Vectors
+
+   All values are in hexadecimal.
+
+B.1.  AES-f8 Test Vectors
+
+   SRTP PREFIX LENGTH  :   0
+
+   RTP packet header   :   806e5cba50681de55c621599
+
+   RTP packet payload  :   70736575646f72616e646f6d6e657373
+                           20697320746865206e65787420626573
+                           74207468696e67
+
+   ROC                 :   d462564a
+   key                 :   234829008467be186c3de14aae72d62c
+   salt key            :   32f2870d
+   key-mask (m)        :   32f2870d555555555555555555555555
+   key XOR key-mask    :   11baae0dd132eb4d3968b41ffb278379
+
+   IV                  :   006e5cba50681de55c621599d462564a
+   IV'                 :   595b699bbd3bc0df26062093c1ad8f73
+
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 51]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   j = 0
+   IV' xor j           :   595b699bbd3bc0df26062093c1ad8f73
+   S(-1)               :   00000000000000000000000000000000
+   IV' xor S(-1) xor j :   595b699bbd3bc0df26062093c1ad8f73
+   S(0)                :   71ef82d70a172660240709c7fbb19d8e
+   plaintext           :   70736575646f72616e646f6d6e657373
+   ciphertext          :   019ce7a26e7854014a6366aa95d4eefd
+
+   j = 1
+   IV' xor j           :   595b699bbd3bc0df26062093c1ad8f72
+   S(0)                :   71ef82d70a172660240709c7fbb19d8e
+   IV' xor S(0) xor j  :   28b4eb4cb72ce6bf020129543a1c12fc
+   S(1)                :   3abd640a60919fd43bd289a09649b5fc
+   plaintext           :   20697320746865206e65787420626573
+   ciphertext          :   1ad4172a14f9faf455b7f1d4b62bd08f
+
+   j = 2
+   IV' xor j           :   595b699bbd3bc0df26062093c1ad8f71
+   S(1)                :   3abd640a60919fd43bd289a09649b5fc
+   IV' xor S(1) xor j  :   63e60d91ddaa5f0b1dd4a93357e43a8d
+   S(2)                :   220c7a8715266565b09ecc8a2a62b11b
+   plaintext           :   74207468696e67
+   ciphertext          :   562c0eef7c4802
+
+B.2.  AES-CM Test Vectors
+
+    Keystream segment length: 1044512 octets (65282 AES blocks)
+    Session Key:      2B7E151628AED2A6ABF7158809CF4F3C
+    Rollover Counter: 00000000
+    Sequence Number:  0000
+    SSRC:             00000000
+    Session Salt:     F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000 (already shifted)
+    Offset:           F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000
+
+    Counter                            Keystream
+
+    F0F1F2F3F4F5F6F7F8F9FAFBFCFD0000   E03EAD0935C95E80E166B16DD92B4EB4
+    F0F1F2F3F4F5F6F7F8F9FAFBFCFD0001   D23513162B02D0F72A43A2FE4A5F97AB
+    F0F1F2F3F4F5F6F7F8F9FAFBFCFD0002   41E95B3BB0A2E8DD477901E4FCA894C0
+    ...                                ...
+    F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF   EC8CDF7398607CB0F2D21675EA9EA1E4
+    F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF00   362B7C3C6773516318A077D7FC5073AE
+    F0F1F2F3F4F5F6F7F8F9FAFBFCFDFF01   6A2CC3787889374FBEB4C81B17BA6C44
+
+   Nota Bene: this test case is contrived so that the latter part of the
+   keystream segment coincides with the test case in Section F.5.1 of
+   [CTR].
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 52]
+
+RFC 3711                          SRTP                        March 2004
+
+
+B.3.  Key Derivation Test Vectors
+
+   This section provides test data for the default key derivation
+   function, which uses AES-128 in Counter Mode.  In the following, we
+   walk through the initial key derivation for the AES-128 Counter Mode
+   cipher, which requires a 16 octet session encryption key and a 14
+   octet session salt, and an authentication function which requires a
+   94-octet session authentication key.  These values are called the
+   cipher key, the cipher salt, and the auth key in the following.
+   Since this is the initial key derivation and the key derivation rate
+   is equal to zero, the value of (index DIV key_derivation_rate) is
+   zero (actually, a six-octet string of zeros).  In the following, we
+   shorten key_derivation_rate to kdr.
+
+   The inputs to the key derivation function are the 16 octet master key
+   and the 14 octet master salt:
+
+      master key:  E1F97A0D3E018BE0D64FA32C06DE4139
+      master salt: 0EC675AD498AFEEBB6960B3AABE6
+
+   We first show how the cipher key is generated.  The input block for
+   AES-CM is generated by exclusive-oring the master salt with the
+   concatenation of the encryption key label 0x00 with (index DIV kdr),
+   then padding on the right with two null octets (which implements the
+   multiply-by-2^16 operation, see Section 4.3.3).  The resulting value
+   is then AES-CM- encrypted using the master key to get the cipher key.
+
+      index DIV kdr:                 000000000000
+      label:                       00
+      master salt:   0EC675AD498AFEEBB6960B3AABE6
+      -----------------------------------------------
+      xor:           0EC675AD498AFEEBB6960B3AABE6     (x, PRF input)
+
+      x*2^16:        0EC675AD498AFEEBB6960B3AABE60000 (AES-CM input)
+
+      cipher key:    C61E7A93744F39EE10734AFE3FF7A087 (AES-CM output)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 53]
+
+RFC 3711                          SRTP                        March 2004
+
+
+   Next, we show how the cipher salt is generated.  The input block for
+   AES-CM is generated by exclusive-oring the master salt with the
+   concatenation of the encryption salt label.  That value is padded and
+   encrypted as above.
+
+      index DIV kdr:                 000000000000
+      label:                       02
+      master salt:   0EC675AD498AFEEBB6960B3AABE6
+
+      ----------------------------------------------
+      xor:           0EC675AD498AFEE9B6960B3AABE6     (x, PRF input)
+
+      x*2^16:        0EC675AD498AFEE9B6960B3AABE60000 (AES-CM input)
+
+                     30CBBC08863D8C85D49DB34A9AE17AC6 (AES-CM ouptut)
+
+      cipher salt:   30CBBC08863D8C85D49DB34A9AE1
+
+   We now show how the auth key is generated.  The input block for AES-
+   CM is generated as above, but using the authentication key label.
+
+      index DIV kdr:                   000000000000
+      label:                         01
+      master salt:     0EC675AD498AFEEBB6960B3AABE6
+      -----------------------------------------------
+      xor:             0EC675AD498AFEEAB6960B3AABE6     (x, PRF input)
+
+      x*2^16:          0EC675AD498AFEEAB6960B3AABE60000 (AES-CM input)
+
+   Below, the auth key is shown on the left, while the corresponding AES
+   input blocks are shown on the right.
+
+   auth key                           AES input blocks
+   CEBE321F6FF7716B6FD4AB49AF256A15   0EC675AD498AFEEAB6960B3AABE60000
+   6D38BAA48F0A0ACF3C34E2359E6CDBCE   0EC675AD498AFEEAB6960B3AABE60001
+   E049646C43D9327AD175578EF7227098   0EC675AD498AFEEAB6960B3AABE60002
+   6371C10C9A369AC2F94A8C5FBCDDDC25   0EC675AD498AFEEAB6960B3AABE60003
+   6D6E919A48B610EF17C2041E47403576   0EC675AD498AFEEAB6960B3AABE60004
+   6B68642C59BBFC2F34DB60DBDFB2       0EC675AD498AFEEAB6960B3AABE60005
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 54]
+
+RFC 3711                          SRTP                        March 2004
+
+
+Authors' Addresses
+
+   Questions and comments should be directed to the authors and
+   avt@ietf.org:
+
+   Mark Baugher
+   Cisco Systems, Inc.
+   5510 SW Orchid Street
+   Portland, OR 97219 USA
+
+   Phone:  +1 408-853-4418
+   EMail:  mbaugher@cisco.com
+
+
+   Elisabetta Carrara
+   Ericsson Research
+   SE-16480 Stockholm
+   Sweden
+
+   Phone:  +46 8 50877040
+   EMail:  elisabetta.carrara@ericsson.com
+
+
+   David A. McGrew
+   Cisco Systems, Inc.
+   San Jose, CA 95134-1706
+   USA
+
+   Phone:  +1 301-349-5815
+   EMail:  mcgrew@cisco.com
+
+
+   Mats Naslund
+   Ericsson Research
+   SE-16480 Stockholm
+   Sweden
+
+   Phone:  +46 8 58533739
+   EMail:  mats.naslund@ericsson.com
+
+
+   Karl Norrman
+   Ericsson Research
+   SE-16480 Stockholm
+   Sweden
+
+   Phone:  +46 8 4044502
+   EMail:  karl.norrman@ericsson.com
+
+
+
+Baugher, et al.             Standards Track                    [Page 55]
+
+RFC 3711                          SRTP                        March 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78 and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Baugher, et al.             Standards Track                    [Page 56]
+
diff --git a/jni/pjproject-android/.svn/pristine/c5/c52eb1030d140883fec01056c63639e8519649bb.svn-base b/jni/pjproject-android/.svn/pristine/c5/c52eb1030d140883fec01056c63639e8519649bb.svn-base
new file mode 100644
index 0000000..b97bdc2
--- /dev/null
+++ b/jni/pjproject-android/.svn/pristine/c5/c52eb1030d140883fec01056c63639e8519649bb.svn-base
@@ -0,0 +1,12 @@
+# $Id$
+#
+from inc_cfg import *
+
+# TCP call
+test_param = TestParam(
+		"Caller requires PRACK",
+		[
+			InstanceParam("callee", "--null-audio --max-calls=1"),
+			InstanceParam("caller", "--null-audio --max-calls=1 --use-100rel")
+		]
+		)
diff --git a/jni/pjproject-android/.svn/pristine/c5/c538b66c7110ca3a028ccfe422d0f1fa200a9935.svn-base b/jni/pjproject-android/.svn/pristine/c5/c538b66c7110ca3a028ccfe422d0f1fa200a9935.svn-base
new file mode 100644
index 0000000..3eefcb9
--- /dev/null
+++ b/jni/pjproject-android/.svn/pristine/c5/c538b66c7110ca3a028ccfe422d0f1fa200a9935.svn-base
@@ -0,0 +1 @@
+1.0.0
diff --git a/jni/pjproject-android/.svn/pristine/c5/c576d862127406b98a310d13c0c2d842971ed4e4.svn-base b/jni/pjproject-android/.svn/pristine/c5/c576d862127406b98a310d13c0c2d842971ed4e4.svn-base
new file mode 100644
index 0000000..91ee183
--- /dev/null
+++ b/jni/pjproject-android/.svn/pristine/c5/c576d862127406b98a310d13c0c2d842971ed4e4.svn-base
@@ -0,0 +1,121 @@
+/* $Id$ */
+/* 
+ * Copyright (C) 2008-2011 Teluu Inc. (http://www.teluu.com)
+ * Copyright (C) 2003-2008 Benny Prijono <benny@prijono.org>
+ *
+ * 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 
+ */
+
+
+/* Internal */
+PJ_INLINE(void) pj_link_node(pj_list_type *prev, pj_list_type *next)
+{
+    ((pj_list*)prev)->next = next;
+    ((pj_list*)next)->prev = prev;
+}
+
+PJ_IDEF(void) pj_list_insert_after(pj_list_type *pos, pj_list_type *node)
+{
+    ((pj_list*)node)->prev = pos;
+    ((pj_list*)node)->next = ((pj_list*)pos)->next;
+    ((pj_list*) ((pj_list*)pos)->next) ->prev = node;
+    ((pj_list*)pos)->next = node;
+}
+
+
+PJ_IDEF(void) pj_list_insert_before(pj_list_type *pos, pj_list_type *node)
+{
+    pj_list_insert_after(((pj_list*)pos)->prev, node);
+}
+
+
+PJ_IDEF(void) pj_list_insert_nodes_after(pj_list_type *pos, pj_list_type *lst)
+{
+    pj_list *lst_last = (pj_list *) ((pj_list*)lst)->prev;
+    pj_list *pos_next = (pj_list *) ((pj_list*)pos)->next;
+
+    pj_link_node(pos, lst);
+    pj_link_node(lst_last, pos_next);
+}
+
+PJ_IDEF(void) pj_list_insert_nodes_before(pj_list_type *pos, pj_list_type *lst)
+{
+    pj_list_insert_nodes_after(((pj_list*)pos)->prev, lst);
+}
+
+PJ_IDEF(void) pj_list_merge_last(pj_list_type *lst1, pj_list_type *lst2)
+{
+    if (!pj_list_empty(lst2)) {
+	pj_link_node(((pj_list*)lst1)->prev, ((pj_list*)lst2)->next);
+	pj_link_node(((pj_list*)lst2)->prev, lst1);
+	pj_list_init(lst2);
+    }
+}
+
+PJ_IDEF(void) pj_list_merge_first(pj_list_type *lst1, pj_list_type *lst2)
+{
+    if (!pj_list_empty(lst2)) {
+	pj_link_node(((pj_list*)lst2)->prev, ((pj_list*)lst1)->next);
+	pj_link_node(((pj_list*)lst1), ((pj_list*)lst2)->next);
+	pj_list_init(lst2);
+    }
+}
+
+PJ_IDEF(void) pj_list_erase(pj_list_type *node)
+{
+    pj_link_node( ((pj_list*)node)->prev, ((pj_list*)node)->next);
+
+    /* It'll be safer to init the next/prev fields to itself, to
+     * prevent multiple erase() from corrupting the list. See
+     * ticket #520 for one sample bug.
+     */
+    pj_list_init(node);
+}
+
+
+PJ_IDEF(pj_list_type*) pj_list_find_node(pj_list_type *list, pj_list_type *node)
+{
+    pj_list *p = (pj_list *) ((pj_list*)list)->next;
+    while (p != list && p != node)
+	p = (pj_list *) p->next;
+
+    return p==node ? p : NULL;
+}
+
+
+PJ_IDEF(pj_list_type*) pj_list_search(pj_list_type *list, void *value,
+	       		int (*comp)(void *value, const pj_list_type *node))
+{
+    pj_list *p = (pj_list *) ((pj_list*)list)->next;
+    while (p != list && (*comp)(value, p) != 0)
+	p = (pj_list *) p->next;
+
+    return p==list ? NULL : p;
+}
+
+
+PJ_IDEF(pj_size_t) pj_list_size(const pj_list_type *list)
+{
+    const pj_list *node = (const pj_list*) ((const pj_list*)list)->next;
+    pj_size_t count = 0;
+
+    while (node != list) {
+	++count;
+	node = (pj_list*)node->next;
+    }
+
+    return count;
+}
+
diff --git a/jni/pjproject-android/.svn/pristine/c5/c59453e3cd37723290cc4d8be89e19e8fa4db792.svn-base b/jni/pjproject-android/.svn/pristine/c5/c59453e3cd37723290cc4d8be89e19e8fa4db792.svn-base
new file mode 100644
index 0000000..953d115
--- /dev/null
+++ b/jni/pjproject-android/.svn/pristine/c5/c59453e3cd37723290cc4d8be89e19e8fa4db792.svn-base
@@ -0,0 +1,1781 @@
+# Doxyfile 1.7.6.1
+
+# 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 (" ").
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+
+# This tag specifies the encoding used for all characters in the config file
+# that follow. The default is UTF-8 which is also the encoding used for all
+# text before the first occurrence of this tag. Doxygen uses libiconv (or the
+# iconv built into libc) for the transcoding. See
+# http://www.gnu.org/software/libiconv for the list of possible encodings.
+
+DOXYFILE_ENCODING      = UTF-8
+
+# The PROJECT_NAME tag is a single word (or sequence of words) that should
+# identify the project. Note that if you do not use Doxywizard you need
+# to put quotes around the project name if it contains spaces.
+
+PROJECT_NAME           = "pjsua2"
+
+# 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         =
+
+# Using the PROJECT_BRIEF tag one can provide an optional one line description
+# for a project that appears at the top of each page and should give viewer
+# a quick idea about the purpose of the project. Keep the description short.
+
+PROJECT_BRIEF          =
+
+# With the PROJECT_LOGO tag one can specify an logo or icon that is
+# included in the documentation. The maximum height of the logo should not
+# exceed 55 pixels and the maximum width should not exceed 200 pixels.
+# Doxygen will copy the logo to the output directory.
+
+PROJECT_LOGO           =
+
+# 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       =
+
+# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
+# 4096 sub-directories (in 2 levels) under the output directory of each output
+# format and will distribute the generated files over these directories.
+# Enabling this option can be useful when feeding doxygen a huge amount of
+# source files, where putting all generated files in the same directory would
+# otherwise cause performance problems for the file system.
+
+CREATE_SUBDIRS         = NO
+
+# 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:
+# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional,
+# Croatian, Czech, Danish, Dutch, Esperanto, Farsi, Finnish, French, German,
+# Greek, Hungarian, Italian, Japanese, Japanese-en (Japanese with English
+# messages), Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian,
+# Polish, Portuguese, Romanian, Russian, Serbian, Serbian-Cyrillic, Slovak,
+# Slovene, Spanish, Swedish, Ukrainian, and Vietnamese.
+
+OUTPUT_LANGUAGE        = English
+
+# 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           = YES
+
+# This tag implements a quasi-intelligent brief description abbreviator
+# that is used to form the text in various listings. Each string
+# in this list, if found as the leading text of the brief description, will be
+# stripped from the text and the result after processing the whole list, is
+# used as the annotated text. Otherwise, the brief description is used as-is.
+# If left blank, the following values are used ("$name" is automatically
+# replaced with the name of the entity): "The $name class" "The $name widget"
+# "The $name file" "is" "provides" "specifies" "contains"
+# "represents" "a" "an" "the"
+
+ABBREVIATE_BRIEF       =
+
+# 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        = YES
+
+# 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. The tag can be used to show relative paths in the file list.
+# If left blank the directory from which doxygen is run is used as the
+# path to strip.
+
+STRIP_FROM_PATH        =
+
+# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
+# the path mentioned in the documentation of a class, which tells
+# the reader which header file to include in order to use a class.
+# If left blank only the name of the header file containing the class
+# definition is used. Otherwise one should specify the include paths that
+# are normally passed to the compiler using the -I flag.
+
+STRIP_FROM_INC_PATH    =
+
+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
+# (but less readable) file names. This can be useful if your file system
+# doesn't support long names like on DOS, Mac, or CD-ROM.
+
+SHORT_NAMES            = 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 regular Qt-style comments
+# (thus requiring an explicit @brief command for a brief description.)
+
+JAVADOC_AUTOBRIEF      = YES
+
+# If the QT_AUTOBRIEF tag is set to YES then Doxygen will
+# interpret the first line (until the first dot) of a Qt-style
+# comment as the brief description. If set to NO, the comments
+# will behave just like regular Qt-style comments (thus requiring
+# an explicit \brief command for a brief description.)
+
+QT_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 INHERIT_DOCS tag is set to YES (the default) then an undocumented
+# member inherits the documentation from any documented member that it
+# re-implements.
+
+INHERIT_DOCS           = YES
+
+# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
+# a new page for each member. If set to NO, the documentation of a member will
+# be part of the file/class/namespace that contains it.
+
+SEPARATE_MEMBER_PAGES  = 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
+
+# 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                =
+
+# This tag can be used to specify a number of word-keyword mappings (TCL only).
+# A mapping has the form "name=value". For example adding
+# "class=itcl::class" will allow you to use the command class in the
+# itcl::class meaning.
+
+TCL_SUBST              =
+
+# 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  = NO
+
+# 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 OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
+# sources only. Doxygen will then generate output that is more tailored for
+# Fortran.
+
+OPTIMIZE_FOR_FORTRAN   = NO
+
+# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
+# sources. Doxygen will then generate output that is tailored for
+# VHDL.
+
+OPTIMIZE_OUTPUT_VHDL   = NO
+
+# Doxygen selects the parser to use depending on the extension of the files it
+# parses. With this tag you can assign which parser to use for a given extension.
+# Doxygen has a built-in mapping, but you can override or extend it using this
+# tag. The format is ext=language, where ext is a file extension, and language
+# is one of the parsers supported by doxygen: IDL, Java, Javascript, CSharp, C,
+# C++, D, PHP, Objective-C, Python, Fortran, VHDL, C, C++. For instance to make
+# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C
+# (default is Fortran), use: inc=Fortran f=C. Note that for custom extensions
+# you also need to set FILE_PATTERNS otherwise the files are not read by doxygen.
+
+EXTENSION_MAPPING      =
+
+# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
+# to include (a tag file for) the STL sources as input, then you should
+# set this tag to YES in order to let doxygen match functions declarations and
+# definitions whose arguments contain STL classes (e.g. func(std::string); v.s.
+# func(std::string) {}). This also makes the inheritance and collaboration
+# diagrams that involve STL classes more complete and accurate.
+
+BUILTIN_STL_SUPPORT    = NO
+
+# If you use Microsoft's C++/CLI language, you should set this option to YES to
+# enable parsing support.
+
+CPP_CLI_SUPPORT        = NO
+
+# Set the SIP_SUPPORT tag to YES if your project consists of sip sources only.
+# Doxygen will parse them like normal C++ but will assume all classes use public
+# instead of private inheritance when no explicit protection keyword is present.
+
+SIP_SUPPORT            = NO
+
+# For Microsoft's IDL there are propget and propput attributes to indicate getter
+# and setter methods for a property. Setting this option to YES (the default)
+# will make doxygen replace the get and set methods by a property in the
+# documentation. This will only work if the methods are indeed getting or
+# setting a simple type. If this is not the case, or you want to show the
+# methods anyway, you should set this option to NO.
+
+IDL_PROPERTY_SUPPORT   = 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
+
+# Set the SUBGROUPING tag to YES (the default) to allow class member groups of
+# the same type (for instance a group of public functions) to be put as a
+# subgroup of that type (e.g. under the Public Functions section). Set it to
+# NO to prevent subgrouping. Alternatively, this can be done per class using
+# the \nosubgrouping command.
+
+SUBGROUPING            = YES
+
+# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and
+# unions are shown inside the group in which they are included (e.g. using
+# @ingroup) instead of on a separate page (for HTML and Man pages) or
+# section (for LaTeX and RTF).
+
+INLINE_GROUPED_CLASSES = NO
+
+# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and
+# unions with only public data fields will be shown inline in the documentation
+# of the scope in which they are defined (i.e. file, namespace, or group
+# documentation), provided this scope is documented. If set to NO (the default),
+# structs, classes, and unions are shown on a separate page (for HTML and Man
+# pages) or section (for LaTeX and RTF).
+
+INLINE_SIMPLE_STRUCTS  = NO
+
+# When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, or enum
+# is documented as struct, union, or enum with the name of the typedef. So
+# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
+# with name TypeT. When disabled the typedef will appear as a member of a file,
+# namespace, or class. And the struct will be named TypeS. This can typically
+# be useful for C code in case the coding convention dictates that all compound
+# types are typedef'ed and only the typedef is referenced, never the tag name.
+
+TYPEDEF_HIDES_STRUCT   = NO
+
+# The SYMBOL_CACHE_SIZE determines the size of the internal cache use to
+# determine which symbols to keep in memory and which to flush to disk.
+# When the cache is full, less often used symbols will be written to disk.
+# For small to medium size projects (<1000 input files) the default value is
+# probably good enough. For larger projects a too small cache size can cause
+# doxygen to be busy swapping symbols to and from disk most of the time
+# causing a significant performance penalty.
+# If the system has enough physical memory increasing the cache will improve the
+# performance by keeping more symbols in memory. Note that the value works on
+# a logarithmic scale so increasing the size by one will roughly double the
+# memory usage. The cache size is given by this formula:
+# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0,
+# corresponding to a cache size of 2^16 = 65536 symbols.
+
+SYMBOL_CACHE_SIZE      = 0
+
+# Similar to the SYMBOL_CACHE_SIZE the size of the symbol lookup cache can be
+# set using LOOKUP_CACHE_SIZE. This cache is used to resolve symbols given
+# their name and scope. Since this can be an expensive process and often the
+# same symbol appear multiple times in the code, doxygen keeps a cache of
+# pre-resolved symbols. If the cache is too small doxygen will become slower.
+# If the cache is too large, memory is wasted. The cache size is given by this
+# formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range is 0..9, the default is 0,
+# corresponding to a cache size of 2^16 = 65536 symbols.
+
+LOOKUP_CACHE_SIZE      = 0
+
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+
+# 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
+
+# This flag is only useful for Objective-C code. When set to YES local
+# methods, which are defined in the implementation section but not in
+# the interface are included in the documentation.
+# If set to NO (the default) only methods in the interface are included.
+
+EXTRACT_LOCAL_METHODS  = NO
+
+# If this flag is set to YES, the members of anonymous namespaces will be
+# extracted and appear in the documentation as a namespace called
+# 'anonymous_namespace{file}', where file will be replaced with the base
+# name of the file that contains the anonymous namespace. By default
+# anonymous namespaces are hidden.
+
+EXTRACT_ANON_NSPACES   = NO
+
+# 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 classes 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
+
+# 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
+# and Mac users are advised to set this option to NO.
+
+CASE_SENSE_NAMES       = YES
+
+# 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 SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
+# will put a list of the files that are included by a file in the documentation
+# of that file.
+
+SHOW_INCLUDE_FILES     = YES
+
+# If the FORCE_LOCAL_INCLUDES tag is set to YES then Doxygen
+# will list include files with double quotes in the documentation
+# rather than with sharp brackets.
+
+FORCE_LOCAL_INCLUDES   = NO
+
+# 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 the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
+# brief documentation of file, namespace and class members alphabetically
+# by member name. If set to NO (the default) the members will appear in
+# declaration order.
+
+SORT_BRIEF_DOCS        = NO
+
+# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen
+# will sort the (brief and detailed) documentation of class members so that
+# constructors and destructors are listed first. If set to NO (the default)
+# the constructors will appear in the respective orders defined by
+# SORT_MEMBER_DOCS and SORT_BRIEF_DOCS.
+# This tag will be ignored for brief docs if SORT_BRIEF_DOCS is set to NO
+# and ignored for detailed docs if SORT_MEMBER_DOCS is set to NO.
+
+SORT_MEMBERS_CTORS_1ST = NO
+
+# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the
+# hierarchy of group names into alphabetical order. If set to NO (the default)
+# the group names will appear in their defined order.
+
+SORT_GROUP_NAMES       = NO
+
+# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be
+# sorted by fully-qualified names, including namespaces. If set to
+# NO (the default), the class list will be sorted only by class name,
+# not including the namespace part.
+# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+# Note: This option applies only to the class list, not to the
+# alphabetical list.
+
+SORT_BY_SCOPE_NAME     = NO
+
+# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to
+# do proper type resolution of all parameters of a function it will reject a
+# match between the prototype and the implementation of a member function even
+# if there is only one candidate or it is obvious which candidate to choose
+# by doing a simple string match. By disabling STRICT_PROTO_MATCHING doxygen
+# will still accept a match between prototype and implementation in such cases.
+
+STRICT_PROTO_MATCHING  = NO
+
+# 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
+
+# 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 macro consists 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 macros in the
+# documentation can be controlled using \showinitializer or \hideinitializer
+# command in the documentation regardless of this setting.
+
+MAX_INITIALIZER_LINES  = 30
+
+# 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
+
+# If the sources in your project are distributed over multiple directories
+# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy
+# in the documentation. The default is NO.
+
+SHOW_DIRECTORIES       = NO
+
+# Set the SHOW_FILES tag to NO to disable the generation of the Files page.
+# This will remove the Files entry from the Quick Index and from the
+# Folder Tree View (if specified). The default is YES.
+
+SHOW_FILES             = YES
+
+# Set the SHOW_NAMESPACES tag to NO to disable the generation of the
+# Namespaces page.
+# This will remove the Namespaces entry from the Quick Index
+# and from the Folder Tree View (if specified). The default is YES.
+
+SHOW_NAMESPACES        = YES
+
+# The FILE_VERSION_FILTER tag can be used to specify a program or script that
+# doxygen should invoke to get the current version for each file (typically from
+# the version control system). Doxygen will invoke the program by executing (via
+# popen()) the command <command> <input-file>, where <command> is the value of
+# the FILE_VERSION_FILTER tag, and <input-file> is the name of an input file
+# provided by doxygen. Whatever the program writes to standard output
+# is used as the file version. See the manual for examples.
+
+FILE_VERSION_FILTER    =
+
+# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
+# by doxygen. The layout file controls the global structure of the generated
+# output files in an output format independent way. The create the layout file
+# that represents doxygen's defaults, run doxygen with the -l option.
+# You can optionally specify a file name after the option, if omitted
+# DoxygenLayout.xml will be used as the name of the layout file.
+
+LAYOUT_FILE            =
+
+# The CITE_BIB_FILES tag can be used to specify one or more bib files
+# containing the references data. This must be a list of .bib files. The
+# .bib extension is automatically appended if omitted. Using this command
+# requires the bibtex tool to be installed. See also
+# http://en.wikipedia.org/wiki/BibTeX for more info. For LaTeX the style
+# of the bibliography can be controlled using LATEX_BIB_STYLE. To use this
+# feature you need bibtex and perl available in the search path.
+
+CITE_BIB_FILES         =
+
+#---------------------------------------------------------------------------
+# 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                  = YES
+
+# 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_NO_PARAMDOC option can be enabled to get warnings for
+# functions that are documented, but have no documentation for their parameters
+# or return value. If set to NO (the default) doxygen will only warn about
+# wrong or incomplete parameter documentation, but not about the absence of
+# documentation.
+
+WARN_NO_PARAMDOC       = NO
+
+# 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. Optionally the format may contain
+# $version, which will be replaced by the version of the file (if it could
+# be obtained via FILE_VERSION_FILTER)
+
+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                  = ../../pjsip/include/pjsua2/media.hpp
+
+# This tag can be used to specify the character encoding of the source files
+# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
+# also the default input encoding. Doxygen uses libiconv (or the iconv built
+# into libc) for the transcoding. See http://www.gnu.org/software/libiconv for
+# the list of possible encodings.
+
+INPUT_ENCODING         = UTF-8
+
+# 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++ *.d *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh
+# *.hxx *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.dox *.py
+# *.f90 *.f *.for *.vhd *.vhdl
+
+FILE_PATTERNS          = *.hpp
+
+# 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              = NO
+
+# The EXCLUDE tag can be used to specify files and/or directories that should be
+# 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.
+# Note that relative paths are relative to the directory from which doxygen is
+# run.
+
+EXCLUDE                =
+
+# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
+# directories that are symbolic links (a Unix file system 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. Note that the wildcards are matched
+# against the file with absolute path, so to exclude all test directories
+# for example use the pattern */test/*
+
+EXCLUDE_PATTERNS       =
+
+# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
+# (namespaces, classes, functions, etc.) that should be excluded from the
+# output. The symbol name can be a fully qualified name, a word, or if the
+# wildcard * is used, a substring. Examples: ANamespace, AClass,
+# AClass::ANamespace, ANamespace::*Test
+
+EXCLUDE_SYMBOLS        =
+
+# 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           =
+
+# 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      = NO
+
+# 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             =
+
+# 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.
+# If FILTER_PATTERNS is specified, this tag will be
+# ignored.
+
+INPUT_FILTER           =
+
+# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+# basis.
+# Doxygen will compare the file name with each pattern and apply the
+# filter if there is a match.
+# The filters are a list of the form:
+# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further
+# info on how filters are used. If FILTER_PATTERNS is empty or if
+# non of the patterns match the file name, INPUT_FILTER is applied.
+
+FILTER_PATTERNS        =
+
+# 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
+
+# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file
+# pattern. A pattern will override the setting for FILTER_PATTERN (if any)
+# and it is also possible to disable source filtering for a specific pattern
+# using *.ext= (so without naming a filter). This option only has effect when
+# FILTER_SOURCE_FILES is enabled.
+
+FILTER_SOURCE_PATTERNS =
+
+#---------------------------------------------------------------------------
+# 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.
+# Note: To get rid of all source code in the generated output, make sure also
+# VERBATIM_HEADERS is set to NO.
+
+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
+# then for each documented function all documented
+# functions referencing it will be listed.
+
+REFERENCED_BY_RELATION = NO
+
+# If the REFERENCES_RELATION tag is set to YES
+# then for each documented function all documented entities
+# called/used by that function will be listed.
+
+REFERENCES_RELATION    = NO
+
+# If the REFERENCES_LINK_SOURCE tag is set to YES (the default)
+# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from
+# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will
+# link to the source code.
+# Otherwise they will link to the documentation.
+
+REFERENCES_LINK_SOURCE = YES
+
+# If the USE_HTAGS tag is set to YES then the references to source code
+# will point to the HTML generated by the htags(1) tool instead of doxygen
+# built-in source browser. The htags tool is part of GNU's global source
+# tagging system (see http://www.gnu.org/software/global/global.html). You
+# will need version 4.8.6 or higher.
+
+USE_HTAGS              = 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
+
+#---------------------------------------------------------------------------
+# 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     = YES
+
+# 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          = NO
+
+# 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    = .html
+
+# 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. Note that when using a custom header you are responsible
+#  for the proper inclusion of any scripts and style sheets that doxygen
+# needs, which is dependent on the configuration options used.
+# It is advised to generate a default header using "doxygen -w html
+# header.html footer.html stylesheet.css YourConfigFile" and then modify
+# that header. Note that the header is subject to change so you typically
+# have to redo this when upgrading to a newer version of doxygen or when
+# changing the value of configuration settings such as GENERATE_TREEVIEW!
+
+HTML_HEADER            =
+
+# 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            =
+
+# 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. Note that doxygen will try to copy
+# the style sheet file to the HTML output directory, so don't put your own
+# style sheet in the HTML output directory as well, or it will be erased!
+
+HTML_STYLESHEET        =
+
+# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
+# other source files which should be copied to the HTML output directory. Note
+# that these files will be copied to the base HTML output directory. Use the
+# $relpath$ marker in the HTML_HEADER and/or HTML_FOOTER files to load these
+# files. In the HTML_STYLESHEET file, use the file name only. Also note that
+# the files will be copied as-is; there are no commands or markers available.
+
+HTML_EXTRA_FILES       =
+
+# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output.
+# Doxygen will adjust the colors in the style sheet and background images
+# according to this color. Hue is specified as an angle on a colorwheel,
+# see http://en.wikipedia.org/wiki/Hue for more information.
+# For instance the value 0 represents red, 60 is yellow, 120 is green,
+# 180 is cyan, 240 is blue, 300 purple, and 360 is red again.
+# The allowed range is 0 to 359.
+
+HTML_COLORSTYLE_HUE    = 220
+
+# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of
+# the colors in the HTML output. For a value of 0 the output will use
+# grayscales only. A value of 255 will produce the most vivid colors.
+
+HTML_COLORSTYLE_SAT    = 100
+
+# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to
+# the luminance component of the colors in the HTML output. Values below
+# 100 gradually make the output lighter, whereas values above 100 make
+# the output darker. The value divided by 100 is the actual gamma applied,
+# so 80 represents a gamma of 0.8, The value 220 represents a gamma of 2.2,
+# and 100 does not change the gamma.
+
+HTML_COLORSTYLE_GAMMA  = 80
+
+# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
+# page will contain the date and time when the page was generated. Setting
+# this to NO can help when comparing the output of multiple runs.
+
+HTML_TIMESTAMP         = YES
+
+# 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 HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
+# documentation will contain sections that can be hidden and shown after the
+# page has loaded. For this to work a browser that supports
+# JavaScript and DHTML is required (for instance Mozilla 1.0+, Firefox
+# Netscape 6.0+, Internet explorer 5.0+, Konqueror, or Safari).
+
+HTML_DYNAMIC_SECTIONS  = NO
+
+# If the GENERATE_DOCSET tag is set to YES, additional index files
+# will be generated that can be used as input for Apple's Xcode 3
+# integrated development environment, introduced with OSX 10.5 (Leopard).
+# To create a documentation set, doxygen will generate a Makefile in the
+# HTML output directory. Running make will produce the docset in that
+# directory and running "make install" will install the docset in
+# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find
+# it at startup.
+# See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
+# for more information.
+
+GENERATE_DOCSET        = NO
+
+# When GENERATE_DOCSET tag is set to YES, this tag determines the name of the
+# feed. A documentation feed provides an umbrella under which multiple
+# documentation sets from a single provider (such as a company or product suite)
+# can be grouped.
+
+DOCSET_FEEDNAME        = "Doxygen generated docs"
+
+# When GENERATE_DOCSET tag is set to YES, this tag specifies a string that
+# should uniquely identify the documentation set bundle. This should be a
+# reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen
+# will append .docset to the name.
+
+DOCSET_BUNDLE_ID       = org.doxygen.Project
+
+# When GENERATE_PUBLISHER_ID tag specifies a string that should uniquely identify
+# the documentation publisher. This should be a reverse domain-name style
+# string, e.g. com.mycompany.MyDocSet.documentation.
+
+DOCSET_PUBLISHER_ID    = org.doxygen.Publisher
+
+# The GENERATE_PUBLISHER_NAME tag identifies the documentation publisher.
+
+DOCSET_PUBLISHER_NAME  = Publisher
+
+# 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 compiled 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 directory.
+
+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 CHM_INDEX_ENCODING
+# is used to encode HtmlHelp index (hhk), content (hhc) and project file
+# content.
+
+CHM_INDEX_ENCODING     =
+
+# 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
+
+# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
+# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated
+# that can be used as input for Qt's qhelpgenerator to generate a
+# Qt Compressed Help (.qch) of the generated HTML documentation.
+
+GENERATE_QHP           = NO
+
+# If the QHG_LOCATION tag is specified, the QCH_FILE tag can
+# be used to specify the file name of the resulting .qch file.
+# The path specified is relative to the HTML output folder.
+
+QCH_FILE               =
+
+# The QHP_NAMESPACE tag specifies the namespace to use when generating
+# Qt Help Project output. For more information please see
+# http://doc.trolltech.com/qthelpproject.html#namespace
+
+QHP_NAMESPACE          = org.doxygen.Project
+
+# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating
+# Qt Help Project output. For more information please see
+# http://doc.trolltech.com/qthelpproject.html#virtual-folders
+
+QHP_VIRTUAL_FOLDER     = doc
+
+# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to
+# add. For more information please see
+# http://doc.trolltech.com/qthelpproject.html#custom-filters
+
+QHP_CUST_FILTER_NAME   =
+
+# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the
+# custom filter to add. For more information please see
+# <a href="http://doc.trolltech.com/qthelpproject.html#custom-filters">
+# Qt Help Project / Custom Filters</a>.
+
+QHP_CUST_FILTER_ATTRS  =
+
+# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
+# project's
+# filter section matches.
+# <a href="http://doc.trolltech.com/qthelpproject.html#filter-attributes">
+# Qt Help Project / Filter Attributes</a>.
+
+QHP_SECT_FILTER_ATTRS  =
+
+# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can
+# be used to specify the location of Qt's qhelpgenerator.
+# If non-empty doxygen will try to run qhelpgenerator on the generated
+# .qhp file.
+
+QHG_LOCATION           =
+
+# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files
+#  will be generated, which together with the HTML files, form an Eclipse help
+# plugin. To install this plugin and make it available under the help contents
+# menu in Eclipse, the contents of the directory containing the HTML and XML
+# files needs to be copied into the plugins directory of eclipse. The name of
+# the directory within the plugins directory should be the same as
+# the ECLIPSE_DOC_ID value. After copying Eclipse needs to be restarted before
+# the help appears.
+
+GENERATE_ECLIPSEHELP   = NO
+
+# A unique identifier for the eclipse help plugin. When installing the plugin
+# the directory name containing the HTML and XML files should also have
+# this name.
+
+ECLIPSE_DOC_ID         = org.doxygen.Project
+
+# The DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs)
+# at top of each HTML page. The value NO (the default) enables the index and
+# the value YES disables it. Since the tabs have the same information as the
+# navigation tree you can set this option to NO if you already set
+# GENERATE_TREEVIEW to YES.
+
+DISABLE_INDEX          = NO
+
+# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
+# structure should be generated to display hierarchical information.
+# If the tag value 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 (i.e. any modern browser).
+# Windows users are probably better off using the HTML help feature.
+# Since the tree basically has the same information as the tab index you
+# could consider to set DISABLE_INDEX to NO when enabling this option.
+
+GENERATE_TREEVIEW      = NO
+
+# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values
+# (range [0,1..20]) that doxygen will group on one line in the generated HTML
+# documentation. Note that a value of 0 will completely suppress the enum
+# values from appearing in the overview section.
+
+ENUM_VALUES_PER_LINE   = 4
+
+# By enabling USE_INLINE_TREES, doxygen will generate the Groups, Directories,
+# and Class Hierarchy pages using a tree view instead of an ordered list.
+
+USE_INLINE_TREES       = 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
+
+# When the EXT_LINKS_IN_WINDOW option is set to YES doxygen will open
+# links to external symbols imported via tag files in a separate window.
+
+EXT_LINKS_IN_WINDOW    = NO
+
+# Use this tag to change the font size of Latex formulas included
+# as images in the HTML documentation. The default is 10. Note that
+# when you change the font size after a successful doxygen run you need
+# to manually remove any form_*.png images from the HTML output directory
+# to force them to be regenerated.
+
+FORMULA_FONTSIZE       = 10
+
+# Use the FORMULA_TRANPARENT tag to determine whether or not the images
+# generated for formulas are transparent PNGs. Transparent PNGs are
+# not supported properly for IE 6.0, but are supported on all modern browsers.
+# Note that when changing this option you need to delete any form_*.png files
+# in the HTML output before the changes have effect.
+
+FORMULA_TRANSPARENT    = YES
+
+# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax
+# (see http://www.mathjax.org) which uses client side Javascript for the
+# rendering instead of using prerendered bitmaps. Use this if you do not
+# have LaTeX installed or if you want to formulas look prettier in the HTML
+# output. When enabled you also need to install MathJax separately and
+# configure the path to it using the MATHJAX_RELPATH option.
+
+USE_MATHJAX            = NO
+
+# When MathJax is enabled you need to specify the location relative to the
+# HTML output directory using the MATHJAX_RELPATH option. The destination
+# directory should contain the MathJax.js script. For instance, if the mathjax
+# directory is located at the same level as the HTML output directory, then
+# MATHJAX_RELPATH should be ../mathjax. The default value points to the
+# mathjax.org site, so you can quickly see the result without installing
+# MathJax, but it is strongly recommended to install a local copy of MathJax
+# before deployment.
+
+MATHJAX_RELPATH        = http://www.mathjax.org/mathjax
+
+# The MATHJAX_EXTENSIONS tag can be used to specify one or MathJax extension
+# names that should be enabled during MathJax rendering.
+
+MATHJAX_EXTENSIONS     =
+
+# When the SEARCHENGINE tag is enabled doxygen will generate a search box
+# for the HTML output. The underlying search engine uses javascript
+# and DHTML and should work on any modern browser. Note that when using
+# HTML help (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets
+# (GENERATE_DOCSET) there is already a search function so this one should
+# typically be disabled. For large projects the javascript based search engine
+# can be slow, then enabling SERVER_BASED_SEARCH may provide a better solution.
+
+SEARCHENGINE           = YES
+
+# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
+# implemented using a PHP enabled web server instead of at the web client
+# using Javascript. Doxygen will generate the search PHP script and index
+# file to put on the web server. The advantage of the server
+# based approach is that it scales better to large projects and allows
+# full text search. The disadvantages are that it is more difficult to setup
+# and does not have live searching capabilities.
+
+SERVER_BASED_SEARCH    = NO
+
+#---------------------------------------------------------------------------
+# 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.
+# Note that when enabling USE_PDFLATEX this option is only used for
+# generating bitmaps for formulas in the HTML output, but not in the
+# Makefile that is written to the output directory.
+
+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, letter, legal and
+# executive. If left blank a4wide will be used.
+
+PAPER_TYPE             = a4
+
+# 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           =
+
+# The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for
+# the generated latex document. The footer should contain everything after
+# the last chapter. If it is left blank doxygen will generate a
+# standard footer. Notice: only use this tag if you know what you are doing!
+
+LATEX_FOOTER           =
+
+# 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
+
+# If LATEX_HIDE_INDICES is set to YES then doxygen will not
+# include the index chapters (such as File Index, Compound Index, etc.)
+# in the output.
+
+LATEX_HIDE_INDICES     = NO
+
+# If LATEX_SOURCE_CODE is set to YES then doxygen will include
+# source code with syntax highlighting in the LaTeX output.
+# Note that which sources are shown also depends on other settings
+# such as SOURCE_BROWSER.
+
+LATEX_SOURCE_CODE      = NO
+
+# The LATEX_BIB_STYLE tag can be used to specify the style to use for the
+# bibliography, e.g. plainnat, or ieeetr. The default style is "plain". See
+# http://en.wikipedia.org/wiki/BibTeX for more info.
+
+LATEX_BIB_STYLE        = plain
+
+#---------------------------------------------------------------------------
+# 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 optimized 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 style sheet definitions from file. Syntax is similar to doxygen's
+# config file, i.e. a series of assignments. 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.
+
+GENERATE_XML           = YES
+
+# The XML_OUTPUT tag is used to specify where the XML 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 `xml' will be used as the default path.
+
+XML_OUTPUT             = xml
+
+# 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                =
+
+# If the XML_PROGRAMLISTING tag is set to YES Doxygen will
+# dump the program listings (including syntax highlighting
+# and cross-referencing information) to the XML output. Note that
+# enabling this will significantly increase the size of the XML output.
+
+XML_PROGRAMLISTING     = YES
+
+#---------------------------------------------------------------------------
+# 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        = NO
+
+# 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_DEFINED tags.
+
+EXPAND_ONLY_PREDEF     = NO
+
+# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
+# pointed to by INCLUDE_PATH will be searched when 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. To prevent a macro definition from being
+# undefined via #undef or recursively expanded use the := operator
+# instead of the = operator.
+
+PREDEFINED             = DOXYGEN
+
+# 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 that
+# overrules the definition found in the source code.
+
+EXPAND_AS_DEFINED      =
+
+# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
+# doxygen's preprocessor will remove all references to function-like macros
+# that are alone on a line, have an all uppercase name, and do not end with a
+# semicolon, because these will confuse the parser if not removed.
+
+SKIP_FUNCTION_MACROS   = YES
+
+#---------------------------------------------------------------------------
+# Configuration::additions related to external references
+#---------------------------------------------------------------------------
+
+# The TAGFILES option can be used to specify one or more tagfiles.
+# Optionally an initial location of the external documentation
+# can be added for each tagfile. The format of a tag file without
+# this location is as follows:
+#
+# TAGFILES = file1 file2 ...
+# Adding location for the tag files is done as follows:
+#
+# TAGFILES = file1=loc1 "file2 = loc2" ...
+# where "loc1" and "loc2" can be relative or absolute paths or
+# URLs. If a location is present for each tag, the installdox tool
+# does not have to be run to correct the links.
+# Note that each tag file must have a unique name
+# (where the name does NOT include the path)
+# If a tag file is not located in the directory in which doxygen
+# is run, you must also specify the path to the tagfile here.
+
+TAGFILES               =
+
+# 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       =
+
+# 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        = YES
+
+# 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
+
+#---------------------------------------------------------------------------
+# 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 also works with HAVE_DOT disabled, but it is recommended to
+# install and use dot, since it yields more powerful graphs.
+
+CLASS_DIAGRAMS         = YES
+
+# You can define message sequence charts within doxygen comments using the \msc
+# command. Doxygen will then run the mscgen tool (see
+# http://www.mcternan.me.uk/mscgen/) to produce the chart and insert it in the
+# documentation. The MSCGEN_PATH tag allows you to specify the directory where
+# the mscgen tool resides. If left empty the tool is assumed to be found in the
+# default search path.
+
+MSCGEN_PATH            =
+
+# 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
+
+# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is
+# allowed to run in parallel. When set to 0 (the default) doxygen will
+# base this on the number of processors available in the system. You can set it
+# explicitly to a value larger than 0 to get control over the balance
+# between CPU load and processing speed.
+
+DOT_NUM_THREADS        = 0
+
+# By default doxygen will use the Helvetica font for all dot files that
+# doxygen generates. When you want a differently looking font you can specify
+# the font name using DOT_FONTNAME. You need to make sure dot is able to find
+# the font, which can be done by putting it in a standard location or by setting
+# the DOTFONTPATH environment variable or by setting DOT_FONTPATH to the
+# directory containing the font.
+
+DOT_FONTNAME           = Helvetica
+
+# The DOT_FONTSIZE tag can be used to set the size of the font of dot graphs.
+# The default size is 10pt.
+
+DOT_FONTSIZE           = 10
+
+# By default doxygen will tell dot to use the Helvetica font.
+# If you specify a different font using DOT_FONTNAME you can use DOT_FONTPATH to
+# set the path where dot can find it.
+
+DOT_FONTPATH           =
+
+# 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
+# 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 the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for groups, showing the direct groups dependencies
+
+GROUP_GRAPHS           = YES
+
+# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
+# collaboration diagrams in a style similar to the OMG's Unified Modeling
+# Language.
+
+UML_LOOK               = NO
+
+# If set to YES, the inheritance and collaboration graphs will show the
+# relations between templates and their instances.
+
+TEMPLATE_RELATIONS     = NO
+
+# 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 CALL_GRAPH and HAVE_DOT options are set to YES then
+# doxygen will generate a call dependency graph for every global function
+# or class method. Note that enabling this option will significantly increase
+# the time of a run. So in most cases it will be better to enable call graphs
+# for selected functions only using the \callgraph command.
+
+CALL_GRAPH             = NO
+
+# If the CALLER_GRAPH and HAVE_DOT tags are set to YES then
+# doxygen will generate a caller dependency graph for every global function
+# or class method. Note that enabling this option will significantly increase
+# the time of a run. So in most cases it will be better to enable caller
+# graphs for selected functions only using the \callergraph command.
+
+CALLER_GRAPH           = NO
+
+# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
+# will generate a graphical hierarchy of all classes instead of a textual one.
+
+GRAPHICAL_HIERARCHY    = YES
+
+# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES
+# then doxygen will show the dependencies a directory has on other directories
+# in a graphical way. The dependency relations are determined by the #include
+# relations between the files in the directories.
+
+DIRECTORY_GRAPH        = YES
+
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
+# generated by dot. Possible values are svg, png, jpg, or gif.
+# If left blank png will be used. If you choose svg you need to set
+# HTML_FILE_EXTENSION to xhtml in order to make the SVG files
+# visible in IE 9+ (other browsers do not have this requirement).
+
+DOT_IMAGE_FORMAT       = png
+
+# If DOT_IMAGE_FORMAT is set to svg, then this option can be set to YES to
+# enable generation of interactive SVG images that allow zooming and panning.
+# Note that this requires a modern browser other than Internet Explorer.
+# Tested and working are Firefox, Chrome, Safari, and Opera. For IE 9+ you
+# need to set HTML_FILE_EXTENSION to xhtml in order to make the SVG files
+# visible. Older versions of IE do not have SVG support.
+
+INTERACTIVE_SVG        = NO
+
+# 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 in 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           =
+
+# The MSCFILE_DIRS tag can be used to specify one or more directories that
+# contain msc files that are included in the documentation (see the
+# \mscfile command).
+
+MSCFILE_DIRS           =
+
+# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of
+# nodes that will be shown in the graph. If the number of nodes in a graph
+# becomes larger than this value, doxygen will truncate the graph, which is
+# visualized by representing a node as a red box. Note that doxygen if the
+# number of direct children of the root node in a graph is already larger than
+# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note
+# that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
+
+DOT_GRAPH_MAX_NODES    = 50
+
+# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
+# graphs generated by dot. A depth value of 3 means that only nodes reachable
+# from the root by following a path via at most 3 edges will be shown. Nodes
+# that lay further from the root node will be omitted. Note that setting this
+# option to 1 or 2 may greatly reduce the computation time needed for large
+# code bases. Also note that the size of a graph can be further restricted by
+# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
+
+MAX_DOT_GRAPH_DEPTH    = 0
+
+# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
+# background. This is disabled by default, because dot on Windows does not
+# seem to support this out of the box. Warning: Depending on the platform used,
+# enabling this option may lead to badly anti-aliased labels on the edges of
+# a graph (i.e. they become hard to read).
+
+DOT_TRANSPARENT        = NO
+
+# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
+# files in one run (i.e. multiple -o and -T options on the command line). This
+# makes dot run faster, but since only newer versions of dot (>1.8.10)
+# support this, this feature is disabled by default.
+
+DOT_MULTI_TARGETS      = YES
+
+# 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 intermediate dot files that are used to generate
+# the various graphs.
+
+DOT_CLEANUP            = YES
diff --git a/jni/pjproject-android/.svn/pristine/c5/c5d1820cd0fecc10721dbc1b8b529b04f5228a56.svn-base b/jni/pjproject-android/.svn/pristine/c5/c5d1820cd0fecc10721dbc1b8b529b04f5228a56.svn-base
new file mode 100644
index 0000000..c086b01
--- /dev/null
+++ b/jni/pjproject-android/.svn/pristine/c5/c5d1820cd0fecc10721dbc1b8b529b04f5228a56.svn-base
@@ -0,0 +1,689 @@
+/* $Id$ */
+/*
+ * Copyright (C) 2013 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
+ */
+#ifndef __PJSUA2_PERSISTENT_HPP__
+#define __PJSUA2_PERSISTENT_HPP__
+
+/**
+ * @file pjsua2/persistent.hpp
+ * @brief PJSUA2 Persistent Services
+ */
+#include <pjsua2/types.hpp>
+
+#include <string>
+#include <vector>
+
+/** PJSUA2 API is inside pj namespace */
+namespace pj
+{
+
+/**
+ * @defgroup PJSUA2_PERSISTENT Persistent API
+ * @ingroup PJSUA2_Ref
+ * @{
+ * The persistent API provides functionality to read/write data from/to
+ * a document (string or file). The data can be simple data types such
+ * as boolean, number, string, and string arrays, or a user defined object.
+ * Currently the implementation supports reading and writing from/to JSON
+ * document, but the framework allows application to extend the API to
+ * support other document formats.
+ */
+
+using std::string;
+using std::vector;
+
+/* Forward declaration for ContainerNode */
+class ContainerNode;
+
+/**
+ * This is the abstract base class of objects that can be serialized to/from
+ * persistent document.
+ */
+class PersistentObject
+{
+public:
+    /**
+     * Read this object from a container node.
+     *
+     * @param node		Container to read values from.
+     */
+    virtual void readObject(const ContainerNode &node) throw(Error) = 0;
+
+    /**
+     * Write this object to a container node.
+     *
+     * @param node		Container to write values to.
+     */
+    virtual void writeObject(ContainerNode &node) const throw(Error) = 0;
+};
+
+
+/**
+ * This a the abstract base class for a persistent document. A document
+ * is created either by loading from a string or a file, or by constructing
+ * it manually when writing data to it. The document then can be saved
+ * to either string or to a file. A document contains one root ContainerNode
+ * where all data are stored under.
+ *
+ * Document is read and written serially, hence the order of reading must be
+ * the same as the order of writing. The PersistentDocument class provides
+ * API to read and write to the root node, but for more flexible operations
+ * application can use the ContainerNode methods instead. Indeed the read
+ * and write API in PersistentDocument is just a shorthand which calls the
+ * relevant methods in the ContainerNode. As a tip, normally application only
+ * uses the readObject() and writeObject() methods declared here to read/write
+ * top level objects, and use the macros that are explained in ContainerNode
+ * documentation to read/write more detailed data.
+ */
+class PersistentDocument
+{
+public:
+    /**
+     * Virtual destructor
+     */
+    virtual ~PersistentDocument()
+    {}
+
+    /**
+     * Load this document from a file.
+     *
+     * @param filename	The file name.
+     */
+    virtual void   	loadFile(const string &filename) throw(Error) = 0;
+
+    /**
+     * Load this document from string.
+     *
+     * @param input	The string.
+     */
+    virtual void   	loadString(const string &input) throw(Error) = 0;
+
+    /**
+     * Write this document to a file.
+     *
+     * @param filename	The file name.
+     */
+    virtual void   	saveFile(const string &filename) throw(Error) = 0;
+
+    /**
+     * Write this document to string.
+     *
+     * @return		The string document.
+     */
+    virtual string 	saveString() throw(Error) = 0;
+
+    /**
+     * Get the root container node for this document
+     *
+     * @return		The root node.
+     */
+    virtual ContainerNode & getRootContainer() const = 0;
+
+
+    /*
+     * Shorthand functions for reading and writing from/to the root container
+     */
+
+
+    /**
+     * Determine if there is unread element. If yes, then app can use one of
+     * the readXxx() functions to read it.
+     *
+     * @return		True if there is.
+     */
+    bool		hasUnread() const;
+
+    /**
+     * Get the name of the next unread element. It will throw Error if there
+     * is no more element to read.
+     *
+     * @return		The name of the next element .
+     */
+    string		unreadName() const throw(Error);
+
+    /**
+     * Read an integer value from the document and return the value.
+     * This will throw Error if the current element is not a number.
+     * The read position will be advanced to the next element.
+     *
+     * @param name	If specified, then the function will check if the
+     * 			name of the next element matches the specified
+     * 			name and throw Error if it doesn't match.
+     *
+     * @return		The value.
+     */
+    int			readInt(const string &name="") const throw(Error);
+
+    /**
+     * Read a float value from the document and return the value.
+     * This will throw Error if the current element is not a number.
+     * The read position will be advanced to the next element.
+     *
+     * @param name	If specified, then the function will check if the
+     * 			name of the next element matches the specified
+     * 			name and throw Error if it doesn't match.
+     *
+     * @return		The value.
+     */
+    float		readNumber(const string &name="") const throw(Error);
+
+    /**
+     * Read a boolean value from the container and return the value.
+     * This will throw Error if the current element is not a boolean.
+     * The read position will be advanced to the next element.
+     *
+     * @param name	If specified, then the function will check if the
+     * 			name of the next element matches the specified
+     * 			name and throw Error if it doesn't match.
+     *
+     * @return		The value.
+     */
+    bool		readBool(const string &name="") const throw(Error);
+
+    /**
+     * Read a string value from the container and return the value.
+     * This will throw Error if the current element is not a string.
+     * The read position will be advanced to the next element.
+     *
+     * @param name	If specified, then the function will check if the
+     * 			name of the next element matches the specified
+     * 			name and throw Error if it doesn't match.
+     *
+     * @return		The value.
+     */
+    string		readString(const string &name="") const throw(Error);
+
+    /**
+     * Read a string array from the container. This will throw Error
+     * if the current element is not a string array. The read position
+     * will be advanced to the next element.
+     *
+     * @param name	If specified, then the function will check if the
+     * 			name of the next element matches the specified
+     * 			name and throw Error if it doesn't match.
+     *
+     * @return		The value.
+     */
+    StringVector	readStringVector(const string &name="") const
+					 throw(Error);
+
+    /**
+     * Read the specified object from the container. This is equal to
+     * calling PersistentObject.readObject(ContainerNode);
+     *
+     * @param obj	The object to read.
+     */
+    void		readObject(PersistentObject &obj) const throw(Error);
+
+    /**
+     * Read a container from the container. This will throw Error if the
+     * current element is not an object. The read position will be advanced
+     * to the next element.
+     *
+     * @param name	If specified, then the function will check if the
+     * 			name of the next element matches the specified
+     * 			name and throw Error if it doesn't match.
+     *
+     * @return		Container object.
+     */
+    ContainerNode	readContainer(const string &name="") const
+				      throw(Error);
+
+    /**
+     * Read array container from the container. This will throw Error if the
+     * current element is not an array. The read position will be advanced
+     * to the next element.
+     *
+     * @param name	If specified, then the function will check if the
+     * 			name of the next element matches the specified
+     * 			name and throw Error if it doesn't match.
+     *
+     * @return		Container object.
+     */
+    ContainerNode	readArray(const string &name="") const
+				  throw(Error);
+
+    /**
+     * Write a number value to the container.
+     *
+     * @param name	The name for the value in the container.
+     * @param num	The value to be written.
+     */
+    void		writeNumber(const string &name,
+        		            float num) throw(Error);
+
+    /**
+     * Write a number value to the container.
+     *
+     * @param name	The name for the value in the container.
+     * @param num	The value to be written.
+     */
+    void		writeInt(const string &name,
+        		         int num) throw(Error);
+
+    /**
+     * Write a boolean value to the container.
+     *
+     * @param name	The name for the value in the container.
+     * @param value	The value to be written.
+     */
+    void		writeBool(const string &name,
+        		          bool value) throw(Error);
+
+    /**
+     * Write a string value to the container.
+     *
+     * @param name	The name for the value in the container.
+     * @param value	The value to be written.
+     */
+    void		writeString(const string &name,
+        		            const string &value) throw(Error);
+
+    /**
+     * Write string vector to the container.
+     *
+     * @param name	The name for the value in the container.
+     * @param arr	The vector to be written.
+     */
+    void		writeStringVector(const string &name,
+        		                  const StringVector &arr)
+					  throw(Error);
+
+    /**
+     * Write an object to the container. This is equal to calling
+     * PersistentObject.writeObject(ContainerNode);
+     *
+     * @param obj	The object to be written
+     */
+    void		writeObject(const PersistentObject &obj) throw(Error);
+
+    /**
+     * Create and write an empty Object node that can be used as parent
+     * for subsequent write operations.
+     *
+     * @param name	The name for the new container in the container.
+     *
+     * @return		A sub-container.
+     */
+    ContainerNode 	writeNewContainer(const string &name)
+					  throw(Error);
+
+    /**
+     * Create and write an empty array node that can be used as parent
+     * for subsequent write operations.
+     *
+     * @param name	The name for the array.
+     *
+     * @return		A sub-container.
+     */
+    ContainerNode 	writeNewArray(const string &name)
+				      throw(Error);
+};
+
+
+/**
+ * Forward declaration of container_node_op.
+ */
+struct container_node_op;
+
+
+/**
+ * Internal data for ContainerNode. See ContainerNode implementation notes
+ * for more info.
+ */
+struct container_node_internal_data
+{
+    void	*doc;		/**< The document.	*/
+    void	*data1;		/**< Internal data 1	*/
+    void	*data2;		/**< Internal data 2	*/
+};
+
+/**
+ * A container node is a placeholder for storing other data elements, which
+ * could be boolean, number, string, array of strings, or another container.
+ * Each data in the container is basically a name/value pair, with a type
+ * internally associated with it so that written data can be read in the
+ * correct type. Data is read and written serially, hence the order of
+ * reading must be the same as the order of writing.
+ *
+ * Application can read data from it by using the various read methods, and
+ * write data to it using the various write methods. Alternatively, it
+ * may be more convenient to use the provided macros below to read and write
+ * the data, because these macros set the name automatically:
+ *	- NODE_READ_BOOL(node,item)
+ *	- NODE_READ_UNSIGNED(node,item)
+ *	- NODE_READ_INT(node,item)
+ *	- NODE_READ_FLOAT(node,item)
+ *	- NODE_READ_NUM_T(node,type,item)
+ *	- NODE_READ_STRING(node,item)
+ *	- NODE_READ_STRINGV(node,item)
+ *	- NODE_READ_OBJ(node,item)
+ *	- NODE_WRITE_BOOL(node,item)
+ *	- NODE_WRITE_UNSIGNED(node,item)
+ *	- NODE_WRITE_INT(node,item)
+ *	- NODE_WRITE_FLOAT(node,item)
+ *	- NODE_WRITE_NUM_T(node,type,item)
+ *	- NODE_WRITE_STRING(node,item)
+ *	- NODE_WRITE_STRINGV(node,item)
+ *	- NODE_WRITE_OBJ(node,item)
+ *
+ * Implementation notes:
+ *
+ * The ContainerNode class is subclass-able, but not in the usual C++ way.
+ * With the usual C++ inheritance, some methods will be made pure virtual
+ * and must be implemented by the actual class. However, doing so will
+ * require dynamic instantiation of the ContainerNode class, which means
+ * we will need to pass around the class as pointer, for example as the
+ * return value of readContainer() and writeNewContainer() methods. Then
+ * we will need to establish who needs or how to delete these objects, or
+ * use shared pointer mechanism, each of which is considered too inconvenient
+ * or complicated for the purpose.
+ *
+ * So hence we use C style "inheritance", where the methods are declared in
+ * container_node_op and the data in container_node_internal_data structures.
+ * An implementation of ContainerNode class will need to set up these members
+ * with values that makes sense to itself. The methods in container_node_op
+ * contains the pointer to the actual implementation of the operation, which
+ * would be specific according to the format of the document. The methods in
+ * this ContainerNode class are just thin wrappers which call the
+ * implementation in the container_node_op structure.
+ *
+ */
+class ContainerNode
+{
+public:
+    /**
+     * Determine if there is unread element. If yes, then app can use one of
+     * the readXxx() functions to read it.
+     */
+    bool		hasUnread() const;
+
+    /**
+     * Get the name of the next unread element.
+     */
+    string		unreadName() const throw(Error);
+
+    /**
+     * Read an integer value from the document and return the value.
+     * This will throw Error if the current element is not a number.
+     * The read position will be advanced to the next element.
+     *
+     * @param name	If specified, then the function will check if the
+     * 			name of the next element matches the specified
+     * 			name and throw Error if it doesn't match.
+     *
+     * @return		The value.
+     */
+    int			readInt(const string &name="") const throw(Error);
+
+    /**
+     * Read a number value from the document and return the value.
+     * This will throw Error if the current element is not a number.
+     * The read position will be advanced to the next element.
+     *
+     * @param name	If specified, then the function will check if the
+     * 			name of the next element matches the specified
+     * 			name and throw Error if it doesn't match.
+     *
+     * @return		The value.
+     */
+    float		readNumber(const string &name="") const throw(Error);
+
+    /**
+     * Read a boolean value from the container and return the value.
+     * This will throw Error if the current element is not a boolean.
+     * The read position will be advanced to the next element.
+     *
+     * @param name	If specified, then the function will check if the
+     * 			name of the next element matches the specified
+     * 			name and throw Error if it doesn't match.
+     *
+     * @return		The value.
+     */
+    bool		readBool(const string &name="") const throw(Error);
+
+    /**
+     * Read a string value from the container and return the value.
+     * This will throw Error if the current element is not a string.
+     * The read position will be advanced to the next element.
+     *
+     * @param name	If specified, then the function will check if the
+     * 			name of the next element matches the specified
+     * 			name and throw Error if it doesn't match.
+     *
+     * @return		The value.
+     */
+    string		readString(const string &name="") const throw(Error);
+
+    /**
+     * Read a string array from the container. This will throw Error
+     * if the current element is not a string array. The read position
+     * will be advanced to the next element.
+     *
+     * @param name	If specified, then the function will check if the
+     * 			name of the next element matches the specified
+     * 			name and throw Error if it doesn't match.
+     *
+     * @return		The value.
+     */
+    StringVector	readStringVector(const string &name="") const
+					 throw(Error);
+
+    /**
+     * Read the specified object from the container. This is equal to
+     * calling PersistentObject.readObject(ContainerNode);
+     *
+     * @param obj	The object to read.
+     */
+    void		readObject(PersistentObject &obj) const throw(Error);
+
+    /**
+     * Read a container from the container. This will throw Error if the
+     * current element is not a container. The read position will be advanced
+     * to the next element.
+     *
+     * @param name	If specified, then the function will check if the
+     * 			name of the next element matches the specified
+     * 			name and throw Error if it doesn't match.
+     *
+     * @return		Container object.
+     */
+    ContainerNode	readContainer(const string &name="") const
+				      throw(Error);
+
+    /**
+     * Read array container from the container. This will throw Error if the
+     * current element is not an array. The read position will be advanced
+     * to the next element.
+     *
+     * @param name	If specified, then the function will check if the
+     * 			name of the next element matches the specified
+     * 			name and throw Error if it doesn't match.
+     *
+     * @return		Container object.
+     */
+    ContainerNode	readArray(const string &name="") const
+				  throw(Error);
+
+    /**
+     * Write a number value to the container.
+     *
+     * @param name	The name for the value in the container.
+     * @param num	The value to be written.
+     */
+    void		writeNumber(const string &name,
+        		            float num) throw(Error);
+
+    /**
+     * Write a number value to the container.
+     *
+     * @param name	The name for the value in the container.
+     * @param num	The value to be written.
+     */
+    void		writeInt(const string &name,
+        		         int num) throw(Error);
+
+    /**
+     * Write a boolean value to the container.
+     *
+     * @param name	The name for the value in the container.
+     * @param value	The value to be written.
+     */
+    void		writeBool(const string &name,
+        		          bool value) throw(Error);
+
+    /**
+     * Write a string value to the container.
+     *
+     * @param name	The name for the value in the container.
+     * @param value	The value to be written.
+     */
+    void		writeString(const string &name,
+        		            const string &value) throw(Error);
+
+    /**
+     * Write string vector to the container.
+     *
+     * @param name	The name for the value in the container.
+     * @param arr	The vector to be written.
+     */
+    void		writeStringVector(const string &name,
+        		                  const StringVector &arr)
+					  throw(Error);
+
+    /**
+     * Write an object to the container. This is equal to calling
+     * PersistentObject.writeObject(ContainerNode);
+     *
+     * @param obj	The object to be written
+     */
+    void		writeObject(const PersistentObject &obj) throw(Error);
+
+    /**
+     * Create and write an empty Object node that can be used as parent
+     * for subsequent write operations.
+     *
+     * @param name	The name for the new container in the container.
+     *
+     * @return		A sub-container.
+     */
+    ContainerNode 	writeNewContainer(const string &name)
+					  throw(Error);
+
+    /**
+     * Create and write an empty array node that can be used as parent
+     * for subsequent write operations.
+     *
+     * @param name	The name for the array.
+     *
+     * @return		A sub-container.
+     */
+    ContainerNode 	writeNewArray(const string &name)
+				      throw(Error);
+
+public:
+    /* internal data */
+    container_node_op *op;		/**< Method table.	*/
+    container_node_internal_data data;	/**< Internal data	*/
+};
+
+
+/**
+ * Pointer to actual ContainerNode implementation. See ContainerNode
+ * implementation notes for more info.
+ */
+//! @cond Doxygen_Suppress
+struct container_node_op
+{
+    bool		(*hasUnread)(const ContainerNode*);
+    string		(*unreadName)(const ContainerNode*)
+				      throw(Error);
+    float		(*readNumber)(const ContainerNode*,
+				      const string&)
+				      throw(Error);
+    bool		(*readBool)(const ContainerNode*,
+				    const string&)
+				    throw(Error);
+    string		(*readString)(const ContainerNode*,
+				      const string&)
+				      throw(Error);
+    StringVector	(*readStringVector)(const ContainerNode*,
+					    const string&)
+					    throw(Error);
+    ContainerNode	(*readContainer)(const ContainerNode*,
+					 const string &)
+					 throw(Error);
+    ContainerNode	(*readArray)(const ContainerNode*,
+				     const string &)
+				     throw(Error);
+    void		(*writeNumber)(ContainerNode*,
+				       const string &name,
+        		               float num)
+        		               throw(Error);
+    void		(*writeBool)(ContainerNode*,
+				     const string &name,
+        			     bool value)
+        			     throw(Error);
+    void		(*writeString)(ContainerNode*,
+				       const string &name,
+        			       const string &value)
+        			       throw(Error);
+    void		(*writeStringVector)(ContainerNode*,
+					     const string &name,
+        				     const StringVector &value)
+					     throw(Error);
+    ContainerNode 	(*writeNewContainer)(ContainerNode*,
+					     const string &name)
+					     throw(Error);
+    ContainerNode 	(*writeNewArray)(ContainerNode*,
+				         const string &name)
+					 throw(Error);
+};
+
+/*
+ * Convenient macros.
+ */
+#define NODE_READ_BOOL(node,item)	item = node.readBool(#item)
+#define NODE_READ_UNSIGNED(node,item)	item = (unsigned)node.readNumber(#item)
+#define NODE_READ_INT(node,item)	item = (int) node.readNumber(#item)
+#define NODE_READ_FLOAT(node,item)	item = node.readNumber(#item)
+#define NODE_READ_NUM_T(node,T,item)	item = (T)(int)node.readNumber(#item)
+#define NODE_READ_STRING(node,item)	item = node.readString(#item)
+#define NODE_READ_STRINGV(node,item)	item = node.readStringVector(#item)
+#define NODE_READ_OBJ(node,item)	node.readObject(item)
+
+#define NODE_WRITE_BOOL(node,item)	node.writeBool(#item, item)
+#define NODE_WRITE_UNSIGNED(node,item)	node.writeNumber(#item, (float)item)
+#define NODE_WRITE_INT(node,item)	node.writeNumber(#item, (float)item)
+#define NODE_WRITE_NUM_T(node,T,item)	node.writeNumber(#item, (float)item)
+#define NODE_WRITE_FLOAT(node,item)	node.writeNumber(#item, item)
+#define NODE_WRITE_STRING(node,item)	node.writeString(#item, item)
+#define NODE_WRITE_STRINGV(node,item)	node.writeStringVector(#item, item)
+#define NODE_WRITE_OBJ(node,item)	node.writeObject(item)
+
+//! @endcond
+
+/**
+ * @}  PJSUA2
+ */
+
+} // namespace pj
+
+
+
+#endif	/* __PJSUA2_PERSISTENT_HPP__ */
diff --git a/jni/pjproject-android/.svn/pristine/c5/c5ed1e2f5b3bc17b9ecf93a800ad491fa24e9920.svn-base b/jni/pjproject-android/.svn/pristine/c5/c5ed1e2f5b3bc17b9ecf93a800ad491fa24e9920.svn-base
new file mode 100644
index 0000000..28ab9ec
--- /dev/null
+++ b/jni/pjproject-android/.svn/pristine/c5/c5ed1e2f5b3bc17b9ecf93a800ad491fa24e9920.svn-base
@@ -0,0 +1,12 @@
+// libresample_dll.cpp : Defines the entry point for the DLL application.
+//
+#include <windows.h>
+
+BOOL APIENTRY DllMain( HANDLE hModule, 
+                       DWORD  ul_reason_for_call, 
+                       LPVOID lpReserved
+					 )
+{
+    return TRUE;
+}
+