| This is ccrtp.info, produced by makeinfo version 4.13 from ccrtp.texi. |
| |
| INFO-DIR-SECTION Development |
| START-INFO-DIR-ENTRY |
| * GNU ccRTP: (ccrtp). GNU ccRTP Real-Time Transport Protocol Framework. |
| END-INFO-DIR-ENTRY |
| |
| GNU ccRTP is a C++ class framework for the development of Real Time |
| Transport Protocol (RTP) based applications. It is based on GNU Common |
| C++. |
| |
| Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006 Federico Montesino |
| Pouzols <fedemp@altern.org>. Permission is granted to copy, distribute |
| and/or modify this document under the terms of the GNU Free |
| Documentation License, Version 1.2 or any later version published by |
| the Free Software Foundation; with no Invariant Sections, no |
| Front-Cover Texts, and no Back-Cover Texts. A copy of the license is |
| included in the section entitled "GNU Free Documentation License". |
| |
| |
| File: ccrtp.info, Node: Top, Next: Introduction, Up: (dir) |
| |
| GNU ccRTP Manual |
| **************** |
| |
| This manual describes GNU ccRTP, a C++ class framework for the |
| development of Real Time Transport Protocol (RTP) based applications. |
| |
| This is the edition 1.3 of this manual and documents GNU ccRTP |
| version 1.3. |
| |
| * Menu: |
| |
| * Introduction:: What RTP and ccRTP are. |
| * Distribution:: How to get GNU ccRTP. |
| * ccRTP Overview:: The library at a glance. |
| * Using ccRTP:: Programming with GNU ccRTP overview. |
| * Specialized Payload Formats:: Supported payload specific extensions. |
| * Standards Tracking:: IETF Standards conformance. |
| * Upgrading:: Upgrading applications based on old releases. |
| * ccRTP Internals:: How GNU ccRTP is done. |
| * Related Work:: Other RTP related libraries and tools. |
| * Future Work:: Future of RTP and ccRTP. |
| * Licenses:: Library and documentation licenses. |
| * Class and Data Type Index:: Index of classes and data types in ccRTP. |
| * Method and Function Index:: Index of methods and functions in ccRTP. |
| * Concept Index:: Index of concepts. |
| |
| |
| File: ccrtp.info, Node: Introduction, Next: Distribution, Prev: Top, Up: Top |
| |
| 1 Introduction |
| ************** |
| |
| ccRTP is a C++ framework for developing applications based on the Real |
| Time Transport Protocol (RTP henceforth). RTP provides end-to-end |
| delivery services for data with real-time characteristics and is being |
| developed by the Audio/Video Working Group of the Internet Engineering |
| Task Force (IETF). |
| |
| ccRTP aims to be an efficient and flexible framework valid for almost |
| any kind of application that uses RTP, ranging from high loaded servers |
| and gateways to personal phone applications. Default constructs and |
| values are provided however for the most common choices in the use of |
| RTP. ccRTP conforms to the latest RTP specifications (*note Standards |
| Tracking::). |
| |
| ccRTP is based on the GNU Common C++ framework, though most of the |
| library does not require it. Common C++ provides basic system services |
| such as threading, synchronization and sockets(1), which makes it |
| possible to provide a complete solution for the use of RTP. However, |
| although ccRTP provides facilities and abstractions useful for the RTP |
| specific components of applications that use RTP, such applications |
| generally require similar system services for other tasks. Besides |
| supporting ccRTP, Common C++ provides a portable and efficient |
| framework for these kind of services. |
| |
| RTP has been defined as an application level protocol framework |
| rather than a typical Internet transport protocol such as TCP and UDP. |
| Thus, RTP is hardly ever implemented as a layer separated from the |
| application. Consequently, RTP applications often must customize the |
| adaptable RTP packet layout and processing rules, timing constraints, |
| session membership rules as well as other RTP and RTCP mechanisms. |
| ccRTP aims to provide a framework for the RTP framework, rather than |
| being just an RTP packet manipulation library. |
| |
| As a clarification of the scope of the ccRTP library and the RTP |
| protocol, we note that ccRTP exclusively deals with the transport of |
| data over the RTP protocol. Once parameters such as destination IP |
| address and transport port, payload type identifier and timestamp |
| frequency are known, ccRTP can be used to open an RTP session and send |
| and receive RTP and RTCP packets. A multimedia application will have |
| those parameters previously set or, more usually, they can be fetched |
| for example from SDP multimedia session descriptions, which can be |
| interchanged (and negotiated) between servers and clients by means of |
| some signaling protocol: SIP, RTSP, or even H.323. Signaling functions |
| are not handled by ccRTP. |
| |
| This document is an introductory programmer's manual, for a more |
| exhaustive reference see the reference manual distributed with GNU |
| ccRTP. In *note ccRTP Overview::, the most important concepts and some |
| basic examples are introduced. A deeper and step by step description as |
| well as short examples are provided in *note Using ccRTP::. |
| |
| Finally, if after reading this document and/or using ccRTP you think |
| it fails to provide some functionality that seems to be needed for some |
| application, we encourage you to contact the developers of ccRTP and |
| ask or propose them improvements and/or additions. You are also |
| encouraged to provide these improvements and to join the development |
| team. Bug reports, suggestions and criticisms are gladly accepted. |
| |
| ---------- Footnotes ---------- |
| |
| (1) As well as other more specialized services, such as MD5 |
| computation. |
| |
| |
| File: ccrtp.info, Node: Distribution, Next: ccRTP Overview, Prev: Introduction, Up: Top |
| |
| 2 Distribution |
| ************** |
| |
| GNU ccRTP is free software (see |
| `http://www.gnu.org/philosophy/philosophy.html'. It is licensed under |
| the terms of the GNU General Public License, *Note GNU General Public |
| License::, plus a linking exception, *Note GNU ccRTP Linking |
| Exception::. |
| |
| The linking exception is the same that is used for gcc libstdc++. |
| This was done in the case of libstdc++ because the language of the LGPL |
| is neither clear nor correct if one uses C++ features such as templates |
| and method implimentation directly in headers, as the division between |
| the C++ library and another's application is no longer purely a linking |
| one. From the practical standpoint, the exact effect is the same as |
| the LGPL, but with language that matches these C++ features. This is |
| all explained at |
| `http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html'. |
| |
| This manual is licensed under the terms of the GNU Free |
| Documentation License, *Note GNU Free Documentation License::. |
| |
| There are several ways to get GNU ccRTP, refer to |
| `http://www.gnu.org' and `http://www.gnu.org/software/ccrtp/'. The |
| development of ccRTP is hosted at Savannah |
| `http://sv.gnu.org/projects/ccrtp/'. |
| |
| |
| File: ccrtp.info, Node: ccRTP Overview, Next: Using ccRTP, Prev: Distribution, Up: Top |
| |
| 3 ccRTP Overview |
| **************** |
| |
| At its highest level, ccRTP provides classes for the real-time |
| transport of data through RTP sessions, as well as the control |
| functions of RTCP. |
| |
| The main concept in the ccRTP implementation of RTP sessions is the |
| use of packet queues to handle transmission and reception of RTP data |
| packets/application data units. In ccRTP, a data block is transmitted |
| by putting it into the transmission (outgoing packets) queue, and |
| received by getting it from the reception (incoming packets) queue. |
| |
| Starting with 1.0 releases, ccRTP fully supports RTP and RTCP. Here |
| is a brief list of some features of ccRTP: |
| |
| * Highly extensible to specialized stacks. |
| |
| * Supports unicast, multi-unicast and multicast. Handles multiple |
| sources (including synchronization sources and contributing |
| sources) and destinations. Also supports symmetric RTP. |
| |
| * Automatic RTCP functions handling, such as association of |
| synchronization sources from the same participant or NTP-RTP |
| timestamp mapping. |
| |
| * Genericity as for underlying network and transport protocols |
| through templates. |
| |
| * It is threadsafe and supports almost any threading model. |
| |
| * Generic and extensible RTP and RTCP header validity checks. |
| |
| * Handles source states and information as well as statistics |
| recording. |
| |
| * Automatically handles SSRC collisions and performs loop detection. |
| |
| * Implements timer reconsideration and reverse reconsideration. |
| |
| * Provides good random numbers, based on `/dev/urandom' or, |
| alternatively, on MD5. |
| |
| |
| There are several levels of interface (public interface, public or |
| protected inheritance, etc) in ccRTP. For instance, the `rtphello' demo |
| program distributed with ccRTP just uses the public interface of the |
| `RTPSession' class and does not redefine the virtual method `onGotSR', |
| thus what this program knows about SR reports is the information |
| conveyed in the last sender report from any source, which can be |
| retrieved via the `getMRSenderInfo' method of the `SyncSource' class. |
| On the contrary, the `rtplisten' demo program redefines `onGotSR' by |
| means of inheritance and could do specialized processing of these RTCP |
| packets. Generally, both data and control packets are not directly |
| accessible through the most external interface. |
| |
| All these functions are performed through a few essential classes and |
| types. The most basic ones are the enumerated type `StaticPayloadType', |
| and the classes `StaticPayloadFormat' and `DynamicPayloadFormat'. The |
| most important ones are the classes `RTPSession', `SyncSource', |
| `Participant' and `AppDataUnit', that represent RTP sessions, |
| synchronization sources, participants in an RTP application, and |
| application data units conveyed in RTP data packets, respectively. |
| |
| In the next sections, two basic examples are presented. These |
| examples are intended to provide a concrete idea of what the code of a |
| ccRTP based application looks like, they are not complete or compilable |
| programs. You can find some real examples under the demo directory in |
| the source distribution of ccRTP. |
| |
| * Menu: |
| |
| * Simple Transmitter:: Skeleton of a simple transmitter. |
| * Simple Receiver:: Skeleton of a simple receiver. |
| |
| |
| File: ccrtp.info, Node: Simple Transmitter, Next: Simple Receiver, Up: ccRTP Overview |
| |
| 3.1 Simple Transmitter |
| ====================== |
| |
| The following snippet illustrates the required steps to send an |
| application data unit over RTP. |
| |
| RTPSession s(InetHostAddress("127.0.0.1"),8000); // bind reception socket |
| |
| // Initialization |
| cout << "Local SSRC identifier: " << s.getLocalSSRC() << endl; |
| s.addDestination("www.example.com",9000); // set one destination for packets |
| s.setPayloadFormat(staticPayloadFormat(sptPCMU)); |
| s.startRunning(); // start running the packet queue scheduler |
| |
| // Send data |
| s.putData(0,buffer,bufferLen); // buffer holds bufferLen payload octets |
| |
| |
| File: ccrtp.info, Node: Simple Receiver, Prev: Simple Transmitter, Up: ccRTP Overview |
| |
| 3.2 Simple Receiver |
| =================== |
| |
| The required actions to receive an application data unit over RTP are |
| listed in the following code snippet. |
| |
| RTPSession s(InetHostAddress("127.0.0.1"),9000); // bind reception socket. |
| |
| // Initialization. |
| cout << "Local SSRC identifier: " << s.getLocalSSRC() << endl; |
| s.setPayloadFormat(staticPayloadFormat(sptPCMU)); |
| s.startRunning(); // start running the packet queue scheduler. |
| |
| // Receive data. |
| const AppDataUnit* adu; |
| adu = s.getData(0); // get data with initial -0- timestamp. |
| if ( adu != NULL ) |
| // do something with adu. |
| // adu->getType() provides the payload type. |
| // adu->getData() provides a const uint8 pointer to a data buffer. |
| // adu->getSize() provides the number of octets in the buffer. |
| // see other methods in the class AppDataUnit, such as getSource(). |
| |
| |
| File: ccrtp.info, Node: Using ccRTP, Next: Specialized Payload Formats, Prev: ccRTP Overview, Up: Top |
| |
| 4 Using ccRTP |
| ************* |
| |
| When using ccRTP, both sending and receiving of data transported over |
| RTP sessions is done through reception and transmission queues handled |
| by the RTP stack. In the most common case, a separate execution thread |
| for each RTP session handles the queues. This case is the threading |
| model that we will generally assume throughout this document. Note |
| however that ccRTP supports other threading models, particularly ccRTP |
| supports the use of a single execution thread to serve a set of RTP |
| sessions. It is also possible to not associate any separate thread with |
| any RTP session, manually calling the main data and control service |
| methods from whatever other thread. |
| |
| The basic idea for packet reception with ccRTP is that the |
| application does not directly read packets from sockets but gets them |
| from a reception queue. The stack is responsible for inserting received |
| packets in the reception queue and handling this queue. In general, a |
| packet reception and insertion in the reception queue does not occur at |
| the same time the application gets it from the queue. |
| |
| Conversely, the basic idea for packet transmission with ccRTP is that |
| packets are not directly written to sockets but inserted in a |
| transmission queue handled by the stack. In general, packet insertion |
| and transmission occur at different times, though it is not necessary. |
| |
| In order to use ccRTP, you must include the main header (`#include |
| <ccrtp/rtp.h>'. Two additional headers are provided by ccRTP: |
| |
| ``#include <ccrtp/rtppool.h'' |
| Classes for pools of RTP service threads. |
| |
| ``#include <ccrtp/rtpext.h>'' |
| Classes for RTP extensions which are not mature yet. |
| |
| |
| You must also link in the library, currently `ccrtp1'. |
| |
| As presented in the last examples, before starting to send or receive |
| data, RTP sessions must be created, the payload format to use must be |
| set and the stack must be signaled to start running. The following |
| sections describe the use of ccRTP during the different phases of RTP |
| sessions and RTP applications in general. |
| |
| * Menu: |
| |
| * RTP Sessions:: Using ccRTP to establish RTP sessions. |
| * Payload Types and Formats:: Payload types and formats. |
| * Participants:: Participants and sources of synchronization. |
| * RTP Packets Extensions:: Extensions to RTP data packets handling. |
| * RTCP Packets Extensions:: Extensions to RTCP packets handling. |
| * Handling Events:: Table of ccRTP plug-ins to react to events. |
| |
| |
| File: ccrtp.info, Node: RTP Sessions, Next: Payload Types and Formats, Up: Using ccRTP |
| |
| 4.1 RTP Sessions |
| ================ |
| |
| This section discusses the use of `RTPSession' objects. Some other |
| classes and concepts are also used, these are just briefly presented |
| here; deeper explanations are provided in next sections. |
| |
| * Menu: |
| |
| * Initiating Sessions:: RTP sessions initialization with ccRTP. |
| * Sending Data:: Sending RTP data packets. |
| * Receiving Data:: Receiving RTP data packets. |
| * Closing Sessions:: Extensions to RTP data packets handling. |
| * Types of Sessions:: Choosing a threading and socket model. |
| |
| |
| File: ccrtp.info, Node: Initiating Sessions, Next: Sending Data, Up: RTP Sessions |
| |
| 4.1.1 Initiating Sessions |
| ------------------------- |
| |
| Initiating RTP sessions with ccRTP involves the construction of an |
| object of the class `RTPSession' and calling some optional |
| initialization methods. `RTPSession' constructors take two mandatory |
| arguments: local network address and local transport port (where |
| incoming packets are expected). There are two constructors, one of them |
| takes a host address as first parameter, while the other takes a |
| multicast address. In the latter case, the application will join to a |
| multicast group. |
| |
| General purpose RTP stacks of ccRTP, such as `RTPSession' objects, |
| must be signaled to start execution. This is done calling the |
| `startRunning()' method. Note there is also a `enableStack()' method, |
| this only activates the stack but does not start the execution of the |
| stack thread. |
| |
| After the steps above, the application can receive data, but will not |
| transmit to any destination. This and other session parameters can be |
| set as follows: |
| |
| * Add destinations: calling the method `addDestination'. |
| |
| * Set payload format. Method `setPayloadFormat'. By default, the |
| static payload type 0 is assumed (PCMU format at 8Khz). |
| |
| * Set local SDES Items. For common applications, the CNAME item |
| value is automatically guessed as user@host. Other items have no |
| default value and are not sent in RTCP packets unless a value is |
| specified by the application. For those items that should be sent |
| in RTCP packets along with the mandatory CNAME, its values can be |
| set calling the `setSDESItem' and `setPRIVPrefix' methods over |
| the object returned by the `defaultApplication' global function. |
| |
| * Enable padding of data packets. Calling setPadding(uint8) on |
| outgoing data queues enables transparent padding of data packets |
| to a multiple of the padding maximum length specified. By default, |
| padding is off (maximum length of padding is 0). |
| |
| * setting addresses: |
| |
| * Set session bandwidth calling the `setSessionBandwidth' method of |
| the session object. If not called, a default bandwidth of 64Kbps |
| is assumed, and 5% of this bandwidth is used for RTCP. This |
| percentage can be changed through the setControlBandwidth method. |
| |
| |
| |
| File: ccrtp.info, Node: Sending Data, Next: Receiving Data, Prev: Initiating Sessions, Up: RTP Sessions |
| |
| 4.1.2 Sending Data |
| ------------------ |
| |
| Data packets are sent through the method `putData', that takes as first |
| parameter the RTP timestamp for the data specified as second parameter. |
| ccRTP handles the random offset for the RTP timestamp internally, so |
| the timestamp value that corresponds to the session creation time is 0. |
| |
| By default, the marker bit of the sent packets is not set. Its value |
| for the next packet (the one that will convey the data provided in the |
| next call to `putData') can be set through the `setMark' method, which |
| takes a boolean as argument. |
| |
| ccRTP also supports fragmenting data blocks into several RTP |
| packets. The `setMaxSendSegmentSize' method can be used to request that |
| no RTP packet be transmitted with a payload length greater than the |
| value specified through `setMaxSendSegmentSize'. The default value of |
| this parameter can be retrieved via `getDefaultMaxSendSegmentSize', |
| which currently should return 65536. When data blocks greater than the |
| maximum segment size are provided through `putData', two or more packet |
| will be inserted in the outgoing packet queue. All these packets but |
| the last one will have length equal to the maximum segment size, |
| whereas the last one's size will be lower or equal to the maximum |
| segment size. |
| |
| |
| File: ccrtp.info, Node: Receiving Data, Next: Closing Sessions, Prev: Sending Data, Up: RTP Sessions |
| |
| 4.1.3 Receiving Data |
| -------------------- |
| |
| Received data is retrieved from the incoming packet queue through the |
| `getData' method, which, given a timestamp and an optional source of |
| synchronization. This method returns a pointer to an `AppDataUnit' |
| object as opposed to a pointer to a memory block. In ccRTP application |
| data units are represented through objects of the `AppDataUnit' class, |
| that provides access to the synchronization source of the data and |
| other related properties. |
| |
| The incoming packet queue takes care of functions such as packet |
| reordering or filtering out duplicate packets. |
| |
| You can guess if there are packets in the reception queue calling |
| `isWaiting'. Both `getData' and `isWaiting' take an optional parameter |
| which selects a particular synchronization source of data units. If not |
| specified, data units are returned regardless of its source. |
| |
| |
| File: ccrtp.info, Node: Closing Sessions, Next: Types of Sessions, Prev: Receiving Data, Up: RTP Sessions |
| |
| 4.1.4 Closing Sessions |
| ---------------------- |
| |
| RTP sessions can be closed deleting or destroying `RTPSession' objects. |
| The stack sends a BYE packet to every destination when the destructor |
| of sessions is called. It is also possible to explicitly send a BYE |
| packet through the dispatchBYE method, which takes the leaving reason |
| string as argument. Note that dispatchBYE will honor a number of rules |
| for sending BYE packets specified in the RTP standard: a BYE packet is |
| not sent if no RTP/RTCP packet was sent, and BYE floods avoiding |
| mechanisms are employed. |
| |
| Note that when a BYE RTCP packet is received from a remote |
| participant, the virtual `onGotGoodbye' will be called. |
| |
| |
| File: ccrtp.info, Node: Types of Sessions, Prev: Closing Sessions, Up: RTP Sessions |
| |
| 4.1.5 Types of Sessions |
| ----------------------- |
| |
| _TODO:_ explain how to instantiate templates depending on the threading |
| model and the number of sockets to use. Also symmetric |
| channels/sessions. Describe what's a channel and a session. |
| |
| |
| File: ccrtp.info, Node: Payload Types and Formats, Next: Participants, Prev: RTP Sessions, Up: Using ccRTP |
| |
| 4.2 Payload Types and Formats |
| ============================= |
| |
| In the context of RTP, an RTP payload type is a 7-bit numeric |
| identifier that identifies a payload format. For payload types, GNU |
| ccRTP defines the integer type `PayloadType'. ccRTP also defines The |
| enumerated type `StaticPayloadType', as the enumeration of the RTP |
| Payload Types statically assigned for standard audio and video formats. |
| |
| These codes were initially specified in `RFC 1890, "RTP Profile for |
| Audio and Video Conferences with Minimal Control" (AVP profile)', |
| superseded by `RFC 3550', and are registered as MIME types in `RFC |
| 3555'. Codes below 96 may be assigned statically, although the default |
| bindings for many of them are already reserverd. Codes in the range |
| 96-127 are assigned dinamically by means outside of the RTP profile or |
| protocol specification. |
| |
| See the "RTP Parameters" list at IANA |
| `http://www.iana.org/assignments/rtp-parameters'. Note however that |
| registering static payload types is now considered a deprecated |
| practice in favor of dynamic payload type negotiation. |
| |
| The properties of a payload format that, as an RTP stack, ccRTP |
| takes into account are the payload type (numeric identifier) and the |
| RTP clock rate. Other properties, such as MIME type, number of audio |
| channels, "ptime" and "maxptime" are not considered. These are only of |
| interest for higher level protocols, such as SDP and H.245. |
| |
| GNU ccRTP defines a hierarchy of payload format classes. Its root is |
| `PayloadFormat', which is a base class for `StaticPayloadFormat' and |
| `DynamicPayloadFormat'. |
| |
| Static payload format objects are built from a static payload code. |
| These are defined in the enumerated type `StaticPayloadType'. The |
| following example constructs a `StaticPayloadFormat' object |
| corresponding to the payload type 0 (statically bounded to PCMA in `RFC |
| 3551'): |
| |
| StaticPayloadType pt = sptPCMU; |
| StaticPayloadFormat* spf = new StaticPayloadFormat(pt); |
| |
| Of course, we could have said: |
| |
| StaticPayloadFormat* spf = new StaticPayloadFormat(sptPCMA); |
| |
| StaticPayloadFormat objects build like the ones above hold the |
| necessary parameters so that the RTP stack can handle incoming and |
| outgoing packets. |
| |
| Regarding dynamic payload formats, a call to |
| `DynamicPayloadFormat::DynamicPayloadFormat(100,90000)' like the |
| following: |
| |
| DynamicPayloadFormat* dpf = new DynamicPayloadFormat(100,90000); |
| |
| Will construct a dynamic payload format object that ties together the |
| '100' payload type numeric identifier and an RTP clock rate of 90 Khz. |
| Note that the numeric identifier does not have to be in the dynamic |
| range. The static payload types are default bindings and MAY be |
| overriden, thus, DynamicPayloadFormat(0,90000) is a valid construct |
| provided 0 has been established as the payload type through a previous |
| negotiation process(1). |
| |
| Whether and how the payload has been negotiated is outside of the |
| scope of RTP and ccRTP, so applications must choose between |
| `StaticPayloadFormat' and `DynamicPayloadFormat' accordingly to their |
| multimedia session control mechanisms. |
| |
| ---------- Footnotes ---------- |
| |
| (1) Despite the fact that RFC 3551 defines a static binding of the 0 |
| code to mu-law PCM at 8Khz. |
| |
| |
| File: ccrtp.info, Node: Participants, Next: RTP Packets Extensions, Prev: Payload Types and Formats, Up: Using ccRTP |
| |
| 4.3 Participants And Sources of Synchronization |
| =============================================== |
| |
| In GNU ccRTP, there are classes that represent RTP applications |
| (`RTPApplication'), participants (`Participant'), synchronizacion |
| sources (`SyncSource') and RTP sessions (`RTPSession'). The relations |
| among these entities are shown in the following diagram: |
| |
| --------------- |
| --------------------| Participant |-------------------- |
| | 0:n --------------- 0:1 | |
| | 1 1:n | |
| ------------------ ---------------- |
| | RTPApplication | | SyncSource | |
| ------------------ ---------------- |
| | 1 0:n | |
| | --------------- | |
| --------------------| RTPSession |-------------------- |
| 0:n --------------- 1 |
| |
| An RTP application establishes a space of CNAME identifiers, whereas |
| an RTP session establishes a space of SSRC identifiers. |
| |
| For each source of synchronization seen in an RTP session, a |
| `SyncSource' object identified by a SSRC numeric identifier is created. |
| Thus, at the beginning of an RTP session there are no `SyncSource' |
| objects related. Note that, if the local source sends packets to itself |
| during an RTP session, a `SyncSource' object will be created for it. |
| |
| The list of sources of synchronization identified in an RTP session |
| can be retrived through STL-like iterators of type |
| `RTPSession::SyncSourcesIterator', as shown in the following example. |
| |
| // rx is an RTPSession object |
| RTPSession::SyncSourcesIterator it; |
| for (it = rx.begin() ; it != rx.end(); it++) { |
| const SyncSource &s = *it; |
| cout << s.getID(); |
| if ( s.isSender() ) |
| cout << "is an active sender"; |
| cout << endl; |
| } |
| |
| Note `RTPSession::SyncSourcesIterator' is a const iterator. |
| |
| When using RTCP, it is possible to associate several synchronization |
| source objects to a participant in the multimedia session, which is |
| represented through the association between `Participant' and |
| `SyncSource' objects. The participant object linked to a source of |
| synchronization can be retrieved through the |
| `SyncSource::getParticipant()' method, as the following examples shows: |
| |
| // s is a source of synchronization object (SyncSource) |
| Participant *p = s.getParticipant(); |
| cerr << p->getSDESItem(SDESItemTypeCNAME) << endl; |
| |
| When RTCP is not being used or the CNAME identifier corresponding to |
| a synchronization source has not been received yet, the participant |
| associated with a synchronization source is not known. In these cases, |
| the method `SyncSource::getParticipant()' will return a NULL pointer. |
| On the contrary, a participant is always related to a synchronization |
| source at least. It can also be related to more than one |
| synchronization source (for instance, when a participant in a |
| videoconference sends two video streams from two different chameras). |
| Note that, if the local source sends data and control packets to |
| itself, a `Participant' object will be created for it. |
| |
| Thus, the `SyncSource::getParticipant' provides a facility for |
| inter-media synchronization. |
| |
| The association of RTP sessions and participants with |
| `RTPApplication' objects makes it possible to implement several "RTP |
| applications" in the same application or process, each one having a |
| separate CNAME space. By default, all RTP sessions are associated to an |
| RTP application provided by the global method `defaultApplication()'. |
| The local CNAME for the default application is guessed from the user |
| and machine name, as specified in `RFC 3550'. |
| |
| However, other applications may be created through the constructor |
| `RTPApplication::RTPApplication(const std::string& cname)'. RTP |
| sessions are associated with applications other than the default via an |
| optional constructor parameter. |
| |
| Similarly to the list of synchronization sources, the list of |
| participants in a session can be retrieved using iterators of type |
| `RTPApplication::ParticipantsIterator', see the following example, |
| which shows the list of CNAMEs of the participants in the default |
| application: |
| |
| RTPApplication &app = defaultApplication(); |
| RTPApplication::ParticipantsIterator ai; |
| for ( ai = app.begin(); ai != app.end(); ai++ ) { |
| const Participant &p = *ai; |
| cerr << p.getSDESItem(SDESItemTypeCNAME) << endl; |
| } |
| |
| Note `RTPApplication::ParticipantsIterator' is a const iterator. |
| |
| _TODO: SyncSource states_. |
| |
| |
| File: ccrtp.info, Node: RTP Packets Extensions, Next: RTCP Packets Extensions, Prev: Participants, Up: Using ccRTP |
| |
| 4.4 RTP Packets Extensions |
| ========================== |
| |
| _TODO._ Describe `RTPPacket', `IncomingRTPPkt' and `OutgoingRTPPkt' |
| classes. *Note RTP Packets Arrival::, for a discussion of event |
| handling virtuals that allow for specialized processing of data packets. |
| |
| |
| File: ccrtp.info, Node: RTCP Packets Extensions, Next: Handling Events, Prev: RTP Packets Extensions, Up: Using ccRTP |
| |
| 4.5 RTCP Packets Extensions |
| =========================== |
| |
| *Note RTCP Packets Arrival::, for a discussion of event handling |
| virtuals that allow for specialized processing of control packets. |
| |
| |
| File: ccrtp.info, Node: Handling Events, Prev: RTCP Packets Extensions, Up: Using ccRTP |
| |
| 4.6 Handling Events |
| =================== |
| |
| There are a number of events that may require special response from the |
| application. ccRTP defines plug-ins to handle these events. |
| |
| * Menu: |
| |
| * RTP Packets Arrival:: Filtering and extending RTP packets parsing. |
| * RTCP Packets Arrival:: Filtering and extending RTCP packets parsing. |
| * Synchronization Source States:: Handling state transitions. |
| * SSRC Collisions:: Handling SSRC identifier collisions. |
| * RTP Packets Expiration:: Outgoing and incoming RTP packets expiration. |
| |
| |
| File: ccrtp.info, Node: RTP Packets Arrival, Next: RTCP Packets Arrival, Up: Handling Events |
| |
| 4.6.1 RTP Packets Arrival |
| ------------------------- |
| |
| `onRTPPacketRecv' is the virtual method that may be redefined in any |
| subclass of `IncomingDataQueue', particularly in subclasses of |
| `RTPSession'. It takes an `IncomingRTPPkt' object as argument and |
| returns a boolean indicating whether the packet should be inserted in |
| the reception queue. |
| |
| |
| File: ccrtp.info, Node: RTP Packets Expiration, Prev: SSRC Collisions, Up: Handling Events |
| |
| 4.6.2 RTP Packets Expiration |
| ---------------------------- |
| |
| `onExpireSend' and `onExpireRecv' |
| |
| `end2EndDelayed' |
| |
| |
| File: ccrtp.info, Node: RTCP Packets Arrival, Next: Synchronization Source States, Prev: RTP Packets Arrival, Up: Handling Events |
| |
| 4.6.3 RTCP Packets Arrival |
| -------------------------- |
| |
| Incoming RTCP packets are automatically handled by ccRTP. However, this |
| does not mean you can't track the reception of RTCP packets. |
| |
| * `onGotSR' |
| |
| * `onGotRR' |
| |
| * `onGotSDESChunk' |
| |
| * `onGotAPP' |
| |
| * `onGotRRSRExtension' |
| |
| |
| Note that this events correspond to RTCP packets, not RTCP compound |
| packets, and probably the reception of a compound packet will trigger |
| more than one of these events. |
| |
| |
| File: ccrtp.info, Node: Synchronization Source States, Next: SSRC Collisions, Prev: RTCP Packets Arrival, Up: Handling Events |
| |
| 4.6.4 Synchronization Source States |
| ----------------------------------- |
| |
| `onNewSyncSource'. |
| |
| |
| File: ccrtp.info, Node: SSRC Collisions, Next: RTP Packets Expiration, Prev: Synchronization Source States, Up: Handling Events |
| |
| 4.6.5 SSRC Collisions |
| --------------------- |
| |
| `onSSRCCollision'. |
| |
| |
| File: ccrtp.info, Node: Specialized Payload Formats, Next: Standards Tracking, Prev: Using ccRTP, Up: Top |
| |
| 5 Specialized Payload Formats |
| ***************************** |
| |
| _TODO:_ finish 2833bis and CN. |
| |
| _TODO:_ comment H.261 specific RTCP packets: FIR and NACK. |
| |
| |
| File: ccrtp.info, Node: Standards Tracking, Next: Upgrading, Prev: Specialized Payload Formats, Up: Top |
| |
| 6 Standards Tracking |
| ******************** |
| |
| _TODO: explain what is done/being done/planned_. |
| |
| * `RTP: A Transport Protocol for Real-Time Applications (RFC 3550, |
| which supersedes RFC 1889)'. |
| |
| * `RTP Profile for Audio and Video Conferences with Minimal Control |
| (RFC 3551, which supersedes RFC 1890)'. |
| |
| * `MIME Type Registration of RTP Payload Formats (RFC 3555)'. |
| |
| * `IANA RTP Parameters'. |
| |
| * `RTP Payload Format for H.261 Video Streams (RFC 2032)'. Defines |
| H.261 specific FIR and NACK RTCP packets. |
| |
| |
| Not yet implemented: |
| |
| * `The Secure Real-time Transport Protocol'. SRTP provile. |
| |
| * `Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)'. |
| |
| * `Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)'. |
| |
| * `Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)'. |
| |
| |
| |
| File: ccrtp.info, Node: Upgrading, Next: ccRTP Internals, Prev: Standards Tracking, Up: Top |
| |
| 7 Upgrading |
| *********** |
| |
| This chapter outlines the main steps required to upgrade applications |
| written for old releases of ccRTP (0.6.x, 0.7.x and 0.9.x series) to |
| the 1.0 series. It is written mostly as a recipe of replacements for |
| old constructs. |
| |
| Replace `#include <cc++/rtp.h>' with `#include <ccrtp/rtp.h>'(1). |
| |
| Changes that have to do more with Common C++ 2 than with ccRTP: |
| |
| `exit(int)' |
| Replace with exit() |
| |
| `Thread::Terminate()' |
| Replace with Thread::terminate() |
| |
| `ccxx_sleep(timeout_t)' |
| Replace with sleep(timeout_t). |
| |
| `Thread::Run()' |
| Replace with Thread::run() |
| |
| |
| Changes required by ccRTP itself: |
| |
| `RTPSource' |
| Now `SyncSource', and is a somewhat different concept. For |
| instance, calls to RTPSource::getID() must be replaced with calls |
| to SyncSource::getID(), which in most cases will not imply any |
| change to this part of the code. |
| |
| `RTPQueue::getLocalInfo()->getID()' |
| Replace with `RTPQueueBase::getLocalSSRC()' |
| |
| `RTPQueue::getCNAME()' |
| Replace with `defaultApplication().getSDESItem(SDESItemTypeSDES)'. |
| |
| `RTPQueue::getPacket()' |
| `getPacket()' has been removed and now there is only a `getData()' |
| method in the RTP queues. |
| |
| `RTPQueue::setTimeout()' |
| Replace calls to RTPQueue::setTimeout(microtimeout_t) with calls to |
| OutgoingDataQueue(microtimeout_t), whose purpose and working is |
| exactly the same. |
| |
| `RTPQueue::putPacket()' |
| `putPacket()' has been removed and now there is only a `putData()' |
| method in the RTP queues. Note also that now the payload type is |
| not specified for each outgoing RTP data block, instead use |
| RTPQueueBase::setPayloadFormat each time the payload type changes. |
| |
| `PayloadType' |
| The definition of payload types has deeply changed in order to |
| allow all standard uses of dynamic payload negotiation. Refer to |
| *note Payload Types and Formats::, for an explanation of the new |
| payload types and formats related classes. |
| |
| For example, `RTP_PAYLOAD_PCMU' must be replaced with something |
| like `StaticPayloadFormat pcmu(sptPCMU)', where `pcmu' is the name |
| of a static payload object that binds an statically assigned |
| `PayloadType' (2). to its corresponding RTP clock rate(3). |
| |
| `RTPSocket::Connect' |
| The call connect has been removed. Now, in order to send packets |
| to a destination `OutgoingDataQueue::addDestination' must be used. |
| It allows for setting more than one destination. Any destination |
| can actually be added more than one time with addDestination, |
| which can be used a simple trick to perform redundant |
| transmission: each packet -both RTP and RTCP- will be transmitted |
| to the destination as many times as it has been added to the list |
| of destinations through calling addDestination. |
| |
| `RTPQueue::getCurrentRate' |
| Replace with `RTPQueueBase::getCurrentRTPClockRate()'. |
| |
| `RTPSocket::Start' |
| Replace with `RTPSession::startRunning'. |
| |
| `RTPQueue::gotHello' |
| Replace with `QueueRTCPManager::onNewSyncSource'. |
| |
| `RTPQueue::gotGoodbye' |
| Replace with `QueueRTCPManager::onGotGoodbye'. |
| |
| |
| ---------- Footnotes ---------- |
| |
| (1) Note that unfortunately ccRTP 1.0pre0 used `#include |
| <cc++/rtp/rtp.h', which is now deprecated. |
| |
| (2) The static payload type 0 corresponds to the audio format PCMU, |
| see `RFC 3550'. |
| |
| (3) 8 khz. |
| |
| |
| File: ccrtp.info, Node: ccRTP Internals, Next: Related Work, Prev: Upgrading, Up: Top |
| |
| 8 ccRTP Internals |
| ***************** |
| |
| * Menu: |
| |
| * Internals Overview:: ccRTP internals overview. |
| * Collisions and Loops:: Collision Resolution and Loop Detection. |
| * Algorithms in the Standard:: Implementation of algorithms in the standard. |
| |
| |
| File: ccrtp.info, Node: Internals Overview, Next: Collisions and Loops, Up: ccRTP Internals |
| |
| 8.1 Internals Overview |
| ====================== |
| |
| _TODO: Explain where on how timer reconsideration/reverse recons. is |
| performed_. |
| |
| Performance: |
| |
| * Zero copy stack. |
| |
| * RW/R multithreading. |
| |
| * Fast specialized linked list and hash mechanisms. |
| |
| |
| File: ccrtp.info, Node: Collisions and Loops, Next: Algorithms in the Standard, Prev: Internals Overview, Up: ccRTP Internals |
| |
| 8.2 Collisions and Loops |
| ======================== |
| |
| ccRTP performs loop detection (following 8.2 in `RFC 3550', though the |
| algorithm in ccRTP differs is structure because of two reasons: |
| |
| * ccRTP holds a table of source for which some packet has been |
| received, instead of a table with all the sources in the session |
| (i.e. the local source is not included in the table unless it |
| sends packets to itself). |
| |
| * RTP and RTCP packets are handled separately whereas the algorithm |
| in 8.2 treats both. |
| |
| Note that the first two conditions in 8.2 (creating new source |
| entries and setting source transport address) are handled in the |
| SSRC bookkeeping methods rather than mixing them with the real |
| collisions and loop handling. |
| |
| Unlike the algorithm given in 8.2, the ccRTP algorithm detects the |
| very rare case when two sources on the same host use the same SSRC |
| identifier and the first RTP packet for that identifier is |
| received from one source and the first RTCP is received from the |
| other. |
| |
| |
| |
| File: ccrtp.info, Node: Algorithms in the Standard, Prev: Collisions and Loops, Up: ccRTP Internals |
| |
| 8.3 Algorithms in the Standard |
| ============================== |
| |
| The following sections summarizes how the algorithms specified in |
| appendixes from `RFC 3550' are implemented in ccRTP. A "mapping" |
| between routines in the RFC and methods/routines in ccRTP is provided. |
| |
| * Menu: |
| |
| * A.1:: RTP Data Header Validity Checks. |
| * A.2:: RTCP Header Validity Checks. |
| * A.3:: Determining the Number of RTP Packets Expected and Lost. |
| * A.4:: Generating SDES RTCP Packets. |
| * A.5:: Parsing RTCP SDES Packets. |
| * A.6:: Generating a Random 32-bit Identifier. |
| * A.7:: Computing the RTCP Transmission Interval. |
| * A.8:: Estimating the Interarrival Jitter. |
| |
| |
| File: ccrtp.info, Node: A.1, Next: A.2, Up: Algorithms in the Standard |
| |
| 8.3.1 A.1 |
| --------- |
| |
| ccRTP performs RTP data header validity check in two stages: the first |
| stage, performed at the constructor of `IncomingRTPPkt' (which is |
| extensible with virtual methods) validates the header fields |
| independent of the source. The second stage, performed at |
| `IncomingDataQueue::checkSSRCInIncomingRTPPkt' and |
| `QueueRTCPManager::checkSSRCInRTCPPkt', validates those fields specific |
| to the source of the packet (number sequence, etc). |
| |
| Additionally, the following table specifies which methods of ccRTP |
| implement the functions init_seq and update_seq from A.1. |
| |
| `void init_seq(source*, u_int16)' |
| void MembershipBookkeeping::SyncSourceLink::initSequence(uint16) |
| |
| `int update_seq(source*, u_int16)' |
| bool RTPQueue::recordReception(SyncSourceLink&, const |
| IncomingRTPPkt&) |
| |
| |
| |
| File: ccrtp.info, Node: A.2, Next: A.3, Prev: A.1, Up: Algorithms in the Standard |
| |
| 8.3.2 A.2 |
| --------- |
| |
| The code in A.2 corresponds to |
| `RTCPCompoundHandler::checkCompountRTCPHeader'. |
| |
| |
| File: ccrtp.info, Node: A.3, Next: A.4, Prev: A.2, Up: Algorithms in the Standard |
| |
| 8.3.3 A.3 |
| --------- |
| |
| Code in A.3 corresponds to `MembershipBookeeping::computeStats'. |
| |
| |
| File: ccrtp.info, Node: A.4, Next: A.5, Prev: A.3, Up: Algorithms in the Standard |
| |
| 8.3.4 A.4 |
| --------- |
| |
| Code in A.4 is implemented as part of the method |
| `QueueRTCPManager::packSDES'. |
| |
| |
| File: ccrtp.info, Node: A.5, Next: A.6, Prev: A.4, Up: Algorithms in the Standard |
| |
| 8.3.5 A.5 |
| --------- |
| |
| Code in A.5 is implemented in the method `QueueRTCPManager::onGotSDES', |
| which calls the virtual method `QueueRTCPManager::onGotSDESChunk' to |
| process each SDES chunk. |
| |
| |
| File: ccrtp.info, Node: A.6, Next: A.7, Prev: A.5, Up: Algorithms in the Standard |
| |
| 8.3.6 A.6 |
| --------- |
| |
| On POSIX systems, ccRTP uses `/dev/urandom' when available. If there is |
| no such device, it defaults to the MD5 based algorithm given in |
| appendix A.6. |
| |
| Code in A.6 corresponds to `uint32 MD5BasedRandom32()', which is |
| called by `uint32 random32()' when no random device is available. |
| |
| |
| File: ccrtp.info, Node: A.7, Next: A.8, Prev: A.6, Up: Algorithms in the Standard |
| |
| 8.3.7 A.7 |
| --------- |
| |
| Mapping: |
| |
| `double rtcp_interval(int, int, double, int, double, int)' |
| virtual timeval QueueRTCPManager::computeRTCPInterval(), and in |
| timeval (seconds + microseconds) units, instead of seconds. |
| |
| `OnExpire(event, int, int, double, int, double, int time_tp, time_tp, int)' |
| QueueRTCPManager::runControlService(microtimeout_t) (this method |
| also implements part of SendRTCPReport(e)) |
| |
| `OnReceive(packet, event, int, int, int, double, double, double, double)' |
| void QueueRTCPManager::takeInControlPacket() and |
| QueueRTCPManager::runControlService(microtimeout_t) |
| |
| `Schedule(time, event) and Reschedule(time, event)' |
| No equivalent. |
| |
| `SendRTCPReport(event)' |
| `dispatchControlPacket'. |
| |
| `SendBYEPacket(event)' |
| `QueueRTCPManager::dispatchBYE(const std::string& reason)'. |
| |
| `TypeOfEvent(event)' |
| No equivalent. |
| |
| `PacketType(p)' |
| No equivalent. |
| |
| `ReceivedPacketSize()' |
| `size_t IncomingDataQueue::takeInDataPacket()'. |
| |
| `SentPacketSize()' |
| `size_t OutgoingDataQueue::dispatchDataPacket()' -data, and |
| `size_t QueueRTCPManager::dispatchControlPacket()' -control. |
| |
| `NewMember(p)' |
| |
| `NewSender(p)' |
| |
| `AddMember() and RemoveMember()' |
| |
| `AddSender() and RemoveSender()' |
| |
| |
| File: ccrtp.info, Node: A.8, Prev: A.7, Up: Algorithms in the Standard |
| |
| 8.3.8 A.8 |
| --------- |
| |
| Interarrival jitter is estimated as specified in A.8, in |
| `recordReception'. Jitter is kept as a float. |
| |
| |
| File: ccrtp.info, Node: Related Work, Next: Future Work, Prev: ccRTP Internals, Up: Top |
| |
| 9 Related Work |
| ************** |
| |
| _TODO_. Other free RTP stacks and tools: |
| |
| * jrtplib |
| |
| * oRTP |
| |
| * LIVE.COM Streaming Media |
| |
| * UCL Common Code Library. Note this library is distributed under a |
| BSD license _with_ the obnoxious clausule. |
| |
| |
| File: ccrtp.info, Node: Future Work, Next: Licenses, Prev: Related Work, Up: Top |
| |
| 10 Future Work |
| ************** |
| |
| _TODO_. |
| |
| |
| File: ccrtp.info, Node: Licenses, Next: Class and Data Type Index, Prev: Future Work, Up: Top |
| |
| Appendix A Licenses |
| ******************* |
| |
| * Menu: |
| |
| * GNU Free Documentation License:: License for this document. |
| * GNU General Public License:: ccRTP Base License. |
| * GNU ccRTP Linking Exception:: ccRTP linking exception. |
| |
| |
| File: ccrtp.info, Node: GNU General Public License, Next: GNU ccRTP Linking Exception, Prev: GNU Free Documentation License, Up: Licenses |
| |
| A.1 GNU GENERAL PUBLIC LICENSE |
| ============================== |
| |
| Version 2, June 1991 |
| |
| Copyright (C) 1989, 1991 Free Software Foundation, Inc. |
| 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA |
| |
| Everyone is permitted to copy and distribute verbatim copies |
| of this license document, but changing it is not allowed. |
| |
| A.1.1 Preamble |
| -------------- |
| |
| The licenses for most software are designed to take away your freedom |
| to share and change it. By contrast, the GNU General Public License is |
| intended to guarantee your freedom to share and change free |
| software--to make sure the software is free for all its users. This |
| General Public License applies to most of the Free Software |
| Foundation's software and to any other program whose authors commit to |
| using it. (Some other Free Software Foundation software is covered by |
| the GNU Library General Public License instead.) You can apply it to |
| your programs, too. |
| |
| When we speak of free software, we are referring to freedom, not |
| price. Our General Public Licenses are designed to make sure that you |
| have the freedom to distribute copies of free software (and charge for |
| this service if you wish), that you receive source code or can get it |
| if you want it, that you can change the software or use pieces of it in |
| new free programs; and that you know you can do these things. |
| |
| To protect your rights, we need to make restrictions that forbid |
| anyone to deny you these rights or to ask you to surrender the rights. |
| These restrictions translate to certain responsibilities for you if you |
| distribute copies of the software, or if you modify it. |
| |
| For example, if you distribute copies of such a program, whether |
| gratis or for a fee, you must give the recipients all the rights that |
| you have. You must make sure that they, too, receive or can get the |
| source code. And you must show them these terms so they know their |
| rights. |
| |
| We protect your rights with two steps: (1) copyright the software, |
| and (2) offer you this license which gives you legal permission to copy, |
| distribute and/or modify the software. |
| |
| Also, for each author's protection and ours, we want to make certain |
| that everyone understands that there is no warranty for this free |
| software. If the software is modified by someone else and passed on, we |
| want its recipients to know that what they have is not the original, so |
| that any problems introduced by others will not reflect on the original |
| authors' reputations. |
| |
| Finally, any free program is threatened constantly by software |
| patents. We wish to avoid the danger that redistributors of a free |
| program will individually obtain patent licenses, in effect making the |
| program proprietary. To prevent this, we have made it clear that any |
| patent must be licensed for everyone's free use or not licensed at all. |
| |
| The precise terms and conditions for copying, distribution and |
| modification follow. |
| |
| TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION |
| 0. This License applies to any program or other work which contains a |
| notice placed by the copyright holder saying it may be distributed |
| under the terms of this General Public License. The "Program", |
| below, refers to any such program or work, and a "work based on |
| the Program" means either the Program or any derivative work under |
| copyright law: that is to say, a work containing the Program or a |
| portion of it, either verbatim or with modifications and/or |
| translated into another language. (Hereinafter, translation is |
| included without limitation in the term "modification".) Each |
| licensee is addressed as "you". |
| |
| Activities other than copying, distribution and modification are |
| not covered by this License; they are outside its scope. The act |
| of running the Program is not restricted, and the output from the |
| Program is covered only if its contents constitute a work based on |
| the Program (independent of having been made by running the |
| Program). Whether that is true depends on what the Program does. |
| |
| 1. You may copy and distribute verbatim copies of the Program's |
| source code as you receive it, in any medium, provided that you |
| conspicuously and appropriately publish on each copy an appropriate |
| copyright notice and disclaimer of warranty; keep intact all the |
| notices that refer to this License and to the absence of any |
| warranty; and give any other recipients of the Program a copy of |
| this License along with the Program. |
| |
| You may charge a fee for the physical act of transferring a copy, |
| and you may at your option offer warranty protection in exchange |
| for a fee. |
| |
| 2. You may modify your copy or copies of the Program or any portion |
| of it, thus forming a work based on the Program, and copy and |
| distribute such modifications or work under the terms of Section 1 |
| above, provided that you also meet all of these conditions: |
| |
| a. You must cause the modified files to carry prominent notices |
| stating that you changed the files and the date of any change. |
| |
| b. You must cause any work that you distribute or publish, that |
| in whole or in part contains or is derived from the Program |
| or any part thereof, to be licensed as a whole at no charge |
| to all third parties under the terms of this License. |
| |
| c. If the modified program normally reads commands interactively |
| when run, you must cause it, when started running for such |
| interactive use in the most ordinary way, to print or display |
| an announcement including an appropriate copyright notice and |
| a notice that there is no warranty (or else, saying that you |
| provide a warranty) and that users may redistribute the |
| program under these conditions, and telling the user how to |
| view a copy of this License. (Exception: if the Program |
| itself is interactive but does not normally print such an |
| announcement, your work based on the Program is not required |
| to print an announcement.) |
| |
| These requirements apply to the modified work as a whole. If |
| identifiable sections of that work are not derived from the |
| Program, and can be reasonably considered independent and separate |
| works in themselves, then this License, and its terms, do not |
| apply to those sections when you distribute them as separate |
| works. But when you distribute the same sections as part of a |
| whole which is a work based on the Program, the distribution of |
| the whole must be on the terms of this License, whose permissions |
| for other licensees extend to the entire whole, and thus to each |
| and every part regardless of who wrote it. |
| |
| Thus, it is not the intent of this section to claim rights or |
| contest your rights to work written entirely by you; rather, the |
| intent is to exercise the right to control the distribution of |
| derivative or collective works based on the Program. |
| |
| In addition, mere aggregation of another work not based on the |
| Program with the Program (or with a work based on the Program) on |
| a volume of a storage or distribution medium does not bring the |
| other work under the scope of this License. |
| |
| 3. You may copy and distribute the Program (or a work based on it, |
| under Section 2) in object code or executable form under the terms |
| of Sections 1 and 2 above provided that you also do one of the |
| following: |
| |
| a. Accompany it with the complete corresponding machine-readable |
| source code, which must be distributed under the terms of |
| Sections 1 and 2 above on a medium customarily used for |
| software interchange; or, |
| |
| b. Accompany it with a written offer, valid for at least three |
| years, to give any third party, for a charge no more than your |
| cost of physically performing source distribution, a complete |
| machine-readable copy of the corresponding source code, to be |
| distributed under the terms of Sections 1 and 2 above on a |
| medium customarily used for software interchange; or, |
| |
| c. Accompany it with the information you received as to the offer |
| to distribute corresponding source code. (This alternative is |
| allowed only for noncommercial distribution and only if you |
| received the program in object code or executable form with |
| such an offer, in accord with Subsection b above.) |
| |
| The source code for a work means the preferred form of the work for |
| making modifications to it. For an executable work, complete |
| source code means all the source code for all modules it contains, |
| plus any associated interface definition files, plus the scripts |
| used to control compilation and installation of the executable. |
| However, as a special exception, the source code distributed need |
| not include anything that is normally distributed (in either |
| source or binary form) with the major components (compiler, |
| kernel, and so on) of the operating system on which the executable |
| runs, unless that component itself accompanies the executable. |
| |
| If distribution of executable or object code is made by offering |
| access to copy from a designated place, then offering equivalent |
| access to copy the source code from the same place counts as |
| distribution of the source code, even though third parties are not |
| compelled to copy the source along with the object code. |
| |
| 4. You may not copy, modify, sublicense, or distribute the Program |
| except as expressly provided under this License. Any attempt |
| otherwise to copy, modify, sublicense or distribute the Program is |
| void, and will automatically terminate your rights under this |
| License. However, parties who have received copies, or rights, |
| from you under this License will not have their licenses |
| terminated so long as such parties remain in full compliance. |
| |
| 5. You are not required to accept this License, since you have not |
| signed it. However, nothing else grants you permission to modify |
| or distribute the Program or its derivative works. These actions |
| are prohibited by law if you do not accept this License. |
| Therefore, by modifying or distributing the Program (or any work |
| based on the Program), you indicate your acceptance of this |
| License to do so, and all its terms and conditions for copying, |
| distributing or modifying the Program or works based on it. |
| |
| 6. Each time you redistribute the Program (or any work based on the |
| Program), the recipient automatically receives a license from the |
| original licensor to copy, distribute or modify the Program |
| subject to these terms and conditions. You may not impose any |
| further restrictions on the recipients' exercise of the rights |
| granted herein. You are not responsible for enforcing compliance |
| by third parties to this License. |
| |
| 7. If, as a consequence of a court judgment or allegation of patent |
| infringement or for any other reason (not limited to patent |
| issues), conditions are imposed on you (whether by court order, |
| agreement or otherwise) that contradict the conditions of this |
| License, they do not excuse you from the conditions of this |
| License. If you cannot distribute so as to satisfy simultaneously |
| your obligations under this License and any other pertinent |
| obligations, then as a consequence you may not distribute the |
| Program at all. For example, if a patent license would not permit |
| royalty-free redistribution of the Program by all those who |
| receive copies directly or indirectly through you, then the only |
| way you could satisfy both it and this License would be to refrain |
| entirely from distribution of the Program. |
| |
| If any portion of this section is held invalid or unenforceable |
| under any particular circumstance, the balance of the section is |
| intended to apply and the section as a whole is intended to apply |
| in other circumstances. |
| |
| It is not the purpose of this section to induce you to infringe any |
| patents or other property right claims or to contest validity of |
| any such claims; this section has the sole purpose of protecting |
| the integrity of the free software distribution system, which is |
| implemented by public license practices. Many people have made |
| generous contributions to the wide range of software distributed |
| through that system in reliance on consistent application of that |
| system; it is up to the author/donor to decide if he or she is |
| willing to distribute software through any other system and a |
| licensee cannot impose that choice. |
| |
| This section is intended to make thoroughly clear what is believed |
| to be a consequence of the rest of this License. |
| |
| 8. If the distribution and/or use of the Program is restricted in |
| certain countries either by patents or by copyrighted interfaces, |
| the original copyright holder who places the Program under this |
| License may add an explicit geographical distribution limitation |
| excluding those countries, so that distribution is permitted only |
| in or among countries not thus excluded. In such case, this |
| License incorporates the limitation as if written in the body of |
| this License. |
| |
| 9. The Free Software Foundation may publish revised and/or new |
| versions of the General Public License from time to time. Such |
| new versions will be similar in spirit to the present version, but |
| may differ in detail to address new problems or concerns. |
| |
| Each version is given a distinguishing version number. If the |
| Program specifies a version number of this License which applies |
| to it and "any later version", you have the option of following |
| the terms and conditions either of that version or of any later |
| version published by the Free Software Foundation. If the Program |
| does not specify a version number of this License, you may choose |
| any version ever published by the Free Software Foundation. |
| |
| 10. If you wish to incorporate parts of the Program into other free |
| programs whose distribution conditions are different, write to the |
| author to ask for permission. For software which is copyrighted |
| by the Free Software Foundation, write to the Free Software |
| Foundation; we sometimes make exceptions for this. Our decision |
| will be guided by the two goals of preserving the free status of |
| all derivatives of our free software and of promoting the sharing |
| and reuse of software generally. |
| |
| NO WARRANTY |
| 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO |
| WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE |
| LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT |
| HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT |
| WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT |
| NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND |
| FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE |
| QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE |
| PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY |
| SERVICING, REPAIR OR CORRECTION. |
| |
| 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN |
| WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY |
| MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE |
| LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, |
| INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR |
| INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF |
| DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU |
| OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY |
| OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN |
| ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. |
| |
| END OF TERMS AND CONDITIONS |
| A.1.2 Appendix: How to Apply These Terms to Your New Programs |
| ------------------------------------------------------------- |
| |
| If you develop a new program, and you want it to be of the greatest |
| possible use to the public, the best way to achieve this is to make it |
| free software which everyone can redistribute and change under these |
| terms. |
| |
| To do so, attach the following notices to the program. It is safest |
| to attach them to the start of each source file to most effectively |
| convey the exclusion of warranty; and each file should have at least |
| the "copyright" line and a pointer to where the full notice is found. |
| |
| ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. |
| Copyright (C) YYYY NAME OF AUTHOR |
| |
| 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. |
| |
| Also add information on how to contact you by electronic and paper |
| mail. |
| |
| If the program is interactive, make it output a short notice like |
| this when it starts in an interactive mode: |
| |
| Gnomovision version 69, Copyright (C) 19YY NAME OF AUTHOR |
| Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. |
| This is free software, and you are welcome to redistribute it |
| under certain conditions; type `show c' for details. |
| |
| The hypothetical commands `show w' and `show c' should show the |
| appropriate parts of the General Public License. Of course, the |
| commands you use may be called something other than `show w' and `show |
| c'; they could even be mouse-clicks or menu items--whatever suits your |
| program. |
| |
| You should also get your employer (if you work as a programmer) or |
| your school, if any, to sign a "copyright disclaimer" for the program, |
| if necessary. Here is a sample; alter the names: |
| |
| Yoyodyne, Inc., hereby disclaims all copyright interest in the program |
| `Gnomovision' (which makes passes at compilers) written by James Hacker. |
| |
| SIGNATURE OF TY COON, 1 April 1989 |
| Ty Coon, President of Vice |
| |
| This General Public License does not permit incorporating your |
| program into proprietary programs. If your program is a subroutine |
| library, you may consider it more useful to permit linking proprietary |
| applications with the library. If this is what you want to do, use the |
| GNU Library General Public License instead of this License. |
| |
| |
| File: ccrtp.info, Node: GNU Free Documentation License, Next: GNU General Public License, Up: Licenses |
| |
| A.2 GNU Free Documentation License |
| ================================== |
| |
| Version 1.2, November 2002 |
| |
| Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. |
| 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA |
| |
| Everyone is permitted to copy and distribute verbatim copies |
| of this license document, but changing it is not allowed. |
| |
| 0. PREAMBLE |
| |
| The purpose of this License is to make a manual, textbook, or other |
| functional and useful document "free" in the sense of freedom: to |
| assure everyone the effective freedom to copy and redistribute it, |
| with or without modifying it, either commercially or |
| noncommercially. Secondarily, this License preserves for the |
| author and publisher a way to get credit for their work, while not |
| being considered responsible for modifications made by others. |
| |
| This License is a kind of "copyleft", which means that derivative |
| works of the document must themselves be free in the same sense. |
| It complements the GNU General Public License, which is a copyleft |
| license designed for free software. |
| |
| We have designed this License in order to use it for manuals for |
| free software, because free software needs free documentation: a |
| free program should come with manuals providing the same freedoms |
| that the software does. But this License is not limited to |
| software manuals; it can be used for any textual work, regardless |
| of subject matter or whether it is published as a printed book. |
| We recommend this License principally for works whose purpose is |
| instruction or reference. |
| |
| 1. APPLICABILITY AND DEFINITIONS |
| |
| This License applies to any manual or other work, in any medium, |
| that contains a notice placed by the copyright holder saying it |
| can be distributed under the terms of this License. Such a notice |
| grants a world-wide, royalty-free license, unlimited in duration, |
| to use that work under the conditions stated herein. The |
| "Document", below, refers to any such manual or work. Any member |
| of the public is a licensee, and is addressed as "you". You |
| accept the license if you copy, modify or distribute the work in a |
| way requiring permission under copyright law. |
| |
| A "Modified Version" of the Document means any work containing the |
| Document or a portion of it, either copied verbatim, or with |
| modifications and/or translated into another language. |
| |
| A "Secondary Section" is a named appendix or a front-matter section |
| of the Document that deals exclusively with the relationship of the |
| publishers or authors of the Document to the Document's overall |
| subject (or to related matters) and contains nothing that could |
| fall directly within that overall subject. (Thus, if the Document |
| is in part a textbook of mathematics, a Secondary Section may not |
| explain any mathematics.) The relationship could be a matter of |
| historical connection with the subject or with related matters, or |
| of legal, commercial, philosophical, ethical or political position |
| regarding them. |
| |
| The "Invariant Sections" are certain Secondary Sections whose |
| titles are designated, as being those of Invariant Sections, in |
| the notice that says that the Document is released under this |
| License. If a section does not fit the above definition of |
| Secondary then it is not allowed to be designated as Invariant. |
| The Document may contain zero Invariant Sections. If the Document |
| does not identify any Invariant Sections then there are none. |
| |
| The "Cover Texts" are certain short passages of text that are |
| listed, as Front-Cover Texts or Back-Cover Texts, in the notice |
| that says that the Document is released under this License. A |
| Front-Cover Text may be at most 5 words, and a Back-Cover Text may |
| be at most 25 words. |
| |
| A "Transparent" copy of the Document means a machine-readable copy, |
| represented in a format whose specification is available to the |
| general public, that is suitable for revising the document |
| straightforwardly with generic text editors or (for images |
| composed of pixels) generic paint programs or (for drawings) some |
| widely available drawing editor, and that is suitable for input to |
| text formatters or for automatic translation to a variety of |
| formats suitable for input to text formatters. A copy made in an |
| otherwise Transparent file format whose markup, or absence of |
| markup, has been arranged to thwart or discourage subsequent |
| modification by readers is not Transparent. An image format is |
| not Transparent if used for any substantial amount of text. A |
| copy that is not "Transparent" is called "Opaque". |
| |
| Examples of suitable formats for Transparent copies include plain |
| ASCII without markup, Texinfo input format, LaTeX input format, |
| SGML or XML using a publicly available DTD, and |
| standard-conforming simple HTML, PostScript or PDF designed for |
| human modification. Examples of transparent image formats include |
| PNG, XCF and JPG. Opaque formats include proprietary formats that |
| can be read and edited only by proprietary word processors, SGML or |
| XML for which the DTD and/or processing tools are not generally |
| available, and the machine-generated HTML, PostScript or PDF |
| produced by some word processors for output purposes only. |
| |
| The "Title Page" means, for a printed book, the title page itself, |
| plus such following pages as are needed to hold, legibly, the |
| material this License requires to appear in the title page. For |
| works in formats which do not have any title page as such, "Title |
| Page" means the text near the most prominent appearance of the |
| work's title, preceding the beginning of the body of the text. |
| |
| A section "Entitled XYZ" means a named subunit of the Document |
| whose title either is precisely XYZ or contains XYZ in parentheses |
| following text that translates XYZ in another language. (Here XYZ |
| stands for a specific section name mentioned below, such as |
| "Acknowledgements", "Dedications", "Endorsements", or "History".) |
| To "Preserve the Title" of such a section when you modify the |
| Document means that it remains a section "Entitled XYZ" according |
| to this definition. |
| |
| The Document may include Warranty Disclaimers next to the notice |
| which states that this License applies to the Document. These |
| Warranty Disclaimers are considered to be included by reference in |
| this License, but only as regards disclaiming warranties: any other |
| implication that these Warranty Disclaimers may have is void and |
| has no effect on the meaning of this License. |
| |
| 2. VERBATIM COPYING |
| |
| You may copy and distribute the Document in any medium, either |
| commercially or noncommercially, provided that this License, the |
| copyright notices, and the license notice saying this License |
| applies to the Document are reproduced in all copies, and that you |
| add no other conditions whatsoever to those of this License. You |
| may not use technical measures to obstruct or control the reading |
| or further copying of the copies you make or distribute. However, |
| you may accept compensation in exchange for copies. If you |
| distribute a large enough number of copies you must also follow |
| the conditions in section 3. |
| |
| You may also lend copies, under the same conditions stated above, |
| and you may publicly display copies. |
| |
| 3. COPYING IN QUANTITY |
| |
| If you publish printed copies (or copies in media that commonly |
| have printed covers) of the Document, numbering more than 100, and |
| the Document's license notice requires Cover Texts, you must |
| enclose the copies in covers that carry, clearly and legibly, all |
| these Cover Texts: Front-Cover Texts on the front cover, and |
| Back-Cover Texts on the back cover. Both covers must also clearly |
| and legibly identify you as the publisher of these copies. The |
| front cover must present the full title with all words of the |
| title equally prominent and visible. You may add other material |
| on the covers in addition. Copying with changes limited to the |
| covers, as long as they preserve the title of the Document and |
| satisfy these conditions, can be treated as verbatim copying in |
| other respects. |
| |
| If the required texts for either cover are too voluminous to fit |
| legibly, you should put the first ones listed (as many as fit |
| reasonably) on the actual cover, and continue the rest onto |
| adjacent pages. |
| |
| If you publish or distribute Opaque copies of the Document |
| numbering more than 100, you must either include a |
| machine-readable Transparent copy along with each Opaque copy, or |
| state in or with each Opaque copy a computer-network location from |
| which the general network-using public has access to download |
| using public-standard network protocols a complete Transparent |
| copy of the Document, free of added material. If you use the |
| latter option, you must take reasonably prudent steps, when you |
| begin distribution of Opaque copies in quantity, to ensure that |
| this Transparent copy will remain thus accessible at the stated |
| location until at least one year after the last time you |
| distribute an Opaque copy (directly or through your agents or |
| retailers) of that edition to the public. |
| |
| It is requested, but not required, that you contact the authors of |
| the Document well before redistributing any large number of |
| copies, to give them a chance to provide you with an updated |
| version of the Document. |
| |
| 4. MODIFICATIONS |
| |
| You may copy and distribute a Modified Version of the Document |
| under the conditions of sections 2 and 3 above, provided that you |
| release the Modified Version under precisely this License, with |
| the Modified Version filling the role of the Document, thus |
| licensing distribution and modification of the Modified Version to |
| whoever possesses a copy of it. In addition, you must do these |
| things in the Modified Version: |
| |
| A. Use in the Title Page (and on the covers, if any) a title |
| distinct from that of the Document, and from those of |
| previous versions (which should, if there were any, be listed |
| in the History section of the Document). You may use the |
| same title as a previous version if the original publisher of |
| that version gives permission. |
| |
| B. List on the Title Page, as authors, one or more persons or |
| entities responsible for authorship of the modifications in |
| the Modified Version, together with at least five of the |
| principal authors of the Document (all of its principal |
| authors, if it has fewer than five), unless they release you |
| from this requirement. |
| |
| C. State on the Title page the name of the publisher of the |
| Modified Version, as the publisher. |
| |
| D. Preserve all the copyright notices of the Document. |
| |
| E. Add an appropriate copyright notice for your modifications |
| adjacent to the other copyright notices. |
| |
| F. Include, immediately after the copyright notices, a license |
| notice giving the public permission to use the Modified |
| Version under the terms of this License, in the form shown in |
| the Addendum below. |
| |
| G. Preserve in that license notice the full lists of Invariant |
| Sections and required Cover Texts given in the Document's |
| license notice. |
| |
| H. Include an unaltered copy of this License. |
| |
| I. Preserve the section Entitled "History", Preserve its Title, |
| and add to it an item stating at least the title, year, new |
| authors, and publisher of the Modified Version as given on |
| the Title Page. If there is no section Entitled "History" in |
| the Document, create one stating the title, year, authors, |
| and publisher of the Document as given on its Title Page, |
| then add an item describing the Modified Version as stated in |
| the previous sentence. |
| |
| J. Preserve the network location, if any, given in the Document |
| for public access to a Transparent copy of the Document, and |
| likewise the network locations given in the Document for |
| previous versions it was based on. These may be placed in |
| the "History" section. You may omit a network location for a |
| work that was published at least four years before the |
| Document itself, or if the original publisher of the version |
| it refers to gives permission. |
| |
| K. For any section Entitled "Acknowledgements" or "Dedications", |
| Preserve the Title of the section, and preserve in the |
| section all the substance and tone of each of the contributor |
| acknowledgements and/or dedications given therein. |
| |
| L. Preserve all the Invariant Sections of the Document, |
| unaltered in their text and in their titles. Section numbers |
| or the equivalent are not considered part of the section |
| titles. |
| |
| M. Delete any section Entitled "Endorsements". Such a section |
| may not be included in the Modified Version. |
| |
| N. Do not retitle any existing section to be Entitled |
| "Endorsements" or to conflict in title with any Invariant |
| Section. |
| |
| O. Preserve any Warranty Disclaimers. |
| |
| If the Modified Version includes new front-matter sections or |
| appendices that qualify as Secondary Sections and contain no |
| material copied from the Document, you may at your option |
| designate some or all of these sections as invariant. To do this, |
| add their titles to the list of Invariant Sections in the Modified |
| Version's license notice. These titles must be distinct from any |
| other section titles. |
| |
| You may add a section Entitled "Endorsements", provided it contains |
| nothing but endorsements of your Modified Version by various |
| parties--for example, statements of peer review or that the text |
| has been approved by an organization as the authoritative |
| definition of a standard. |
| |
| You may add a passage of up to five words as a Front-Cover Text, |
| and a passage of up to 25 words as a Back-Cover Text, to the end |
| of the list of Cover Texts in the Modified Version. Only one |
| passage of Front-Cover Text and one of Back-Cover Text may be |
| added by (or through arrangements made by) any one entity. If the |
| Document already includes a cover text for the same cover, |
| previously added by you or by arrangement made by the same entity |
| you are acting on behalf of, you may not add another; but you may |
| replace the old one, on explicit permission from the previous |
| publisher that added the old one. |
| |
| The author(s) and publisher(s) of the Document do not by this |
| License give permission to use their names for publicity for or to |
| assert or imply endorsement of any Modified Version. |
| |
| 5. COMBINING DOCUMENTS |
| |
| You may combine the Document with other documents released under |
| this License, under the terms defined in section 4 above for |
| modified versions, provided that you include in the combination |
| all of the Invariant Sections of all of the original documents, |
| unmodified, and list them all as Invariant Sections of your |
| combined work in its license notice, and that you preserve all |
| their Warranty Disclaimers. |
| |
| The combined work need only contain one copy of this License, and |
| multiple identical Invariant Sections may be replaced with a single |
| copy. If there are multiple Invariant Sections with the same name |
| but different contents, make the title of each such section unique |
| by adding at the end of it, in parentheses, the name of the |
| original author or publisher of that section if known, or else a |
| unique number. Make the same adjustment to the section titles in |
| the list of Invariant Sections in the license notice of the |
| combined work. |
| |
| In the combination, you must combine any sections Entitled |
| "History" in the various original documents, forming one section |
| Entitled "History"; likewise combine any sections Entitled |
| "Acknowledgements", and any sections Entitled "Dedications". You |
| must delete all sections Entitled "Endorsements." |
| |
| 6. COLLECTIONS OF DOCUMENTS |
| |
| You may make a collection consisting of the Document and other |
| documents released under this License, and replace the individual |
| copies of this License in the various documents with a single copy |
| that is included in the collection, provided that you follow the |
| rules of this License for verbatim copying of each of the |
| documents in all other respects. |
| |
| You may extract a single document from such a collection, and |
| distribute it individually under this License, provided you insert |
| a copy of this License into the extracted document, and follow |
| this License in all other respects regarding verbatim copying of |
| that document. |
| |
| 7. AGGREGATION WITH INDEPENDENT WORKS |
| |
| A compilation of the Document or its derivatives with other |
| separate and independent documents or works, in or on a volume of |
| a storage or distribution medium, is called an "aggregate" if the |
| copyright resulting from the compilation is not used to limit the |
| legal rights of the compilation's users beyond what the individual |
| works permit. When the Document is included an aggregate, this |
| License does not apply to the other works in the aggregate which |
| are not themselves derivative works of the Document. |
| |
| If the Cover Text requirement of section 3 is applicable to these |
| copies of the Document, then if the Document is less than one half |
| of the entire aggregate, the Document's Cover Texts may be placed |
| on covers that bracket the Document within the aggregate, or the |
| electronic equivalent of covers if the Document is in electronic |
| form. Otherwise they must appear on printed covers that bracket |
| the whole aggregate. |
| |
| 8. TRANSLATION |
| |
| Translation is considered a kind of modification, so you may |
| distribute translations of the Document under the terms of section |
| 4. Replacing Invariant Sections with translations requires special |
| permission from their copyright holders, but you may include |
| translations of some or all Invariant Sections in addition to the |
| original versions of these Invariant Sections. You may include a |
| translation of this License, and all the license notices in the |
| Document, and any Warrany Disclaimers, provided that you also |
| include the original English version of this License and the |
| original versions of those notices and disclaimers. In case of a |
| disagreement between the translation and the original version of |
| this License or a notice or disclaimer, the original version will |
| prevail. |
| |
| If a section in the Document is Entitled "Acknowledgements", |
| "Dedications", or "History", the requirement (section 4) to |
| Preserve its Title (section 1) will typically require changing the |
| actual title. |
| |
| 9. TERMINATION |
| |
| You may not copy, modify, sublicense, or distribute the Document |
| except as expressly provided for under this License. Any other |
| attempt to copy, modify, sublicense or distribute the Document is |
| void, and will automatically terminate your rights under this |
| License. However, parties who have received copies, or rights, |
| from you under this License will not have their licenses |
| terminated so long as such parties remain in full compliance. |
| |
| 10. FUTURE REVISIONS OF THIS LICENSE |
| |
| The Free Software Foundation may publish new, revised versions of |
| the GNU Free Documentation License from time to time. Such new |
| versions will be similar in spirit to the present version, but may |
| differ in detail to address new problems or concerns. See |
| `http://www.gnu.org/copyleft/'. |
| |
| Each version of the License is given a distinguishing version |
| number. If the Document specifies that a particular numbered |
| version of this License "or any later version" applies to it, you |
| have the option of following the terms and conditions either of |
| that specified version or of any later version that has been |
| published (not as a draft) by the Free Software Foundation. If |
| the Document does not specify a version number of this License, |
| you may choose any version ever published (not as a draft) by the |
| Free Software Foundation. |
| |
| A.2.1 ADDENDUM: How to use this License for your documents |
| ---------------------------------------------------------- |
| |
| To use this License in a document you have written, include a copy of |
| the License in the document and put the following copyright and license |
| notices just after the title page: |
| |
| Copyright (C) YEAR YOUR NAME. |
| Permission is granted to copy, distribute and/or modify this document |
| under the terms of the GNU Free Documentation License, Version 1.2 |
| or any later version published by the Free Software Foundation; |
| with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. |
| A copy of the license is included in the section entitled ``GNU |
| Free Documentation License''. |
| |
| If you have Invariant Sections, Front-Cover Texts and Back-Cover |
| Texts, replace the "with...Texts." line with this: |
| |
| with the Invariant Sections being LIST THEIR TITLES, with |
| the Front-Cover Texts being LIST, and with the Back-Cover Texts |
| being LIST. |
| |
| If you have Invariant Sections without Cover Texts, or some other |
| combination of the three, merge those two alternatives to suit the |
| situation. |
| |
| If your document contains nontrivial examples of program code, we |
| recommend releasing these examples in parallel under your choice of |
| free software license, such as the GNU General Public License, to |
| permit their use in free software. |
| |
| |
| File: ccrtp.info, Node: GNU ccRTP Linking Exception, Prev: GNU General Public License, Up: Licenses |
| |
| A.3 GNU ccRTP Linking Exception |
| =============================== |
| |
| As a special exception to the GNU General Public License, permission is |
| granted for additional uses of the text contained in its release of |
| ccRTP. |
| |
| The exception is that, if you link the ccRTP library with other files |
| to produce an executable, this does not by itself cause the resulting |
| executable to be covered by the GNU General Public License. Your use |
| of that executable is in no way restricted on account of linking the |
| ccRTP library code into it. |
| |
| This exception does not however invalidate any other reasons why the |
| executable file might be covered by the GNU General Public License. |
| |
| This exception applies only to the code released under the name |
| ccRTP. If you copy code from other releases into a copy of ccRTP, as |
| the General Public License permits, the exception does not apply to the |
| code that you add in this way. To avoid misleading anyone as to the |
| status of such modified files, you must delete this exception notice |
| from them. |
| |
| If you write modifications of your own for ccRTP, it is your choice |
| whether to permit this exception to apply to your modifications. If |
| you do not wish that, delete this exception notice. |
| |
| |
| File: ccrtp.info, Node: Class and Data Type Index, Next: Method and Function Index, Prev: Licenses, Up: Top |
| |
| Class and Data Type Index |
| ************************* |
| |
| [index] |
| * Menu: |
| |
| * AppDataUnit: ccRTP Overview. (line 59) |
| * DynamicPayloadFormat <1>: Payload Types and Formats. |
| (line 52) |
| * DynamicPayloadFormat: ccRTP Overview. (line 59) |
| * DynamicPayloadType: Upgrading. (line 58) |
| * IncomingRTPPkt: RTP Packets Extensions. |
| (line 6) |
| * OutgoingRTPPkt: RTP Packets Extensions. |
| (line 6) |
| * Participant <1>: Participants. (line 6) |
| * Participant: ccRTP Overview. (line 59) |
| * PayloadFormat: Payload Types and Formats. |
| (line 25) |
| * PayloadType: Payload Types and Formats. |
| (line 6) |
| * RTPApplication: Participants. (line 6) |
| * RTPPacket: RTP Packets Extensions. |
| (line 6) |
| * RTPSession <1>: Participants. (line 6) |
| * RTPSession <2>: Initiating Sessions. (line 6) |
| * RTPSession: ccRTP Overview. (line 47) |
| * RTPSource: Upgrading. (line 31) |
| * StaticPayloadFormat <1>: Payload Types and Formats. |
| (line 35) |
| * StaticPayloadFormat: ccRTP Overview. (line 59) |
| * StaticPayloadType <1>: Upgrading. (line 58) |
| * StaticPayloadType <2>: Payload Types and Formats. |
| (line 6) |
| * StaticPayloadType: ccRTP Overview. (line 59) |
| * SyncSource <1>: Upgrading. (line 31) |
| * SyncSource <2>: Participants. (line 6) |
| * SyncSource: ccRTP Overview. (line 59) |
| |
| |
| File: ccrtp.info, Node: Method and Function Index, Next: Concept Index, Prev: Class and Data Type Index, Up: Top |
| |
| Method and Function Index |
| ************************* |
| |
| [index] |
| * Menu: |
| |
| * ccxx_sleep: Upgrading. (line 22) |
| * defaultApplication <1>: Upgrading. (line 40) |
| * defaultApplication <2>: Participants. (line 73) |
| * defaultApplication: Initiating Sessions. (line 30) |
| * DynamicPayloadFormat::DynamicPayloadFormat: Payload Types and Formats. |
| (line 52) |
| * exit: Upgrading. (line 16) |
| * getMRSenderInfo: ccRTP Overview. (line 47) |
| * IncomingDataQueue::checkSSRCInIncomingRTPPkt: A.1. (line 6) |
| * IncomingDataQueue::getData <1>: Upgrading. (line 43) |
| * IncomingDataQueue::getData: Receiving Data. (line 6) |
| * IncomingDataQueue::isWaiting: Receiving Data. (line 17) |
| * IncomingDataQueue::onExpireRecv: RTP Packets Expiration. |
| (line 6) |
| * IncomingDataQueue::onNewSyncSource: Synchronization Source States. |
| (line 6) |
| * IncomingDataQueue::onRTPPacketRecv: RTP Packets Arrival. (line 6) |
| * IncomingDataQueue::recordReception: A.8. (line 6) |
| * IncomingDataQueue::takeInDataPacket: A.7. (line 35) |
| * MembershipBookkeeping::SyncSourceLink::computeStats: A.3. (line 6) |
| * onGotSR: ccRTP Overview. (line 47) |
| * OutgoingDataQueue::addDestination: Initiating Sessions. (line 25) |
| * OutgoingDataQueue::dispatchDataPacket: A.7. (line 38) |
| * OutgoingDataQueue::onExpireSend: RTP Packets Expiration. |
| (line 6) |
| * OutgoingDataQueue::putData <1>: Upgrading. (line 52) |
| * OutgoingDataQueue::putData: Sending Data. (line 6) |
| * OutgoingDataQueue::setMark: Sending Data. (line 11) |
| * OutgoingDataQueue::setPadding: Initiating Sessions. (line 38) |
| * OutgoingDataQueue::setSchedulingTimeout: Upgrading. (line 47) |
| * OutgoingDataQueueBase::getDefaultMaxSendSegmentSize: Sending Data. |
| (line 16) |
| * OutgoingDataQueueBase::setMaxSendSegmentSize: Sending Data. (line 16) |
| * QueueRTCPMaanger::setControlBandwidth: Initiating Sessions. (line 45) |
| * QueueRTCPManager::checkSSRCInRTCPPkt: A.1. (line 6) |
| * QueueRTCPManager::dispatchBYE: A.7. (line 26) |
| * QueueRTCPManager::dispatchControlPacket: A.7. (line 23) |
| * QueueRTCPManager::end2EndDelayed: RTP Packets Expiration. |
| (line 8) |
| * QueueRTCPManager::onGotAPP: RTCP Packets Arrival. (line 15) |
| * QueueRTCPManager::onGotGoodbye: Upgrading. (line 88) |
| * QueueRTCPManager::onGotRR: RTCP Packets Arrival. (line 11) |
| * QueueRTCPManager::onGotRRSRExtension: RTCP Packets Arrival. (line 17) |
| * QueueRTCPManager::onGotSDES: A.5. (line 6) |
| * QueueRTCPManager::onGotSDESChunk: RTCP Packets Arrival. (line 13) |
| * QueueRTCPManager::onGotSR: RTCP Packets Arrival. (line 9) |
| * QueueRTCPManager::onNewSyncSource: Upgrading. (line 85) |
| * QueueRTCPManager::onSSRCCollision: SSRC Collisions. (line 6) |
| * QueueRTCPManager::packSDES: A.4. (line 6) |
| * RTCPCompoundHandler::checkCompountRTCPHeader: A.2. (line 6) |
| * RTPApplication: Participants. (line 73) |
| * RTPApplication::getSDESItem: Upgrading. (line 40) |
| * RTPApplication::ParticipantsIterator: Participants. (line 86) |
| * RTPApplication::setPRIVPrefix: Initiating Sessions. (line 30) |
| * RTPPApplication::setSDESItem: Initiating Sessions. (line 30) |
| * RTPQueue::getCNAME: Upgrading. (line 40) |
| * RTPQueue::getCurrentRate: Upgrading. (line 79) |
| * RTPQueue::getLocalInfo: Upgrading. (line 37) |
| * RTPQueue::getLocalSSRC: Upgrading. (line 37) |
| * RTPQueue::getPacket: Upgrading. (line 43) |
| * RTPQueue::gotGoodbye: Upgrading. (line 88) |
| * RTPQueue::gotHello: Upgrading. (line 85) |
| * RTPQueue::putPacket: Upgrading. (line 52) |
| * RTPQueue::setTimeout: Upgrading. (line 47) |
| * RTPQueueBase::getCurrentRTPClockRate: Upgrading. (line 79) |
| * RTPQueueBase::setPayloadFormat <1>: Upgrading. (line 52) |
| * RTPQueueBase::setPayloadFormat: Initiating Sessions. (line 27) |
| * RTPSession::enableStack: Initiating Sessions. (line 15) |
| * RTPSession::startRunning <1>: Upgrading. (line 82) |
| * RTPSession::startRunning: Initiating Sessions. (line 15) |
| * RTPSession::SyncSourcesIterator: Participants. (line 46) |
| * RTPSocket::Start: Upgrading. (line 82) |
| * StaticPayloadFormat::StaticPayloadFormat: Payload Types and Formats. |
| (line 41) |
| * SyncSource::getParticipant(): Participants. (line 48) |
| * Thread::sleep: Upgrading. (line 22) |
| * Thread::terminate: Upgrading. (line 19) |
| |
| |
| File: ccrtp.info, Node: Concept Index, Prev: Method and Function Index, Up: Top |
| |
| Concept Index |
| ************* |
| |
| [index] |
| * Menu: |
| |
| * /dev/urandom <1>: A.6. (line 6) |
| * /dev/urandom: ccRTP Overview. (line 43) |
| * A.1: A.1. (line 6) |
| * A.2: A.2. (line 6) |
| * A.3: A.3. (line 6) |
| * A.4: A.4. (line 6) |
| * A.5: A.5. (line 6) |
| * A.6: A.6. (line 6) |
| * A.7: A.7. (line 6) |
| * A.8: A.8. (line 6) |
| * Algoritms in the Standard: Algorithms in the Standard. |
| (line 6) |
| * APP: RTCP Packets Arrival. (line 15) |
| * Audio/Video Working Group: Introduction. (line 6) |
| * AVPF: Standards Tracking. (line 26) |
| * C++: Introduction. (line 6) |
| * ccRTP Internals: ccRTP Internals. (line 6) |
| * ccRTP Overview: ccRTP Overview. (line 6) |
| * class framework: Introduction. (line 6) |
| * clock rate: Payload Types and Formats. |
| (line 25) |
| * Closing Sessions: Closing Sessions. (line 6) |
| * CNAME <1>: Participants. (line 23) |
| * CNAME: Initiating Sessions. (line 30) |
| * collision: SSRC Collisions. (line 6) |
| * Collisions and Loops: Collisions and Loops. (line 6) |
| * Common C++: Introduction. (line 6) |
| * const iterator: Participants. (line 46) |
| * default bandwidth: Initiating Sessions. (line 45) |
| * default value <1>: Participants. (line 73) |
| * default value <2>: Sending Data. (line 11) |
| * default value: Initiating Sessions. (line 27) |
| * demo program: ccRTP Overview. (line 47) |
| * destination: Upgrading. (line 68) |
| * distribution: Distribution. (line 6) |
| * duplicate packets: Receiving Data. (line 14) |
| * FDL, GNU Free Documentation License: GNU Free Documentation License. |
| (line 6) |
| * free software: Distribution. (line 6) |
| * Future, Future Work: Future Work. (line 6) |
| * GNU ccRTP Linking Exception: GNU ccRTP Linking Exception. |
| (line 6) |
| * GNU FDL: Distribution. (line 6) |
| * GNU GPL: Distribution. (line 6) |
| * H.245: Payload Types and Formats. |
| (line 25) |
| * H.323: Introduction. (line 38) |
| * Handling Events: Handling Events. (line 6) |
| * header check <1>: A.2. (line 6) |
| * header check: ccRTP Overview. (line 34) |
| * header validity <1>: A.2. (line 6) |
| * header validity: ccRTP Overview. (line 34) |
| * IANA: Payload Types and Formats. |
| (line 20) |
| * IETF <1>: Standards Tracking. (line 6) |
| * IETF: Introduction. (line 6) |
| * IETF standards: Standards Tracking. (line 6) |
| * incoming queue: Using ccRTP. (line 17) |
| * Initiating Sessions: Initiating Sessions. (line 6) |
| * interarrival jitter: A.8. (line 6) |
| * Internals Overview: Internals Overview. (line 6) |
| * Internet Ingeneering Task Force: Introduction. (line 6) |
| * Introduction: Introduction. (line 6) |
| * iterator: Participants. (line 46) |
| * jitter: A.8. (line 6) |
| * join: Initiating Sessions. (line 6) |
| * linking exception: Distribution. (line 6) |
| * loop detection: ccRTP Overview. (line 39) |
| * marker bit: Sending Data. (line 11) |
| * MD5 <1>: A.6. (line 6) |
| * MD5 <2>: ccRTP Overview. (line 43) |
| * MD5: Introduction. (line 19) |
| * MIME: Payload Types and Formats. |
| (line 25) |
| * multicast: Initiating Sessions. (line 6) |
| * outgoing queue: Using ccRTP. (line 24) |
| * packet queue <1>: Using ccRTP. (line 6) |
| * packet queue: ccRTP Overview. (line 10) |
| * padding: Initiating Sessions. (line 38) |
| * participant: Participants. (line 48) |
| * Participant: Participants. (line 6) |
| * Payload Formats: Payload Types and Formats. |
| (line 6) |
| * payload type: Upgrading. (line 52) |
| * Payload Types: Payload Types and Formats. |
| (line 6) |
| * PCMU: Initiating Sessions. (line 27) |
| * philosophy: Distribution. (line 6) |
| * PRIV: Initiating Sessions. (line 30) |
| * profile: Standards Tracking. (line 24) |
| * Random numbers <1>: A.6. (line 6) |
| * Random numbers: ccRTP Overview. (line 43) |
| * Receiving Data: Receiving Data. (line 6) |
| * reception queue: Using ccRTP. (line 17) |
| * reconsideration: ccRTP Overview. (line 41) |
| * redundancy: Upgrading. (line 68) |
| * Related work: Related Work. (line 6) |
| * reordering: Receiving Data. (line 14) |
| * reverse reconsideration: ccRTP Overview. (line 41) |
| * RR: RTCP Packets Arrival. (line 11) |
| * RTCP APP: RTCP Packets Arrival. (line 15) |
| * RTCP bandwidth: Initiating Sessions. (line 45) |
| * RTCP compound packets: Initiating Sessions. (line 30) |
| * RTCP header: A.2. (line 6) |
| * RTCP Packet Arrival: RTCP Packets Arrival. (line 6) |
| * RTCP packets: Initiating Sessions. (line 30) |
| * RTCP Packets Extensions: RTCP Packets Extensions. |
| (line 6) |
| * RTCP RR: RTCP Packets Arrival. (line 11) |
| * RTCP SDES: RTCP Packets Arrival. (line 13) |
| * RTCP SR <1>: RTCP Packets Arrival. (line 9) |
| * RTCP SR: ccRTP Overview. (line 47) |
| * RTCP-based feedback: Standards Tracking. (line 26) |
| * RTP clock rate: Payload Types and Formats. |
| (line 25) |
| * RTP Packet Arrival: RTP Packets Arrival. (line 6) |
| * RTP Packets Expiration: RTP Packets Expiration. |
| (line 6) |
| * RTP Packets Extensions: RTP Packets Extensions. |
| (line 6) |
| * RTP parameters: Payload Types and Formats. |
| (line 20) |
| * RTP Sessions: RTP Sessions. (line 6) |
| * RTP timestamp offset: Sending Data. (line 6) |
| * rtphello: ccRTP Overview. (line 47) |
| * rtplisten: ccRTP Overview. (line 47) |
| * RTSP: Introduction. (line 38) |
| * SAVPF: Standards Tracking. (line 30) |
| * SDES: RTCP Packets Arrival. (line 13) |
| * SDES item: Initiating Sessions. (line 30) |
| * SDP: Payload Types and Formats. |
| (line 25) |
| * Secure RTP: Standards Tracking. (line 24) |
| * segment size: Sending Data. (line 16) |
| * Sending Data: Sending Data. (line 6) |
| * Session control: Payload Types and Formats. |
| (line 66) |
| * Session Description Protocol: Payload Types and Formats. |
| (line 25) |
| * signalization: Introduction. (line 38) |
| * Simple Receiver: Simple Receiver. (line 6) |
| * Simple Transmitter: Simple Transmitter. (line 6) |
| * SIP: Introduction. (line 38) |
| * sockets: Introduction. (line 19) |
| * Source of Synchronization: Participants. (line 6) |
| * Specialized Payload Formats: Specialized Payload Formats. |
| (line 6) |
| * SR <1>: RTCP Packets Arrival. (line 9) |
| * SR: ccRTP Overview. (line 47) |
| * SRE Extension: RTCP Packets Arrival. (line 17) |
| * SRTP: Standards Tracking. (line 24) |
| * SSRC collision: SSRC Collisions. (line 6) |
| * SSRC Collision: SSRC Collisions. (line 6) |
| * SSRC collision: ccRTP Overview. (line 39) |
| * Standards tracking: Standards Tracking. (line 6) |
| * static payload type: Initiating Sessions. (line 27) |
| * synchronization: Introduction. (line 19) |
| * Synchronization Source States: Synchronization Source States. |
| (line 6) |
| * system services: Introduction. (line 19) |
| * thread: Using ccRTP. (line 6) |
| * threading: Introduction. (line 19) |
| * timer reconsideration: ccRTP Overview. (line 41) |
| * timestamp clock rate: Payload Types and Formats. |
| (line 25) |
| * timestamp offset: Sending Data. (line 6) |
| * transmission queue: Using ccRTP. (line 24) |
| * Types of Sessions: Types of Sessions. (line 6) |
| * Upgrading: Upgrading. (line 6) |
| * Using ccRTP: Using ccRTP. (line 6) |
| |
| |
| |
| Tag Table: |
| Node: Top840 |
| Node: Introduction2058 |
| Ref: Introduction-Footnote-15455 |
| Node: Distribution5532 |
| Node: ccRTP Overview6807 |
| Node: Simple Transmitter10143 |
| Node: Simple Receiver10852 |
| Node: Using ccRTP11842 |
| Node: RTP Sessions14445 |
| Node: Initiating Sessions15116 |
| Node: Sending Data17436 |
| Node: Receiving Data18816 |
| Node: Closing Sessions19799 |
| Node: Types of Sessions20591 |
| Node: Payload Types and Formats20918 |
| Ref: Payload Types and Formats-Footnote-124146 |
| Node: Participants24247 |
| Node: RTP Packets Extensions29070 |
| Node: RTCP Packets Extensions29453 |
| Node: Handling Events29768 |
| Node: RTP Packets Arrival30418 |
| Node: RTP Packets Expiration30860 |
| Node: RTCP Packets Arrival31072 |
| Node: Synchronization Source States31671 |
| Node: SSRC Collisions31897 |
| Node: Specialized Payload Formats32097 |
| Node: Standards Tracking32366 |
| Node: Upgrading33300 |
| Ref: Upgrading-Footnote-136536 |
| Ref: Upgrading-Footnote-236640 |
| Ref: Upgrading-Footnote-336728 |
| Node: ccRTP Internals36743 |
| Node: Internals Overview37092 |
| Node: Collisions and Loops37442 |
| Node: Algorithms in the Standard38628 |
| Node: A.139487 |
| Node: A.240369 |
| Node: A.340559 |
| Node: A.440735 |
| Node: A.540925 |
| Node: A.641202 |
| Node: A.741598 |
| Node: A.842917 |
| Node: Related Work43119 |
| Node: Future Work43464 |
| Node: Licenses43592 |
| Node: GNU General Public License43960 |
| Node: GNU Free Documentation License63225 |
| Node: GNU ccRTP Linking Exception85652 |
| Node: Class and Data Type Index86975 |
| Node: Method and Function Index89452 |
| Node: Concept Index95237 |
| |
| End Tag Table |
| |
| |
| Local Variables: |
| coding: iso-8859-1 |
| End: |