Emeric Vigier | 2f62582 | 2012-08-06 11:09:52 -0400 | [diff] [blame] | 1 | This is ccrtp.info, produced by makeinfo version 4.13 from ccrtp.texi. |
| 2 | |
| 3 | INFO-DIR-SECTION Development |
| 4 | START-INFO-DIR-ENTRY |
| 5 | * GNU ccRTP: (ccrtp). GNU ccRTP Real-Time Transport Protocol Framework. |
| 6 | END-INFO-DIR-ENTRY |
| 7 | |
| 8 | GNU ccRTP is a C++ class framework for the development of Real Time |
| 9 | Transport Protocol (RTP) based applications. It is based on GNU Common |
| 10 | C++. |
| 11 | |
| 12 | Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006 Federico Montesino |
| 13 | Pouzols <fedemp@altern.org>. Permission is granted to copy, distribute |
| 14 | and/or modify this document under the terms of the GNU Free |
| 15 | Documentation License, Version 1.2 or any later version published by |
| 16 | the Free Software Foundation; with no Invariant Sections, no |
| 17 | Front-Cover Texts, and no Back-Cover Texts. A copy of the license is |
| 18 | included in the section entitled "GNU Free Documentation License". |
| 19 | |
| 20 | |
| 21 | File: ccrtp.info, Node: Top, Next: Introduction, Up: (dir) |
| 22 | |
| 23 | GNU ccRTP Manual |
| 24 | **************** |
| 25 | |
| 26 | This manual describes GNU ccRTP, a C++ class framework for the |
| 27 | development of Real Time Transport Protocol (RTP) based applications. |
| 28 | |
| 29 | This is the edition 1.3 of this manual and documents GNU ccRTP |
| 30 | version 1.3. |
| 31 | |
| 32 | * Menu: |
| 33 | |
| 34 | * Introduction:: What RTP and ccRTP are. |
| 35 | * Distribution:: How to get GNU ccRTP. |
| 36 | * ccRTP Overview:: The library at a glance. |
| 37 | * Using ccRTP:: Programming with GNU ccRTP overview. |
| 38 | * Specialized Payload Formats:: Supported payload specific extensions. |
| 39 | * Standards Tracking:: IETF Standards conformance. |
| 40 | * Upgrading:: Upgrading applications based on old releases. |
| 41 | * ccRTP Internals:: How GNU ccRTP is done. |
| 42 | * Related Work:: Other RTP related libraries and tools. |
| 43 | * Future Work:: Future of RTP and ccRTP. |
| 44 | * Licenses:: Library and documentation licenses. |
| 45 | * Class and Data Type Index:: Index of classes and data types in ccRTP. |
| 46 | * Method and Function Index:: Index of methods and functions in ccRTP. |
| 47 | * Concept Index:: Index of concepts. |
| 48 | |
| 49 | |
| 50 | File: ccrtp.info, Node: Introduction, Next: Distribution, Prev: Top, Up: Top |
| 51 | |
| 52 | 1 Introduction |
| 53 | ************** |
| 54 | |
| 55 | ccRTP is a C++ framework for developing applications based on the Real |
| 56 | Time Transport Protocol (RTP henceforth). RTP provides end-to-end |
| 57 | delivery services for data with real-time characteristics and is being |
| 58 | developed by the Audio/Video Working Group of the Internet Engineering |
| 59 | Task Force (IETF). |
| 60 | |
| 61 | ccRTP aims to be an efficient and flexible framework valid for almost |
| 62 | any kind of application that uses RTP, ranging from high loaded servers |
| 63 | and gateways to personal phone applications. Default constructs and |
| 64 | values are provided however for the most common choices in the use of |
| 65 | RTP. ccRTP conforms to the latest RTP specifications (*note Standards |
| 66 | Tracking::). |
| 67 | |
| 68 | ccRTP is based on the GNU Common C++ framework, though most of the |
| 69 | library does not require it. Common C++ provides basic system services |
| 70 | such as threading, synchronization and sockets(1), which makes it |
| 71 | possible to provide a complete solution for the use of RTP. However, |
| 72 | although ccRTP provides facilities and abstractions useful for the RTP |
| 73 | specific components of applications that use RTP, such applications |
| 74 | generally require similar system services for other tasks. Besides |
| 75 | supporting ccRTP, Common C++ provides a portable and efficient |
| 76 | framework for these kind of services. |
| 77 | |
| 78 | RTP has been defined as an application level protocol framework |
| 79 | rather than a typical Internet transport protocol such as TCP and UDP. |
| 80 | Thus, RTP is hardly ever implemented as a layer separated from the |
| 81 | application. Consequently, RTP applications often must customize the |
| 82 | adaptable RTP packet layout and processing rules, timing constraints, |
| 83 | session membership rules as well as other RTP and RTCP mechanisms. |
| 84 | ccRTP aims to provide a framework for the RTP framework, rather than |
| 85 | being just an RTP packet manipulation library. |
| 86 | |
| 87 | As a clarification of the scope of the ccRTP library and the RTP |
| 88 | protocol, we note that ccRTP exclusively deals with the transport of |
| 89 | data over the RTP protocol. Once parameters such as destination IP |
| 90 | address and transport port, payload type identifier and timestamp |
| 91 | frequency are known, ccRTP can be used to open an RTP session and send |
| 92 | and receive RTP and RTCP packets. A multimedia application will have |
| 93 | those parameters previously set or, more usually, they can be fetched |
| 94 | for example from SDP multimedia session descriptions, which can be |
| 95 | interchanged (and negotiated) between servers and clients by means of |
| 96 | some signaling protocol: SIP, RTSP, or even H.323. Signaling functions |
| 97 | are not handled by ccRTP. |
| 98 | |
| 99 | This document is an introductory programmer's manual, for a more |
| 100 | exhaustive reference see the reference manual distributed with GNU |
| 101 | ccRTP. In *note ccRTP Overview::, the most important concepts and some |
| 102 | basic examples are introduced. A deeper and step by step description as |
| 103 | well as short examples are provided in *note Using ccRTP::. |
| 104 | |
| 105 | Finally, if after reading this document and/or using ccRTP you think |
| 106 | it fails to provide some functionality that seems to be needed for some |
| 107 | application, we encourage you to contact the developers of ccRTP and |
| 108 | ask or propose them improvements and/or additions. You are also |
| 109 | encouraged to provide these improvements and to join the development |
| 110 | team. Bug reports, suggestions and criticisms are gladly accepted. |
| 111 | |
| 112 | ---------- Footnotes ---------- |
| 113 | |
| 114 | (1) As well as other more specialized services, such as MD5 |
| 115 | computation. |
| 116 | |
| 117 | |
| 118 | File: ccrtp.info, Node: Distribution, Next: ccRTP Overview, Prev: Introduction, Up: Top |
| 119 | |
| 120 | 2 Distribution |
| 121 | ************** |
| 122 | |
| 123 | GNU ccRTP is free software (see |
| 124 | `http://www.gnu.org/philosophy/philosophy.html'. It is licensed under |
| 125 | the terms of the GNU General Public License, *Note GNU General Public |
| 126 | License::, plus a linking exception, *Note GNU ccRTP Linking |
| 127 | Exception::. |
| 128 | |
| 129 | The linking exception is the same that is used for gcc libstdc++. |
| 130 | This was done in the case of libstdc++ because the language of the LGPL |
| 131 | is neither clear nor correct if one uses C++ features such as templates |
| 132 | and method implimentation directly in headers, as the division between |
| 133 | the C++ library and another's application is no longer purely a linking |
| 134 | one. From the practical standpoint, the exact effect is the same as |
| 135 | the LGPL, but with language that matches these C++ features. This is |
| 136 | all explained at |
| 137 | `http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html'. |
| 138 | |
| 139 | This manual is licensed under the terms of the GNU Free |
| 140 | Documentation License, *Note GNU Free Documentation License::. |
| 141 | |
| 142 | There are several ways to get GNU ccRTP, refer to |
| 143 | `http://www.gnu.org' and `http://www.gnu.org/software/ccrtp/'. The |
| 144 | development of ccRTP is hosted at Savannah |
| 145 | `http://sv.gnu.org/projects/ccrtp/'. |
| 146 | |
| 147 | |
| 148 | File: ccrtp.info, Node: ccRTP Overview, Next: Using ccRTP, Prev: Distribution, Up: Top |
| 149 | |
| 150 | 3 ccRTP Overview |
| 151 | **************** |
| 152 | |
| 153 | At its highest level, ccRTP provides classes for the real-time |
| 154 | transport of data through RTP sessions, as well as the control |
| 155 | functions of RTCP. |
| 156 | |
| 157 | The main concept in the ccRTP implementation of RTP sessions is the |
| 158 | use of packet queues to handle transmission and reception of RTP data |
| 159 | packets/application data units. In ccRTP, a data block is transmitted |
| 160 | by putting it into the transmission (outgoing packets) queue, and |
| 161 | received by getting it from the reception (incoming packets) queue. |
| 162 | |
| 163 | Starting with 1.0 releases, ccRTP fully supports RTP and RTCP. Here |
| 164 | is a brief list of some features of ccRTP: |
| 165 | |
| 166 | * Highly extensible to specialized stacks. |
| 167 | |
| 168 | * Supports unicast, multi-unicast and multicast. Handles multiple |
| 169 | sources (including synchronization sources and contributing |
| 170 | sources) and destinations. Also supports symmetric RTP. |
| 171 | |
| 172 | * Automatic RTCP functions handling, such as association of |
| 173 | synchronization sources from the same participant or NTP-RTP |
| 174 | timestamp mapping. |
| 175 | |
| 176 | * Genericity as for underlying network and transport protocols |
| 177 | through templates. |
| 178 | |
| 179 | * It is threadsafe and supports almost any threading model. |
| 180 | |
| 181 | * Generic and extensible RTP and RTCP header validity checks. |
| 182 | |
| 183 | * Handles source states and information as well as statistics |
| 184 | recording. |
| 185 | |
| 186 | * Automatically handles SSRC collisions and performs loop detection. |
| 187 | |
| 188 | * Implements timer reconsideration and reverse reconsideration. |
| 189 | |
| 190 | * Provides good random numbers, based on `/dev/urandom' or, |
| 191 | alternatively, on MD5. |
| 192 | |
| 193 | |
| 194 | There are several levels of interface (public interface, public or |
| 195 | protected inheritance, etc) in ccRTP. For instance, the `rtphello' demo |
| 196 | program distributed with ccRTP just uses the public interface of the |
| 197 | `RTPSession' class and does not redefine the virtual method `onGotSR', |
| 198 | thus what this program knows about SR reports is the information |
| 199 | conveyed in the last sender report from any source, which can be |
| 200 | retrieved via the `getMRSenderInfo' method of the `SyncSource' class. |
| 201 | On the contrary, the `rtplisten' demo program redefines `onGotSR' by |
| 202 | means of inheritance and could do specialized processing of these RTCP |
| 203 | packets. Generally, both data and control packets are not directly |
| 204 | accessible through the most external interface. |
| 205 | |
| 206 | All these functions are performed through a few essential classes and |
| 207 | types. The most basic ones are the enumerated type `StaticPayloadType', |
| 208 | and the classes `StaticPayloadFormat' and `DynamicPayloadFormat'. The |
| 209 | most important ones are the classes `RTPSession', `SyncSource', |
| 210 | `Participant' and `AppDataUnit', that represent RTP sessions, |
| 211 | synchronization sources, participants in an RTP application, and |
| 212 | application data units conveyed in RTP data packets, respectively. |
| 213 | |
| 214 | In the next sections, two basic examples are presented. These |
| 215 | examples are intended to provide a concrete idea of what the code of a |
| 216 | ccRTP based application looks like, they are not complete or compilable |
| 217 | programs. You can find some real examples under the demo directory in |
| 218 | the source distribution of ccRTP. |
| 219 | |
| 220 | * Menu: |
| 221 | |
| 222 | * Simple Transmitter:: Skeleton of a simple transmitter. |
| 223 | * Simple Receiver:: Skeleton of a simple receiver. |
| 224 | |
| 225 | |
| 226 | File: ccrtp.info, Node: Simple Transmitter, Next: Simple Receiver, Up: ccRTP Overview |
| 227 | |
| 228 | 3.1 Simple Transmitter |
| 229 | ====================== |
| 230 | |
| 231 | The following snippet illustrates the required steps to send an |
| 232 | application data unit over RTP. |
| 233 | |
| 234 | RTPSession s(InetHostAddress("127.0.0.1"),8000); // bind reception socket |
| 235 | |
| 236 | // Initialization |
| 237 | cout << "Local SSRC identifier: " << s.getLocalSSRC() << endl; |
| 238 | s.addDestination("www.example.com",9000); // set one destination for packets |
| 239 | s.setPayloadFormat(staticPayloadFormat(sptPCMU)); |
| 240 | s.startRunning(); // start running the packet queue scheduler |
| 241 | |
| 242 | // Send data |
| 243 | s.putData(0,buffer,bufferLen); // buffer holds bufferLen payload octets |
| 244 | |
| 245 | |
| 246 | File: ccrtp.info, Node: Simple Receiver, Prev: Simple Transmitter, Up: ccRTP Overview |
| 247 | |
| 248 | 3.2 Simple Receiver |
| 249 | =================== |
| 250 | |
| 251 | The required actions to receive an application data unit over RTP are |
| 252 | listed in the following code snippet. |
| 253 | |
| 254 | RTPSession s(InetHostAddress("127.0.0.1"),9000); // bind reception socket. |
| 255 | |
| 256 | // Initialization. |
| 257 | cout << "Local SSRC identifier: " << s.getLocalSSRC() << endl; |
| 258 | s.setPayloadFormat(staticPayloadFormat(sptPCMU)); |
| 259 | s.startRunning(); // start running the packet queue scheduler. |
| 260 | |
| 261 | // Receive data. |
| 262 | const AppDataUnit* adu; |
| 263 | adu = s.getData(0); // get data with initial -0- timestamp. |
| 264 | if ( adu != NULL ) |
| 265 | // do something with adu. |
| 266 | // adu->getType() provides the payload type. |
| 267 | // adu->getData() provides a const uint8 pointer to a data buffer. |
| 268 | // adu->getSize() provides the number of octets in the buffer. |
| 269 | // see other methods in the class AppDataUnit, such as getSource(). |
| 270 | |
| 271 | |
| 272 | File: ccrtp.info, Node: Using ccRTP, Next: Specialized Payload Formats, Prev: ccRTP Overview, Up: Top |
| 273 | |
| 274 | 4 Using ccRTP |
| 275 | ************* |
| 276 | |
| 277 | When using ccRTP, both sending and receiving of data transported over |
| 278 | RTP sessions is done through reception and transmission queues handled |
| 279 | by the RTP stack. In the most common case, a separate execution thread |
| 280 | for each RTP session handles the queues. This case is the threading |
| 281 | model that we will generally assume throughout this document. Note |
| 282 | however that ccRTP supports other threading models, particularly ccRTP |
| 283 | supports the use of a single execution thread to serve a set of RTP |
| 284 | sessions. It is also possible to not associate any separate thread with |
| 285 | any RTP session, manually calling the main data and control service |
| 286 | methods from whatever other thread. |
| 287 | |
| 288 | The basic idea for packet reception with ccRTP is that the |
| 289 | application does not directly read packets from sockets but gets them |
| 290 | from a reception queue. The stack is responsible for inserting received |
| 291 | packets in the reception queue and handling this queue. In general, a |
| 292 | packet reception and insertion in the reception queue does not occur at |
| 293 | the same time the application gets it from the queue. |
| 294 | |
| 295 | Conversely, the basic idea for packet transmission with ccRTP is that |
| 296 | packets are not directly written to sockets but inserted in a |
| 297 | transmission queue handled by the stack. In general, packet insertion |
| 298 | and transmission occur at different times, though it is not necessary. |
| 299 | |
| 300 | In order to use ccRTP, you must include the main header (`#include |
| 301 | <ccrtp/rtp.h>'. Two additional headers are provided by ccRTP: |
| 302 | |
| 303 | ``#include <ccrtp/rtppool.h'' |
| 304 | Classes for pools of RTP service threads. |
| 305 | |
| 306 | ``#include <ccrtp/rtpext.h>'' |
| 307 | Classes for RTP extensions which are not mature yet. |
| 308 | |
| 309 | |
| 310 | You must also link in the library, currently `ccrtp1'. |
| 311 | |
| 312 | As presented in the last examples, before starting to send or receive |
| 313 | data, RTP sessions must be created, the payload format to use must be |
| 314 | set and the stack must be signaled to start running. The following |
| 315 | sections describe the use of ccRTP during the different phases of RTP |
| 316 | sessions and RTP applications in general. |
| 317 | |
| 318 | * Menu: |
| 319 | |
| 320 | * RTP Sessions:: Using ccRTP to establish RTP sessions. |
| 321 | * Payload Types and Formats:: Payload types and formats. |
| 322 | * Participants:: Participants and sources of synchronization. |
| 323 | * RTP Packets Extensions:: Extensions to RTP data packets handling. |
| 324 | * RTCP Packets Extensions:: Extensions to RTCP packets handling. |
| 325 | * Handling Events:: Table of ccRTP plug-ins to react to events. |
| 326 | |
| 327 | |
| 328 | File: ccrtp.info, Node: RTP Sessions, Next: Payload Types and Formats, Up: Using ccRTP |
| 329 | |
| 330 | 4.1 RTP Sessions |
| 331 | ================ |
| 332 | |
| 333 | This section discusses the use of `RTPSession' objects. Some other |
| 334 | classes and concepts are also used, these are just briefly presented |
| 335 | here; deeper explanations are provided in next sections. |
| 336 | |
| 337 | * Menu: |
| 338 | |
| 339 | * Initiating Sessions:: RTP sessions initialization with ccRTP. |
| 340 | * Sending Data:: Sending RTP data packets. |
| 341 | * Receiving Data:: Receiving RTP data packets. |
| 342 | * Closing Sessions:: Extensions to RTP data packets handling. |
| 343 | * Types of Sessions:: Choosing a threading and socket model. |
| 344 | |
| 345 | |
| 346 | File: ccrtp.info, Node: Initiating Sessions, Next: Sending Data, Up: RTP Sessions |
| 347 | |
| 348 | 4.1.1 Initiating Sessions |
| 349 | ------------------------- |
| 350 | |
| 351 | Initiating RTP sessions with ccRTP involves the construction of an |
| 352 | object of the class `RTPSession' and calling some optional |
| 353 | initialization methods. `RTPSession' constructors take two mandatory |
| 354 | arguments: local network address and local transport port (where |
| 355 | incoming packets are expected). There are two constructors, one of them |
| 356 | takes a host address as first parameter, while the other takes a |
| 357 | multicast address. In the latter case, the application will join to a |
| 358 | multicast group. |
| 359 | |
| 360 | General purpose RTP stacks of ccRTP, such as `RTPSession' objects, |
| 361 | must be signaled to start execution. This is done calling the |
| 362 | `startRunning()' method. Note there is also a `enableStack()' method, |
| 363 | this only activates the stack but does not start the execution of the |
| 364 | stack thread. |
| 365 | |
| 366 | After the steps above, the application can receive data, but will not |
| 367 | transmit to any destination. This and other session parameters can be |
| 368 | set as follows: |
| 369 | |
| 370 | * Add destinations: calling the method `addDestination'. |
| 371 | |
| 372 | * Set payload format. Method `setPayloadFormat'. By default, the |
| 373 | static payload type 0 is assumed (PCMU format at 8Khz). |
| 374 | |
| 375 | * Set local SDES Items. For common applications, the CNAME item |
| 376 | value is automatically guessed as user@host. Other items have no |
| 377 | default value and are not sent in RTCP packets unless a value is |
| 378 | specified by the application. For those items that should be sent |
| 379 | in RTCP packets along with the mandatory CNAME, its values can be |
| 380 | set calling the `setSDESItem' and `setPRIVPrefix' methods over |
| 381 | the object returned by the `defaultApplication' global function. |
| 382 | |
| 383 | * Enable padding of data packets. Calling setPadding(uint8) on |
| 384 | outgoing data queues enables transparent padding of data packets |
| 385 | to a multiple of the padding maximum length specified. By default, |
| 386 | padding is off (maximum length of padding is 0). |
| 387 | |
| 388 | * setting addresses: |
| 389 | |
| 390 | * Set session bandwidth calling the `setSessionBandwidth' method of |
| 391 | the session object. If not called, a default bandwidth of 64Kbps |
| 392 | is assumed, and 5% of this bandwidth is used for RTCP. This |
| 393 | percentage can be changed through the setControlBandwidth method. |
| 394 | |
| 395 | |
| 396 | |
| 397 | File: ccrtp.info, Node: Sending Data, Next: Receiving Data, Prev: Initiating Sessions, Up: RTP Sessions |
| 398 | |
| 399 | 4.1.2 Sending Data |
| 400 | ------------------ |
| 401 | |
| 402 | Data packets are sent through the method `putData', that takes as first |
| 403 | parameter the RTP timestamp for the data specified as second parameter. |
| 404 | ccRTP handles the random offset for the RTP timestamp internally, so |
| 405 | the timestamp value that corresponds to the session creation time is 0. |
| 406 | |
| 407 | By default, the marker bit of the sent packets is not set. Its value |
| 408 | for the next packet (the one that will convey the data provided in the |
| 409 | next call to `putData') can be set through the `setMark' method, which |
| 410 | takes a boolean as argument. |
| 411 | |
| 412 | ccRTP also supports fragmenting data blocks into several RTP |
| 413 | packets. The `setMaxSendSegmentSize' method can be used to request that |
| 414 | no RTP packet be transmitted with a payload length greater than the |
| 415 | value specified through `setMaxSendSegmentSize'. The default value of |
| 416 | this parameter can be retrieved via `getDefaultMaxSendSegmentSize', |
| 417 | which currently should return 65536. When data blocks greater than the |
| 418 | maximum segment size are provided through `putData', two or more packet |
| 419 | will be inserted in the outgoing packet queue. All these packets but |
| 420 | the last one will have length equal to the maximum segment size, |
| 421 | whereas the last one's size will be lower or equal to the maximum |
| 422 | segment size. |
| 423 | |
| 424 | |
| 425 | File: ccrtp.info, Node: Receiving Data, Next: Closing Sessions, Prev: Sending Data, Up: RTP Sessions |
| 426 | |
| 427 | 4.1.3 Receiving Data |
| 428 | -------------------- |
| 429 | |
| 430 | Received data is retrieved from the incoming packet queue through the |
| 431 | `getData' method, which, given a timestamp and an optional source of |
| 432 | synchronization. This method returns a pointer to an `AppDataUnit' |
| 433 | object as opposed to a pointer to a memory block. In ccRTP application |
| 434 | data units are represented through objects of the `AppDataUnit' class, |
| 435 | that provides access to the synchronization source of the data and |
| 436 | other related properties. |
| 437 | |
| 438 | The incoming packet queue takes care of functions such as packet |
| 439 | reordering or filtering out duplicate packets. |
| 440 | |
| 441 | You can guess if there are packets in the reception queue calling |
| 442 | `isWaiting'. Both `getData' and `isWaiting' take an optional parameter |
| 443 | which selects a particular synchronization source of data units. If not |
| 444 | specified, data units are returned regardless of its source. |
| 445 | |
| 446 | |
| 447 | File: ccrtp.info, Node: Closing Sessions, Next: Types of Sessions, Prev: Receiving Data, Up: RTP Sessions |
| 448 | |
| 449 | 4.1.4 Closing Sessions |
| 450 | ---------------------- |
| 451 | |
| 452 | RTP sessions can be closed deleting or destroying `RTPSession' objects. |
| 453 | The stack sends a BYE packet to every destination when the destructor |
| 454 | of sessions is called. It is also possible to explicitly send a BYE |
| 455 | packet through the dispatchBYE method, which takes the leaving reason |
| 456 | string as argument. Note that dispatchBYE will honor a number of rules |
| 457 | for sending BYE packets specified in the RTP standard: a BYE packet is |
| 458 | not sent if no RTP/RTCP packet was sent, and BYE floods avoiding |
| 459 | mechanisms are employed. |
| 460 | |
| 461 | Note that when a BYE RTCP packet is received from a remote |
| 462 | participant, the virtual `onGotGoodbye' will be called. |
| 463 | |
| 464 | |
| 465 | File: ccrtp.info, Node: Types of Sessions, Prev: Closing Sessions, Up: RTP Sessions |
| 466 | |
| 467 | 4.1.5 Types of Sessions |
| 468 | ----------------------- |
| 469 | |
| 470 | _TODO:_ explain how to instantiate templates depending on the threading |
| 471 | model and the number of sockets to use. Also symmetric |
| 472 | channels/sessions. Describe what's a channel and a session. |
| 473 | |
| 474 | |
| 475 | File: ccrtp.info, Node: Payload Types and Formats, Next: Participants, Prev: RTP Sessions, Up: Using ccRTP |
| 476 | |
| 477 | 4.2 Payload Types and Formats |
| 478 | ============================= |
| 479 | |
| 480 | In the context of RTP, an RTP payload type is a 7-bit numeric |
| 481 | identifier that identifies a payload format. For payload types, GNU |
| 482 | ccRTP defines the integer type `PayloadType'. ccRTP also defines The |
| 483 | enumerated type `StaticPayloadType', as the enumeration of the RTP |
| 484 | Payload Types statically assigned for standard audio and video formats. |
| 485 | |
| 486 | These codes were initially specified in `RFC 1890, "RTP Profile for |
| 487 | Audio and Video Conferences with Minimal Control" (AVP profile)', |
| 488 | superseded by `RFC 3550', and are registered as MIME types in `RFC |
| 489 | 3555'. Codes below 96 may be assigned statically, although the default |
| 490 | bindings for many of them are already reserverd. Codes in the range |
| 491 | 96-127 are assigned dinamically by means outside of the RTP profile or |
| 492 | protocol specification. |
| 493 | |
| 494 | See the "RTP Parameters" list at IANA |
| 495 | `http://www.iana.org/assignments/rtp-parameters'. Note however that |
| 496 | registering static payload types is now considered a deprecated |
| 497 | practice in favor of dynamic payload type negotiation. |
| 498 | |
| 499 | The properties of a payload format that, as an RTP stack, ccRTP |
| 500 | takes into account are the payload type (numeric identifier) and the |
| 501 | RTP clock rate. Other properties, such as MIME type, number of audio |
| 502 | channels, "ptime" and "maxptime" are not considered. These are only of |
| 503 | interest for higher level protocols, such as SDP and H.245. |
| 504 | |
| 505 | GNU ccRTP defines a hierarchy of payload format classes. Its root is |
| 506 | `PayloadFormat', which is a base class for `StaticPayloadFormat' and |
| 507 | `DynamicPayloadFormat'. |
| 508 | |
| 509 | Static payload format objects are built from a static payload code. |
| 510 | These are defined in the enumerated type `StaticPayloadType'. The |
| 511 | following example constructs a `StaticPayloadFormat' object |
| 512 | corresponding to the payload type 0 (statically bounded to PCMA in `RFC |
| 513 | 3551'): |
| 514 | |
| 515 | StaticPayloadType pt = sptPCMU; |
| 516 | StaticPayloadFormat* spf = new StaticPayloadFormat(pt); |
| 517 | |
| 518 | Of course, we could have said: |
| 519 | |
| 520 | StaticPayloadFormat* spf = new StaticPayloadFormat(sptPCMA); |
| 521 | |
| 522 | StaticPayloadFormat objects build like the ones above hold the |
| 523 | necessary parameters so that the RTP stack can handle incoming and |
| 524 | outgoing packets. |
| 525 | |
| 526 | Regarding dynamic payload formats, a call to |
| 527 | `DynamicPayloadFormat::DynamicPayloadFormat(100,90000)' like the |
| 528 | following: |
| 529 | |
| 530 | DynamicPayloadFormat* dpf = new DynamicPayloadFormat(100,90000); |
| 531 | |
| 532 | Will construct a dynamic payload format object that ties together the |
| 533 | '100' payload type numeric identifier and an RTP clock rate of 90 Khz. |
| 534 | Note that the numeric identifier does not have to be in the dynamic |
| 535 | range. The static payload types are default bindings and MAY be |
| 536 | overriden, thus, DynamicPayloadFormat(0,90000) is a valid construct |
| 537 | provided 0 has been established as the payload type through a previous |
| 538 | negotiation process(1). |
| 539 | |
| 540 | Whether and how the payload has been negotiated is outside of the |
| 541 | scope of RTP and ccRTP, so applications must choose between |
| 542 | `StaticPayloadFormat' and `DynamicPayloadFormat' accordingly to their |
| 543 | multimedia session control mechanisms. |
| 544 | |
| 545 | ---------- Footnotes ---------- |
| 546 | |
| 547 | (1) Despite the fact that RFC 3551 defines a static binding of the 0 |
| 548 | code to mu-law PCM at 8Khz. |
| 549 | |
| 550 | |
| 551 | File: ccrtp.info, Node: Participants, Next: RTP Packets Extensions, Prev: Payload Types and Formats, Up: Using ccRTP |
| 552 | |
| 553 | 4.3 Participants And Sources of Synchronization |
| 554 | =============================================== |
| 555 | |
| 556 | In GNU ccRTP, there are classes that represent RTP applications |
| 557 | (`RTPApplication'), participants (`Participant'), synchronizacion |
| 558 | sources (`SyncSource') and RTP sessions (`RTPSession'). The relations |
| 559 | among these entities are shown in the following diagram: |
| 560 | |
| 561 | --------------- |
| 562 | --------------------| Participant |-------------------- |
| 563 | | 0:n --------------- 0:1 | |
| 564 | | 1 1:n | |
| 565 | ------------------ ---------------- |
| 566 | | RTPApplication | | SyncSource | |
| 567 | ------------------ ---------------- |
| 568 | | 1 0:n | |
| 569 | | --------------- | |
| 570 | --------------------| RTPSession |-------------------- |
| 571 | 0:n --------------- 1 |
| 572 | |
| 573 | An RTP application establishes a space of CNAME identifiers, whereas |
| 574 | an RTP session establishes a space of SSRC identifiers. |
| 575 | |
| 576 | For each source of synchronization seen in an RTP session, a |
| 577 | `SyncSource' object identified by a SSRC numeric identifier is created. |
| 578 | Thus, at the beginning of an RTP session there are no `SyncSource' |
| 579 | objects related. Note that, if the local source sends packets to itself |
| 580 | during an RTP session, a `SyncSource' object will be created for it. |
| 581 | |
| 582 | The list of sources of synchronization identified in an RTP session |
| 583 | can be retrived through STL-like iterators of type |
| 584 | `RTPSession::SyncSourcesIterator', as shown in the following example. |
| 585 | |
| 586 | // rx is an RTPSession object |
| 587 | RTPSession::SyncSourcesIterator it; |
| 588 | for (it = rx.begin() ; it != rx.end(); it++) { |
| 589 | const SyncSource &s = *it; |
| 590 | cout << s.getID(); |
| 591 | if ( s.isSender() ) |
| 592 | cout << "is an active sender"; |
| 593 | cout << endl; |
| 594 | } |
| 595 | |
| 596 | Note `RTPSession::SyncSourcesIterator' is a const iterator. |
| 597 | |
| 598 | When using RTCP, it is possible to associate several synchronization |
| 599 | source objects to a participant in the multimedia session, which is |
| 600 | represented through the association between `Participant' and |
| 601 | `SyncSource' objects. The participant object linked to a source of |
| 602 | synchronization can be retrieved through the |
| 603 | `SyncSource::getParticipant()' method, as the following examples shows: |
| 604 | |
| 605 | // s is a source of synchronization object (SyncSource) |
| 606 | Participant *p = s.getParticipant(); |
| 607 | cerr << p->getSDESItem(SDESItemTypeCNAME) << endl; |
| 608 | |
| 609 | When RTCP is not being used or the CNAME identifier corresponding to |
| 610 | a synchronization source has not been received yet, the participant |
| 611 | associated with a synchronization source is not known. In these cases, |
| 612 | the method `SyncSource::getParticipant()' will return a NULL pointer. |
| 613 | On the contrary, a participant is always related to a synchronization |
| 614 | source at least. It can also be related to more than one |
| 615 | synchronization source (for instance, when a participant in a |
| 616 | videoconference sends two video streams from two different chameras). |
| 617 | Note that, if the local source sends data and control packets to |
| 618 | itself, a `Participant' object will be created for it. |
| 619 | |
| 620 | Thus, the `SyncSource::getParticipant' provides a facility for |
| 621 | inter-media synchronization. |
| 622 | |
| 623 | The association of RTP sessions and participants with |
| 624 | `RTPApplication' objects makes it possible to implement several "RTP |
| 625 | applications" in the same application or process, each one having a |
| 626 | separate CNAME space. By default, all RTP sessions are associated to an |
| 627 | RTP application provided by the global method `defaultApplication()'. |
| 628 | The local CNAME for the default application is guessed from the user |
| 629 | and machine name, as specified in `RFC 3550'. |
| 630 | |
| 631 | However, other applications may be created through the constructor |
| 632 | `RTPApplication::RTPApplication(const std::string& cname)'. RTP |
| 633 | sessions are associated with applications other than the default via an |
| 634 | optional constructor parameter. |
| 635 | |
| 636 | Similarly to the list of synchronization sources, the list of |
| 637 | participants in a session can be retrieved using iterators of type |
| 638 | `RTPApplication::ParticipantsIterator', see the following example, |
| 639 | which shows the list of CNAMEs of the participants in the default |
| 640 | application: |
| 641 | |
| 642 | RTPApplication &app = defaultApplication(); |
| 643 | RTPApplication::ParticipantsIterator ai; |
| 644 | for ( ai = app.begin(); ai != app.end(); ai++ ) { |
| 645 | const Participant &p = *ai; |
| 646 | cerr << p.getSDESItem(SDESItemTypeCNAME) << endl; |
| 647 | } |
| 648 | |
| 649 | Note `RTPApplication::ParticipantsIterator' is a const iterator. |
| 650 | |
| 651 | _TODO: SyncSource states_. |
| 652 | |
| 653 | |
| 654 | File: ccrtp.info, Node: RTP Packets Extensions, Next: RTCP Packets Extensions, Prev: Participants, Up: Using ccRTP |
| 655 | |
| 656 | 4.4 RTP Packets Extensions |
| 657 | ========================== |
| 658 | |
| 659 | _TODO._ Describe `RTPPacket', `IncomingRTPPkt' and `OutgoingRTPPkt' |
| 660 | classes. *Note RTP Packets Arrival::, for a discussion of event |
| 661 | handling virtuals that allow for specialized processing of data packets. |
| 662 | |
| 663 | |
| 664 | File: ccrtp.info, Node: RTCP Packets Extensions, Next: Handling Events, Prev: RTP Packets Extensions, Up: Using ccRTP |
| 665 | |
| 666 | 4.5 RTCP Packets Extensions |
| 667 | =========================== |
| 668 | |
| 669 | *Note RTCP Packets Arrival::, for a discussion of event handling |
| 670 | virtuals that allow for specialized processing of control packets. |
| 671 | |
| 672 | |
| 673 | File: ccrtp.info, Node: Handling Events, Prev: RTCP Packets Extensions, Up: Using ccRTP |
| 674 | |
| 675 | 4.6 Handling Events |
| 676 | =================== |
| 677 | |
| 678 | There are a number of events that may require special response from the |
| 679 | application. ccRTP defines plug-ins to handle these events. |
| 680 | |
| 681 | * Menu: |
| 682 | |
| 683 | * RTP Packets Arrival:: Filtering and extending RTP packets parsing. |
| 684 | * RTCP Packets Arrival:: Filtering and extending RTCP packets parsing. |
| 685 | * Synchronization Source States:: Handling state transitions. |
| 686 | * SSRC Collisions:: Handling SSRC identifier collisions. |
| 687 | * RTP Packets Expiration:: Outgoing and incoming RTP packets expiration. |
| 688 | |
| 689 | |
| 690 | File: ccrtp.info, Node: RTP Packets Arrival, Next: RTCP Packets Arrival, Up: Handling Events |
| 691 | |
| 692 | 4.6.1 RTP Packets Arrival |
| 693 | ------------------------- |
| 694 | |
| 695 | `onRTPPacketRecv' is the virtual method that may be redefined in any |
| 696 | subclass of `IncomingDataQueue', particularly in subclasses of |
| 697 | `RTPSession'. It takes an `IncomingRTPPkt' object as argument and |
| 698 | returns a boolean indicating whether the packet should be inserted in |
| 699 | the reception queue. |
| 700 | |
| 701 | |
| 702 | File: ccrtp.info, Node: RTP Packets Expiration, Prev: SSRC Collisions, Up: Handling Events |
| 703 | |
| 704 | 4.6.2 RTP Packets Expiration |
| 705 | ---------------------------- |
| 706 | |
| 707 | `onExpireSend' and `onExpireRecv' |
| 708 | |
| 709 | `end2EndDelayed' |
| 710 | |
| 711 | |
| 712 | File: ccrtp.info, Node: RTCP Packets Arrival, Next: Synchronization Source States, Prev: RTP Packets Arrival, Up: Handling Events |
| 713 | |
| 714 | 4.6.3 RTCP Packets Arrival |
| 715 | -------------------------- |
| 716 | |
| 717 | Incoming RTCP packets are automatically handled by ccRTP. However, this |
| 718 | does not mean you can't track the reception of RTCP packets. |
| 719 | |
| 720 | * `onGotSR' |
| 721 | |
| 722 | * `onGotRR' |
| 723 | |
| 724 | * `onGotSDESChunk' |
| 725 | |
| 726 | * `onGotAPP' |
| 727 | |
| 728 | * `onGotRRSRExtension' |
| 729 | |
| 730 | |
| 731 | Note that this events correspond to RTCP packets, not RTCP compound |
| 732 | packets, and probably the reception of a compound packet will trigger |
| 733 | more than one of these events. |
| 734 | |
| 735 | |
| 736 | File: ccrtp.info, Node: Synchronization Source States, Next: SSRC Collisions, Prev: RTCP Packets Arrival, Up: Handling Events |
| 737 | |
| 738 | 4.6.4 Synchronization Source States |
| 739 | ----------------------------------- |
| 740 | |
| 741 | `onNewSyncSource'. |
| 742 | |
| 743 | |
| 744 | File: ccrtp.info, Node: SSRC Collisions, Next: RTP Packets Expiration, Prev: Synchronization Source States, Up: Handling Events |
| 745 | |
| 746 | 4.6.5 SSRC Collisions |
| 747 | --------------------- |
| 748 | |
| 749 | `onSSRCCollision'. |
| 750 | |
| 751 | |
| 752 | File: ccrtp.info, Node: Specialized Payload Formats, Next: Standards Tracking, Prev: Using ccRTP, Up: Top |
| 753 | |
| 754 | 5 Specialized Payload Formats |
| 755 | ***************************** |
| 756 | |
| 757 | _TODO:_ finish 2833bis and CN. |
| 758 | |
| 759 | _TODO:_ comment H.261 specific RTCP packets: FIR and NACK. |
| 760 | |
| 761 | |
| 762 | File: ccrtp.info, Node: Standards Tracking, Next: Upgrading, Prev: Specialized Payload Formats, Up: Top |
| 763 | |
| 764 | 6 Standards Tracking |
| 765 | ******************** |
| 766 | |
| 767 | _TODO: explain what is done/being done/planned_. |
| 768 | |
| 769 | * `RTP: A Transport Protocol for Real-Time Applications (RFC 3550, |
| 770 | which supersedes RFC 1889)'. |
| 771 | |
| 772 | * `RTP Profile for Audio and Video Conferences with Minimal Control |
| 773 | (RFC 3551, which supersedes RFC 1890)'. |
| 774 | |
| 775 | * `MIME Type Registration of RTP Payload Formats (RFC 3555)'. |
| 776 | |
| 777 | * `IANA RTP Parameters'. |
| 778 | |
| 779 | * `RTP Payload Format for H.261 Video Streams (RFC 2032)'. Defines |
| 780 | H.261 specific FIR and NACK RTCP packets. |
| 781 | |
| 782 | |
| 783 | Not yet implemented: |
| 784 | |
| 785 | * `The Secure Real-time Transport Protocol'. SRTP provile. |
| 786 | |
| 787 | * `Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)'. |
| 788 | |
| 789 | * `Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)'. |
| 790 | |
| 791 | * `Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)'. |
| 792 | |
| 793 | |
| 794 | |
| 795 | File: ccrtp.info, Node: Upgrading, Next: ccRTP Internals, Prev: Standards Tracking, Up: Top |
| 796 | |
| 797 | 7 Upgrading |
| 798 | *********** |
| 799 | |
| 800 | This chapter outlines the main steps required to upgrade applications |
| 801 | written for old releases of ccRTP (0.6.x, 0.7.x and 0.9.x series) to |
| 802 | the 1.0 series. It is written mostly as a recipe of replacements for |
| 803 | old constructs. |
| 804 | |
| 805 | Replace `#include <cc++/rtp.h>' with `#include <ccrtp/rtp.h>'(1). |
| 806 | |
| 807 | Changes that have to do more with Common C++ 2 than with ccRTP: |
| 808 | |
| 809 | `exit(int)' |
| 810 | Replace with exit() |
| 811 | |
| 812 | `Thread::Terminate()' |
| 813 | Replace with Thread::terminate() |
| 814 | |
| 815 | `ccxx_sleep(timeout_t)' |
| 816 | Replace with sleep(timeout_t). |
| 817 | |
| 818 | `Thread::Run()' |
| 819 | Replace with Thread::run() |
| 820 | |
| 821 | |
| 822 | Changes required by ccRTP itself: |
| 823 | |
| 824 | `RTPSource' |
| 825 | Now `SyncSource', and is a somewhat different concept. For |
| 826 | instance, calls to RTPSource::getID() must be replaced with calls |
| 827 | to SyncSource::getID(), which in most cases will not imply any |
| 828 | change to this part of the code. |
| 829 | |
| 830 | `RTPQueue::getLocalInfo()->getID()' |
| 831 | Replace with `RTPQueueBase::getLocalSSRC()' |
| 832 | |
| 833 | `RTPQueue::getCNAME()' |
| 834 | Replace with `defaultApplication().getSDESItem(SDESItemTypeSDES)'. |
| 835 | |
| 836 | `RTPQueue::getPacket()' |
| 837 | `getPacket()' has been removed and now there is only a `getData()' |
| 838 | method in the RTP queues. |
| 839 | |
| 840 | `RTPQueue::setTimeout()' |
| 841 | Replace calls to RTPQueue::setTimeout(microtimeout_t) with calls to |
| 842 | OutgoingDataQueue(microtimeout_t), whose purpose and working is |
| 843 | exactly the same. |
| 844 | |
| 845 | `RTPQueue::putPacket()' |
| 846 | `putPacket()' has been removed and now there is only a `putData()' |
| 847 | method in the RTP queues. Note also that now the payload type is |
| 848 | not specified for each outgoing RTP data block, instead use |
| 849 | RTPQueueBase::setPayloadFormat each time the payload type changes. |
| 850 | |
| 851 | `PayloadType' |
| 852 | The definition of payload types has deeply changed in order to |
| 853 | allow all standard uses of dynamic payload negotiation. Refer to |
| 854 | *note Payload Types and Formats::, for an explanation of the new |
| 855 | payload types and formats related classes. |
| 856 | |
| 857 | For example, `RTP_PAYLOAD_PCMU' must be replaced with something |
| 858 | like `StaticPayloadFormat pcmu(sptPCMU)', where `pcmu' is the name |
| 859 | of a static payload object that binds an statically assigned |
| 860 | `PayloadType' (2). to its corresponding RTP clock rate(3). |
| 861 | |
| 862 | `RTPSocket::Connect' |
| 863 | The call connect has been removed. Now, in order to send packets |
| 864 | to a destination `OutgoingDataQueue::addDestination' must be used. |
| 865 | It allows for setting more than one destination. Any destination |
| 866 | can actually be added more than one time with addDestination, |
| 867 | which can be used a simple trick to perform redundant |
| 868 | transmission: each packet -both RTP and RTCP- will be transmitted |
| 869 | to the destination as many times as it has been added to the list |
| 870 | of destinations through calling addDestination. |
| 871 | |
| 872 | `RTPQueue::getCurrentRate' |
| 873 | Replace with `RTPQueueBase::getCurrentRTPClockRate()'. |
| 874 | |
| 875 | `RTPSocket::Start' |
| 876 | Replace with `RTPSession::startRunning'. |
| 877 | |
| 878 | `RTPQueue::gotHello' |
| 879 | Replace with `QueueRTCPManager::onNewSyncSource'. |
| 880 | |
| 881 | `RTPQueue::gotGoodbye' |
| 882 | Replace with `QueueRTCPManager::onGotGoodbye'. |
| 883 | |
| 884 | |
| 885 | ---------- Footnotes ---------- |
| 886 | |
| 887 | (1) Note that unfortunately ccRTP 1.0pre0 used `#include |
| 888 | <cc++/rtp/rtp.h', which is now deprecated. |
| 889 | |
| 890 | (2) The static payload type 0 corresponds to the audio format PCMU, |
| 891 | see `RFC 3550'. |
| 892 | |
| 893 | (3) 8 khz. |
| 894 | |
| 895 | |
| 896 | File: ccrtp.info, Node: ccRTP Internals, Next: Related Work, Prev: Upgrading, Up: Top |
| 897 | |
| 898 | 8 ccRTP Internals |
| 899 | ***************** |
| 900 | |
| 901 | * Menu: |
| 902 | |
| 903 | * Internals Overview:: ccRTP internals overview. |
| 904 | * Collisions and Loops:: Collision Resolution and Loop Detection. |
| 905 | * Algorithms in the Standard:: Implementation of algorithms in the standard. |
| 906 | |
| 907 | |
| 908 | File: ccrtp.info, Node: Internals Overview, Next: Collisions and Loops, Up: ccRTP Internals |
| 909 | |
| 910 | 8.1 Internals Overview |
| 911 | ====================== |
| 912 | |
| 913 | _TODO: Explain where on how timer reconsideration/reverse recons. is |
| 914 | performed_. |
| 915 | |
| 916 | Performance: |
| 917 | |
| 918 | * Zero copy stack. |
| 919 | |
| 920 | * RW/R multithreading. |
| 921 | |
| 922 | * Fast specialized linked list and hash mechanisms. |
| 923 | |
| 924 | |
| 925 | File: ccrtp.info, Node: Collisions and Loops, Next: Algorithms in the Standard, Prev: Internals Overview, Up: ccRTP Internals |
| 926 | |
| 927 | 8.2 Collisions and Loops |
| 928 | ======================== |
| 929 | |
| 930 | ccRTP performs loop detection (following 8.2 in `RFC 3550', though the |
| 931 | algorithm in ccRTP differs is structure because of two reasons: |
| 932 | |
| 933 | * ccRTP holds a table of source for which some packet has been |
| 934 | received, instead of a table with all the sources in the session |
| 935 | (i.e. the local source is not included in the table unless it |
| 936 | sends packets to itself). |
| 937 | |
| 938 | * RTP and RTCP packets are handled separately whereas the algorithm |
| 939 | in 8.2 treats both. |
| 940 | |
| 941 | Note that the first two conditions in 8.2 (creating new source |
| 942 | entries and setting source transport address) are handled in the |
| 943 | SSRC bookkeeping methods rather than mixing them with the real |
| 944 | collisions and loop handling. |
| 945 | |
| 946 | Unlike the algorithm given in 8.2, the ccRTP algorithm detects the |
| 947 | very rare case when two sources on the same host use the same SSRC |
| 948 | identifier and the first RTP packet for that identifier is |
| 949 | received from one source and the first RTCP is received from the |
| 950 | other. |
| 951 | |
| 952 | |
| 953 | |
| 954 | File: ccrtp.info, Node: Algorithms in the Standard, Prev: Collisions and Loops, Up: ccRTP Internals |
| 955 | |
| 956 | 8.3 Algorithms in the Standard |
| 957 | ============================== |
| 958 | |
| 959 | The following sections summarizes how the algorithms specified in |
| 960 | appendixes from `RFC 3550' are implemented in ccRTP. A "mapping" |
| 961 | between routines in the RFC and methods/routines in ccRTP is provided. |
| 962 | |
| 963 | * Menu: |
| 964 | |
| 965 | * A.1:: RTP Data Header Validity Checks. |
| 966 | * A.2:: RTCP Header Validity Checks. |
| 967 | * A.3:: Determining the Number of RTP Packets Expected and Lost. |
| 968 | * A.4:: Generating SDES RTCP Packets. |
| 969 | * A.5:: Parsing RTCP SDES Packets. |
| 970 | * A.6:: Generating a Random 32-bit Identifier. |
| 971 | * A.7:: Computing the RTCP Transmission Interval. |
| 972 | * A.8:: Estimating the Interarrival Jitter. |
| 973 | |
| 974 | |
| 975 | File: ccrtp.info, Node: A.1, Next: A.2, Up: Algorithms in the Standard |
| 976 | |
| 977 | 8.3.1 A.1 |
| 978 | --------- |
| 979 | |
| 980 | ccRTP performs RTP data header validity check in two stages: the first |
| 981 | stage, performed at the constructor of `IncomingRTPPkt' (which is |
| 982 | extensible with virtual methods) validates the header fields |
| 983 | independent of the source. The second stage, performed at |
| 984 | `IncomingDataQueue::checkSSRCInIncomingRTPPkt' and |
| 985 | `QueueRTCPManager::checkSSRCInRTCPPkt', validates those fields specific |
| 986 | to the source of the packet (number sequence, etc). |
| 987 | |
| 988 | Additionally, the following table specifies which methods of ccRTP |
| 989 | implement the functions init_seq and update_seq from A.1. |
| 990 | |
| 991 | `void init_seq(source*, u_int16)' |
| 992 | void MembershipBookkeeping::SyncSourceLink::initSequence(uint16) |
| 993 | |
| 994 | `int update_seq(source*, u_int16)' |
| 995 | bool RTPQueue::recordReception(SyncSourceLink&, const |
| 996 | IncomingRTPPkt&) |
| 997 | |
| 998 | |
| 999 | |
| 1000 | File: ccrtp.info, Node: A.2, Next: A.3, Prev: A.1, Up: Algorithms in the Standard |
| 1001 | |
| 1002 | 8.3.2 A.2 |
| 1003 | --------- |
| 1004 | |
| 1005 | The code in A.2 corresponds to |
| 1006 | `RTCPCompoundHandler::checkCompountRTCPHeader'. |
| 1007 | |
| 1008 | |
| 1009 | File: ccrtp.info, Node: A.3, Next: A.4, Prev: A.2, Up: Algorithms in the Standard |
| 1010 | |
| 1011 | 8.3.3 A.3 |
| 1012 | --------- |
| 1013 | |
| 1014 | Code in A.3 corresponds to `MembershipBookeeping::computeStats'. |
| 1015 | |
| 1016 | |
| 1017 | File: ccrtp.info, Node: A.4, Next: A.5, Prev: A.3, Up: Algorithms in the Standard |
| 1018 | |
| 1019 | 8.3.4 A.4 |
| 1020 | --------- |
| 1021 | |
| 1022 | Code in A.4 is implemented as part of the method |
| 1023 | `QueueRTCPManager::packSDES'. |
| 1024 | |
| 1025 | |
| 1026 | File: ccrtp.info, Node: A.5, Next: A.6, Prev: A.4, Up: Algorithms in the Standard |
| 1027 | |
| 1028 | 8.3.5 A.5 |
| 1029 | --------- |
| 1030 | |
| 1031 | Code in A.5 is implemented in the method `QueueRTCPManager::onGotSDES', |
| 1032 | which calls the virtual method `QueueRTCPManager::onGotSDESChunk' to |
| 1033 | process each SDES chunk. |
| 1034 | |
| 1035 | |
| 1036 | File: ccrtp.info, Node: A.6, Next: A.7, Prev: A.5, Up: Algorithms in the Standard |
| 1037 | |
| 1038 | 8.3.6 A.6 |
| 1039 | --------- |
| 1040 | |
| 1041 | On POSIX systems, ccRTP uses `/dev/urandom' when available. If there is |
| 1042 | no such device, it defaults to the MD5 based algorithm given in |
| 1043 | appendix A.6. |
| 1044 | |
| 1045 | Code in A.6 corresponds to `uint32 MD5BasedRandom32()', which is |
| 1046 | called by `uint32 random32()' when no random device is available. |
| 1047 | |
| 1048 | |
| 1049 | File: ccrtp.info, Node: A.7, Next: A.8, Prev: A.6, Up: Algorithms in the Standard |
| 1050 | |
| 1051 | 8.3.7 A.7 |
| 1052 | --------- |
| 1053 | |
| 1054 | Mapping: |
| 1055 | |
| 1056 | `double rtcp_interval(int, int, double, int, double, int)' |
| 1057 | virtual timeval QueueRTCPManager::computeRTCPInterval(), and in |
| 1058 | timeval (seconds + microseconds) units, instead of seconds. |
| 1059 | |
| 1060 | `OnExpire(event, int, int, double, int, double, int time_tp, time_tp, int)' |
| 1061 | QueueRTCPManager::runControlService(microtimeout_t) (this method |
| 1062 | also implements part of SendRTCPReport(e)) |
| 1063 | |
| 1064 | `OnReceive(packet, event, int, int, int, double, double, double, double)' |
| 1065 | void QueueRTCPManager::takeInControlPacket() and |
| 1066 | QueueRTCPManager::runControlService(microtimeout_t) |
| 1067 | |
| 1068 | `Schedule(time, event) and Reschedule(time, event)' |
| 1069 | No equivalent. |
| 1070 | |
| 1071 | `SendRTCPReport(event)' |
| 1072 | `dispatchControlPacket'. |
| 1073 | |
| 1074 | `SendBYEPacket(event)' |
| 1075 | `QueueRTCPManager::dispatchBYE(const std::string& reason)'. |
| 1076 | |
| 1077 | `TypeOfEvent(event)' |
| 1078 | No equivalent. |
| 1079 | |
| 1080 | `PacketType(p)' |
| 1081 | No equivalent. |
| 1082 | |
| 1083 | `ReceivedPacketSize()' |
| 1084 | `size_t IncomingDataQueue::takeInDataPacket()'. |
| 1085 | |
| 1086 | `SentPacketSize()' |
| 1087 | `size_t OutgoingDataQueue::dispatchDataPacket()' -data, and |
| 1088 | `size_t QueueRTCPManager::dispatchControlPacket()' -control. |
| 1089 | |
| 1090 | `NewMember(p)' |
| 1091 | |
| 1092 | `NewSender(p)' |
| 1093 | |
| 1094 | `AddMember() and RemoveMember()' |
| 1095 | |
| 1096 | `AddSender() and RemoveSender()' |
| 1097 | |
| 1098 | |
| 1099 | File: ccrtp.info, Node: A.8, Prev: A.7, Up: Algorithms in the Standard |
| 1100 | |
| 1101 | 8.3.8 A.8 |
| 1102 | --------- |
| 1103 | |
| 1104 | Interarrival jitter is estimated as specified in A.8, in |
| 1105 | `recordReception'. Jitter is kept as a float. |
| 1106 | |
| 1107 | |
| 1108 | File: ccrtp.info, Node: Related Work, Next: Future Work, Prev: ccRTP Internals, Up: Top |
| 1109 | |
| 1110 | 9 Related Work |
| 1111 | ************** |
| 1112 | |
| 1113 | _TODO_. Other free RTP stacks and tools: |
| 1114 | |
| 1115 | * jrtplib |
| 1116 | |
| 1117 | * oRTP |
| 1118 | |
| 1119 | * LIVE.COM Streaming Media |
| 1120 | |
| 1121 | * UCL Common Code Library. Note this library is distributed under a |
| 1122 | BSD license _with_ the obnoxious clausule. |
| 1123 | |
| 1124 | |
| 1125 | File: ccrtp.info, Node: Future Work, Next: Licenses, Prev: Related Work, Up: Top |
| 1126 | |
| 1127 | 10 Future Work |
| 1128 | ************** |
| 1129 | |
| 1130 | _TODO_. |
| 1131 | |
| 1132 | |
| 1133 | File: ccrtp.info, Node: Licenses, Next: Class and Data Type Index, Prev: Future Work, Up: Top |
| 1134 | |
| 1135 | Appendix A Licenses |
| 1136 | ******************* |
| 1137 | |
| 1138 | * Menu: |
| 1139 | |
| 1140 | * GNU Free Documentation License:: License for this document. |
| 1141 | * GNU General Public License:: ccRTP Base License. |
| 1142 | * GNU ccRTP Linking Exception:: ccRTP linking exception. |
| 1143 | |
| 1144 | |
| 1145 | File: ccrtp.info, Node: GNU General Public License, Next: GNU ccRTP Linking Exception, Prev: GNU Free Documentation License, Up: Licenses |
| 1146 | |
| 1147 | A.1 GNU GENERAL PUBLIC LICENSE |
| 1148 | ============================== |
| 1149 | |
| 1150 | Version 2, June 1991 |
| 1151 | |
| 1152 | Copyright (C) 1989, 1991 Free Software Foundation, Inc. |
| 1153 | 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA |
| 1154 | |
| 1155 | Everyone is permitted to copy and distribute verbatim copies |
| 1156 | of this license document, but changing it is not allowed. |
| 1157 | |
| 1158 | A.1.1 Preamble |
| 1159 | -------------- |
| 1160 | |
| 1161 | The licenses for most software are designed to take away your freedom |
| 1162 | to share and change it. By contrast, the GNU General Public License is |
| 1163 | intended to guarantee your freedom to share and change free |
| 1164 | software--to make sure the software is free for all its users. This |
| 1165 | General Public License applies to most of the Free Software |
| 1166 | Foundation's software and to any other program whose authors commit to |
| 1167 | using it. (Some other Free Software Foundation software is covered by |
| 1168 | the GNU Library General Public License instead.) You can apply it to |
| 1169 | your programs, too. |
| 1170 | |
| 1171 | When we speak of free software, we are referring to freedom, not |
| 1172 | price. Our General Public Licenses are designed to make sure that you |
| 1173 | have the freedom to distribute copies of free software (and charge for |
| 1174 | this service if you wish), that you receive source code or can get it |
| 1175 | if you want it, that you can change the software or use pieces of it in |
| 1176 | new free programs; and that you know you can do these things. |
| 1177 | |
| 1178 | To protect your rights, we need to make restrictions that forbid |
| 1179 | anyone to deny you these rights or to ask you to surrender the rights. |
| 1180 | These restrictions translate to certain responsibilities for you if you |
| 1181 | distribute copies of the software, or if you modify it. |
| 1182 | |
| 1183 | For example, if you distribute copies of such a program, whether |
| 1184 | gratis or for a fee, you must give the recipients all the rights that |
| 1185 | you have. You must make sure that they, too, receive or can get the |
| 1186 | source code. And you must show them these terms so they know their |
| 1187 | rights. |
| 1188 | |
| 1189 | We protect your rights with two steps: (1) copyright the software, |
| 1190 | and (2) offer you this license which gives you legal permission to copy, |
| 1191 | distribute and/or modify the software. |
| 1192 | |
| 1193 | Also, for each author's protection and ours, we want to make certain |
| 1194 | that everyone understands that there is no warranty for this free |
| 1195 | software. If the software is modified by someone else and passed on, we |
| 1196 | want its recipients to know that what they have is not the original, so |
| 1197 | that any problems introduced by others will not reflect on the original |
| 1198 | authors' reputations. |
| 1199 | |
| 1200 | Finally, any free program is threatened constantly by software |
| 1201 | patents. We wish to avoid the danger that redistributors of a free |
| 1202 | program will individually obtain patent licenses, in effect making the |
| 1203 | program proprietary. To prevent this, we have made it clear that any |
| 1204 | patent must be licensed for everyone's free use or not licensed at all. |
| 1205 | |
| 1206 | The precise terms and conditions for copying, distribution and |
| 1207 | modification follow. |
| 1208 | |
| 1209 | TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION |
| 1210 | 0. This License applies to any program or other work which contains a |
| 1211 | notice placed by the copyright holder saying it may be distributed |
| 1212 | under the terms of this General Public License. The "Program", |
| 1213 | below, refers to any such program or work, and a "work based on |
| 1214 | the Program" means either the Program or any derivative work under |
| 1215 | copyright law: that is to say, a work containing the Program or a |
| 1216 | portion of it, either verbatim or with modifications and/or |
| 1217 | translated into another language. (Hereinafter, translation is |
| 1218 | included without limitation in the term "modification".) Each |
| 1219 | licensee is addressed as "you". |
| 1220 | |
| 1221 | Activities other than copying, distribution and modification are |
| 1222 | not covered by this License; they are outside its scope. The act |
| 1223 | of running the Program is not restricted, and the output from the |
| 1224 | Program is covered only if its contents constitute a work based on |
| 1225 | the Program (independent of having been made by running the |
| 1226 | Program). Whether that is true depends on what the Program does. |
| 1227 | |
| 1228 | 1. You may copy and distribute verbatim copies of the Program's |
| 1229 | source code as you receive it, in any medium, provided that you |
| 1230 | conspicuously and appropriately publish on each copy an appropriate |
| 1231 | copyright notice and disclaimer of warranty; keep intact all the |
| 1232 | notices that refer to this License and to the absence of any |
| 1233 | warranty; and give any other recipients of the Program a copy of |
| 1234 | this License along with the Program. |
| 1235 | |
| 1236 | You may charge a fee for the physical act of transferring a copy, |
| 1237 | and you may at your option offer warranty protection in exchange |
| 1238 | for a fee. |
| 1239 | |
| 1240 | 2. You may modify your copy or copies of the Program or any portion |
| 1241 | of it, thus forming a work based on the Program, and copy and |
| 1242 | distribute such modifications or work under the terms of Section 1 |
| 1243 | above, provided that you also meet all of these conditions: |
| 1244 | |
| 1245 | a. You must cause the modified files to carry prominent notices |
| 1246 | stating that you changed the files and the date of any change. |
| 1247 | |
| 1248 | b. You must cause any work that you distribute or publish, that |
| 1249 | in whole or in part contains or is derived from the Program |
| 1250 | or any part thereof, to be licensed as a whole at no charge |
| 1251 | to all third parties under the terms of this License. |
| 1252 | |
| 1253 | c. If the modified program normally reads commands interactively |
| 1254 | when run, you must cause it, when started running for such |
| 1255 | interactive use in the most ordinary way, to print or display |
| 1256 | an announcement including an appropriate copyright notice and |
| 1257 | a notice that there is no warranty (or else, saying that you |
| 1258 | provide a warranty) and that users may redistribute the |
| 1259 | program under these conditions, and telling the user how to |
| 1260 | view a copy of this License. (Exception: if the Program |
| 1261 | itself is interactive but does not normally print such an |
| 1262 | announcement, your work based on the Program is not required |
| 1263 | to print an announcement.) |
| 1264 | |
| 1265 | These requirements apply to the modified work as a whole. If |
| 1266 | identifiable sections of that work are not derived from the |
| 1267 | Program, and can be reasonably considered independent and separate |
| 1268 | works in themselves, then this License, and its terms, do not |
| 1269 | apply to those sections when you distribute them as separate |
| 1270 | works. But when you distribute the same sections as part of a |
| 1271 | whole which is a work based on the Program, the distribution of |
| 1272 | the whole must be on the terms of this License, whose permissions |
| 1273 | for other licensees extend to the entire whole, and thus to each |
| 1274 | and every part regardless of who wrote it. |
| 1275 | |
| 1276 | Thus, it is not the intent of this section to claim rights or |
| 1277 | contest your rights to work written entirely by you; rather, the |
| 1278 | intent is to exercise the right to control the distribution of |
| 1279 | derivative or collective works based on the Program. |
| 1280 | |
| 1281 | In addition, mere aggregation of another work not based on the |
| 1282 | Program with the Program (or with a work based on the Program) on |
| 1283 | a volume of a storage or distribution medium does not bring the |
| 1284 | other work under the scope of this License. |
| 1285 | |
| 1286 | 3. You may copy and distribute the Program (or a work based on it, |
| 1287 | under Section 2) in object code or executable form under the terms |
| 1288 | of Sections 1 and 2 above provided that you also do one of the |
| 1289 | following: |
| 1290 | |
| 1291 | a. Accompany it with the complete corresponding machine-readable |
| 1292 | source code, which must be distributed under the terms of |
| 1293 | Sections 1 and 2 above on a medium customarily used for |
| 1294 | software interchange; or, |
| 1295 | |
| 1296 | b. Accompany it with a written offer, valid for at least three |
| 1297 | years, to give any third party, for a charge no more than your |
| 1298 | cost of physically performing source distribution, a complete |
| 1299 | machine-readable copy of the corresponding source code, to be |
| 1300 | distributed under the terms of Sections 1 and 2 above on a |
| 1301 | medium customarily used for software interchange; or, |
| 1302 | |
| 1303 | c. Accompany it with the information you received as to the offer |
| 1304 | to distribute corresponding source code. (This alternative is |
| 1305 | allowed only for noncommercial distribution and only if you |
| 1306 | received the program in object code or executable form with |
| 1307 | such an offer, in accord with Subsection b above.) |
| 1308 | |
| 1309 | The source code for a work means the preferred form of the work for |
| 1310 | making modifications to it. For an executable work, complete |
| 1311 | source code means all the source code for all modules it contains, |
| 1312 | plus any associated interface definition files, plus the scripts |
| 1313 | used to control compilation and installation of the executable. |
| 1314 | However, as a special exception, the source code distributed need |
| 1315 | not include anything that is normally distributed (in either |
| 1316 | source or binary form) with the major components (compiler, |
| 1317 | kernel, and so on) of the operating system on which the executable |
| 1318 | runs, unless that component itself accompanies the executable. |
| 1319 | |
| 1320 | If distribution of executable or object code is made by offering |
| 1321 | access to copy from a designated place, then offering equivalent |
| 1322 | access to copy the source code from the same place counts as |
| 1323 | distribution of the source code, even though third parties are not |
| 1324 | compelled to copy the source along with the object code. |
| 1325 | |
| 1326 | 4. You may not copy, modify, sublicense, or distribute the Program |
| 1327 | except as expressly provided under this License. Any attempt |
| 1328 | otherwise to copy, modify, sublicense or distribute the Program is |
| 1329 | void, and will automatically terminate your rights under this |
| 1330 | License. However, parties who have received copies, or rights, |
| 1331 | from you under this License will not have their licenses |
| 1332 | terminated so long as such parties remain in full compliance. |
| 1333 | |
| 1334 | 5. You are not required to accept this License, since you have not |
| 1335 | signed it. However, nothing else grants you permission to modify |
| 1336 | or distribute the Program or its derivative works. These actions |
| 1337 | are prohibited by law if you do not accept this License. |
| 1338 | Therefore, by modifying or distributing the Program (or any work |
| 1339 | based on the Program), you indicate your acceptance of this |
| 1340 | License to do so, and all its terms and conditions for copying, |
| 1341 | distributing or modifying the Program or works based on it. |
| 1342 | |
| 1343 | 6. Each time you redistribute the Program (or any work based on the |
| 1344 | Program), the recipient automatically receives a license from the |
| 1345 | original licensor to copy, distribute or modify the Program |
| 1346 | subject to these terms and conditions. You may not impose any |
| 1347 | further restrictions on the recipients' exercise of the rights |
| 1348 | granted herein. You are not responsible for enforcing compliance |
| 1349 | by third parties to this License. |
| 1350 | |
| 1351 | 7. If, as a consequence of a court judgment or allegation of patent |
| 1352 | infringement or for any other reason (not limited to patent |
| 1353 | issues), conditions are imposed on you (whether by court order, |
| 1354 | agreement or otherwise) that contradict the conditions of this |
| 1355 | License, they do not excuse you from the conditions of this |
| 1356 | License. If you cannot distribute so as to satisfy simultaneously |
| 1357 | your obligations under this License and any other pertinent |
| 1358 | obligations, then as a consequence you may not distribute the |
| 1359 | Program at all. For example, if a patent license would not permit |
| 1360 | royalty-free redistribution of the Program by all those who |
| 1361 | receive copies directly or indirectly through you, then the only |
| 1362 | way you could satisfy both it and this License would be to refrain |
| 1363 | entirely from distribution of the Program. |
| 1364 | |
| 1365 | If any portion of this section is held invalid or unenforceable |
| 1366 | under any particular circumstance, the balance of the section is |
| 1367 | intended to apply and the section as a whole is intended to apply |
| 1368 | in other circumstances. |
| 1369 | |
| 1370 | It is not the purpose of this section to induce you to infringe any |
| 1371 | patents or other property right claims or to contest validity of |
| 1372 | any such claims; this section has the sole purpose of protecting |
| 1373 | the integrity of the free software distribution system, which is |
| 1374 | implemented by public license practices. Many people have made |
| 1375 | generous contributions to the wide range of software distributed |
| 1376 | through that system in reliance on consistent application of that |
| 1377 | system; it is up to the author/donor to decide if he or she is |
| 1378 | willing to distribute software through any other system and a |
| 1379 | licensee cannot impose that choice. |
| 1380 | |
| 1381 | This section is intended to make thoroughly clear what is believed |
| 1382 | to be a consequence of the rest of this License. |
| 1383 | |
| 1384 | 8. If the distribution and/or use of the Program is restricted in |
| 1385 | certain countries either by patents or by copyrighted interfaces, |
| 1386 | the original copyright holder who places the Program under this |
| 1387 | License may add an explicit geographical distribution limitation |
| 1388 | excluding those countries, so that distribution is permitted only |
| 1389 | in or among countries not thus excluded. In such case, this |
| 1390 | License incorporates the limitation as if written in the body of |
| 1391 | this License. |
| 1392 | |
| 1393 | 9. The Free Software Foundation may publish revised and/or new |
| 1394 | versions of the General Public License from time to time. Such |
| 1395 | new versions will be similar in spirit to the present version, but |
| 1396 | may differ in detail to address new problems or concerns. |
| 1397 | |
| 1398 | Each version is given a distinguishing version number. If the |
| 1399 | Program specifies a version number of this License which applies |
| 1400 | to it and "any later version", you have the option of following |
| 1401 | the terms and conditions either of that version or of any later |
| 1402 | version published by the Free Software Foundation. If the Program |
| 1403 | does not specify a version number of this License, you may choose |
| 1404 | any version ever published by the Free Software Foundation. |
| 1405 | |
| 1406 | 10. If you wish to incorporate parts of the Program into other free |
| 1407 | programs whose distribution conditions are different, write to the |
| 1408 | author to ask for permission. For software which is copyrighted |
| 1409 | by the Free Software Foundation, write to the Free Software |
| 1410 | Foundation; we sometimes make exceptions for this. Our decision |
| 1411 | will be guided by the two goals of preserving the free status of |
| 1412 | all derivatives of our free software and of promoting the sharing |
| 1413 | and reuse of software generally. |
| 1414 | |
| 1415 | NO WARRANTY |
| 1416 | 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO |
| 1417 | WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE |
| 1418 | LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT |
| 1419 | HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT |
| 1420 | WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT |
| 1421 | NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND |
| 1422 | FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE |
| 1423 | QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE |
| 1424 | PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY |
| 1425 | SERVICING, REPAIR OR CORRECTION. |
| 1426 | |
| 1427 | 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN |
| 1428 | WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY |
| 1429 | MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE |
| 1430 | LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, |
| 1431 | INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR |
| 1432 | INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF |
| 1433 | DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU |
| 1434 | OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY |
| 1435 | OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN |
| 1436 | ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. |
| 1437 | |
| 1438 | END OF TERMS AND CONDITIONS |
| 1439 | A.1.2 Appendix: How to Apply These Terms to Your New Programs |
| 1440 | ------------------------------------------------------------- |
| 1441 | |
| 1442 | If you develop a new program, and you want it to be of the greatest |
| 1443 | possible use to the public, the best way to achieve this is to make it |
| 1444 | free software which everyone can redistribute and change under these |
| 1445 | terms. |
| 1446 | |
| 1447 | To do so, attach the following notices to the program. It is safest |
| 1448 | to attach them to the start of each source file to most effectively |
| 1449 | convey the exclusion of warranty; and each file should have at least |
| 1450 | the "copyright" line and a pointer to where the full notice is found. |
| 1451 | |
| 1452 | ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES. |
| 1453 | Copyright (C) YYYY NAME OF AUTHOR |
| 1454 | |
| 1455 | This program is free software; you can redistribute it and/or modify |
| 1456 | it under the terms of the GNU General Public License as published by |
| 1457 | the Free Software Foundation; either version 2 of the License, or |
| 1458 | (at your option) any later version. |
| 1459 | |
| 1460 | This program is distributed in the hope that it will be useful, |
| 1461 | but WITHOUT ANY WARRANTY; without even the implied warranty of |
| 1462 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
| 1463 | GNU General Public License for more details. |
| 1464 | |
| 1465 | You should have received a copy of the GNU General Public License |
| 1466 | along with this program; if not, write to the Free Software |
| 1467 | Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. |
| 1468 | |
| 1469 | Also add information on how to contact you by electronic and paper |
| 1470 | mail. |
| 1471 | |
| 1472 | If the program is interactive, make it output a short notice like |
| 1473 | this when it starts in an interactive mode: |
| 1474 | |
| 1475 | Gnomovision version 69, Copyright (C) 19YY NAME OF AUTHOR |
| 1476 | Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. |
| 1477 | This is free software, and you are welcome to redistribute it |
| 1478 | under certain conditions; type `show c' for details. |
| 1479 | |
| 1480 | The hypothetical commands `show w' and `show c' should show the |
| 1481 | appropriate parts of the General Public License. Of course, the |
| 1482 | commands you use may be called something other than `show w' and `show |
| 1483 | c'; they could even be mouse-clicks or menu items--whatever suits your |
| 1484 | program. |
| 1485 | |
| 1486 | You should also get your employer (if you work as a programmer) or |
| 1487 | your school, if any, to sign a "copyright disclaimer" for the program, |
| 1488 | if necessary. Here is a sample; alter the names: |
| 1489 | |
| 1490 | Yoyodyne, Inc., hereby disclaims all copyright interest in the program |
| 1491 | `Gnomovision' (which makes passes at compilers) written by James Hacker. |
| 1492 | |
| 1493 | SIGNATURE OF TY COON, 1 April 1989 |
| 1494 | Ty Coon, President of Vice |
| 1495 | |
| 1496 | This General Public License does not permit incorporating your |
| 1497 | program into proprietary programs. If your program is a subroutine |
| 1498 | library, you may consider it more useful to permit linking proprietary |
| 1499 | applications with the library. If this is what you want to do, use the |
| 1500 | GNU Library General Public License instead of this License. |
| 1501 | |
| 1502 | |
| 1503 | File: ccrtp.info, Node: GNU Free Documentation License, Next: GNU General Public License, Up: Licenses |
| 1504 | |
| 1505 | A.2 GNU Free Documentation License |
| 1506 | ================================== |
| 1507 | |
| 1508 | Version 1.2, November 2002 |
| 1509 | |
| 1510 | Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. |
| 1511 | 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA |
| 1512 | |
| 1513 | Everyone is permitted to copy and distribute verbatim copies |
| 1514 | of this license document, but changing it is not allowed. |
| 1515 | |
| 1516 | 0. PREAMBLE |
| 1517 | |
| 1518 | The purpose of this License is to make a manual, textbook, or other |
| 1519 | functional and useful document "free" in the sense of freedom: to |
| 1520 | assure everyone the effective freedom to copy and redistribute it, |
| 1521 | with or without modifying it, either commercially or |
| 1522 | noncommercially. Secondarily, this License preserves for the |
| 1523 | author and publisher a way to get credit for their work, while not |
| 1524 | being considered responsible for modifications made by others. |
| 1525 | |
| 1526 | This License is a kind of "copyleft", which means that derivative |
| 1527 | works of the document must themselves be free in the same sense. |
| 1528 | It complements the GNU General Public License, which is a copyleft |
| 1529 | license designed for free software. |
| 1530 | |
| 1531 | We have designed this License in order to use it for manuals for |
| 1532 | free software, because free software needs free documentation: a |
| 1533 | free program should come with manuals providing the same freedoms |
| 1534 | that the software does. But this License is not limited to |
| 1535 | software manuals; it can be used for any textual work, regardless |
| 1536 | of subject matter or whether it is published as a printed book. |
| 1537 | We recommend this License principally for works whose purpose is |
| 1538 | instruction or reference. |
| 1539 | |
| 1540 | 1. APPLICABILITY AND DEFINITIONS |
| 1541 | |
| 1542 | This License applies to any manual or other work, in any medium, |
| 1543 | that contains a notice placed by the copyright holder saying it |
| 1544 | can be distributed under the terms of this License. Such a notice |
| 1545 | grants a world-wide, royalty-free license, unlimited in duration, |
| 1546 | to use that work under the conditions stated herein. The |
| 1547 | "Document", below, refers to any such manual or work. Any member |
| 1548 | of the public is a licensee, and is addressed as "you". You |
| 1549 | accept the license if you copy, modify or distribute the work in a |
| 1550 | way requiring permission under copyright law. |
| 1551 | |
| 1552 | A "Modified Version" of the Document means any work containing the |
| 1553 | Document or a portion of it, either copied verbatim, or with |
| 1554 | modifications and/or translated into another language. |
| 1555 | |
| 1556 | A "Secondary Section" is a named appendix or a front-matter section |
| 1557 | of the Document that deals exclusively with the relationship of the |
| 1558 | publishers or authors of the Document to the Document's overall |
| 1559 | subject (or to related matters) and contains nothing that could |
| 1560 | fall directly within that overall subject. (Thus, if the Document |
| 1561 | is in part a textbook of mathematics, a Secondary Section may not |
| 1562 | explain any mathematics.) The relationship could be a matter of |
| 1563 | historical connection with the subject or with related matters, or |
| 1564 | of legal, commercial, philosophical, ethical or political position |
| 1565 | regarding them. |
| 1566 | |
| 1567 | The "Invariant Sections" are certain Secondary Sections whose |
| 1568 | titles are designated, as being those of Invariant Sections, in |
| 1569 | the notice that says that the Document is released under this |
| 1570 | License. If a section does not fit the above definition of |
| 1571 | Secondary then it is not allowed to be designated as Invariant. |
| 1572 | The Document may contain zero Invariant Sections. If the Document |
| 1573 | does not identify any Invariant Sections then there are none. |
| 1574 | |
| 1575 | The "Cover Texts" are certain short passages of text that are |
| 1576 | listed, as Front-Cover Texts or Back-Cover Texts, in the notice |
| 1577 | that says that the Document is released under this License. A |
| 1578 | Front-Cover Text may be at most 5 words, and a Back-Cover Text may |
| 1579 | be at most 25 words. |
| 1580 | |
| 1581 | A "Transparent" copy of the Document means a machine-readable copy, |
| 1582 | represented in a format whose specification is available to the |
| 1583 | general public, that is suitable for revising the document |
| 1584 | straightforwardly with generic text editors or (for images |
| 1585 | composed of pixels) generic paint programs or (for drawings) some |
| 1586 | widely available drawing editor, and that is suitable for input to |
| 1587 | text formatters or for automatic translation to a variety of |
| 1588 | formats suitable for input to text formatters. A copy made in an |
| 1589 | otherwise Transparent file format whose markup, or absence of |
| 1590 | markup, has been arranged to thwart or discourage subsequent |
| 1591 | modification by readers is not Transparent. An image format is |
| 1592 | not Transparent if used for any substantial amount of text. A |
| 1593 | copy that is not "Transparent" is called "Opaque". |
| 1594 | |
| 1595 | Examples of suitable formats for Transparent copies include plain |
| 1596 | ASCII without markup, Texinfo input format, LaTeX input format, |
| 1597 | SGML or XML using a publicly available DTD, and |
| 1598 | standard-conforming simple HTML, PostScript or PDF designed for |
| 1599 | human modification. Examples of transparent image formats include |
| 1600 | PNG, XCF and JPG. Opaque formats include proprietary formats that |
| 1601 | can be read and edited only by proprietary word processors, SGML or |
| 1602 | XML for which the DTD and/or processing tools are not generally |
| 1603 | available, and the machine-generated HTML, PostScript or PDF |
| 1604 | produced by some word processors for output purposes only. |
| 1605 | |
| 1606 | The "Title Page" means, for a printed book, the title page itself, |
| 1607 | plus such following pages as are needed to hold, legibly, the |
| 1608 | material this License requires to appear in the title page. For |
| 1609 | works in formats which do not have any title page as such, "Title |
| 1610 | Page" means the text near the most prominent appearance of the |
| 1611 | work's title, preceding the beginning of the body of the text. |
| 1612 | |
| 1613 | A section "Entitled XYZ" means a named subunit of the Document |
| 1614 | whose title either is precisely XYZ or contains XYZ in parentheses |
| 1615 | following text that translates XYZ in another language. (Here XYZ |
| 1616 | stands for a specific section name mentioned below, such as |
| 1617 | "Acknowledgements", "Dedications", "Endorsements", or "History".) |
| 1618 | To "Preserve the Title" of such a section when you modify the |
| 1619 | Document means that it remains a section "Entitled XYZ" according |
| 1620 | to this definition. |
| 1621 | |
| 1622 | The Document may include Warranty Disclaimers next to the notice |
| 1623 | which states that this License applies to the Document. These |
| 1624 | Warranty Disclaimers are considered to be included by reference in |
| 1625 | this License, but only as regards disclaiming warranties: any other |
| 1626 | implication that these Warranty Disclaimers may have is void and |
| 1627 | has no effect on the meaning of this License. |
| 1628 | |
| 1629 | 2. VERBATIM COPYING |
| 1630 | |
| 1631 | You may copy and distribute the Document in any medium, either |
| 1632 | commercially or noncommercially, provided that this License, the |
| 1633 | copyright notices, and the license notice saying this License |
| 1634 | applies to the Document are reproduced in all copies, and that you |
| 1635 | add no other conditions whatsoever to those of this License. You |
| 1636 | may not use technical measures to obstruct or control the reading |
| 1637 | or further copying of the copies you make or distribute. However, |
| 1638 | you may accept compensation in exchange for copies. If you |
| 1639 | distribute a large enough number of copies you must also follow |
| 1640 | the conditions in section 3. |
| 1641 | |
| 1642 | You may also lend copies, under the same conditions stated above, |
| 1643 | and you may publicly display copies. |
| 1644 | |
| 1645 | 3. COPYING IN QUANTITY |
| 1646 | |
| 1647 | If you publish printed copies (or copies in media that commonly |
| 1648 | have printed covers) of the Document, numbering more than 100, and |
| 1649 | the Document's license notice requires Cover Texts, you must |
| 1650 | enclose the copies in covers that carry, clearly and legibly, all |
| 1651 | these Cover Texts: Front-Cover Texts on the front cover, and |
| 1652 | Back-Cover Texts on the back cover. Both covers must also clearly |
| 1653 | and legibly identify you as the publisher of these copies. The |
| 1654 | front cover must present the full title with all words of the |
| 1655 | title equally prominent and visible. You may add other material |
| 1656 | on the covers in addition. Copying with changes limited to the |
| 1657 | covers, as long as they preserve the title of the Document and |
| 1658 | satisfy these conditions, can be treated as verbatim copying in |
| 1659 | other respects. |
| 1660 | |
| 1661 | If the required texts for either cover are too voluminous to fit |
| 1662 | legibly, you should put the first ones listed (as many as fit |
| 1663 | reasonably) on the actual cover, and continue the rest onto |
| 1664 | adjacent pages. |
| 1665 | |
| 1666 | If you publish or distribute Opaque copies of the Document |
| 1667 | numbering more than 100, you must either include a |
| 1668 | machine-readable Transparent copy along with each Opaque copy, or |
| 1669 | state in or with each Opaque copy a computer-network location from |
| 1670 | which the general network-using public has access to download |
| 1671 | using public-standard network protocols a complete Transparent |
| 1672 | copy of the Document, free of added material. If you use the |
| 1673 | latter option, you must take reasonably prudent steps, when you |
| 1674 | begin distribution of Opaque copies in quantity, to ensure that |
| 1675 | this Transparent copy will remain thus accessible at the stated |
| 1676 | location until at least one year after the last time you |
| 1677 | distribute an Opaque copy (directly or through your agents or |
| 1678 | retailers) of that edition to the public. |
| 1679 | |
| 1680 | It is requested, but not required, that you contact the authors of |
| 1681 | the Document well before redistributing any large number of |
| 1682 | copies, to give them a chance to provide you with an updated |
| 1683 | version of the Document. |
| 1684 | |
| 1685 | 4. MODIFICATIONS |
| 1686 | |
| 1687 | You may copy and distribute a Modified Version of the Document |
| 1688 | under the conditions of sections 2 and 3 above, provided that you |
| 1689 | release the Modified Version under precisely this License, with |
| 1690 | the Modified Version filling the role of the Document, thus |
| 1691 | licensing distribution and modification of the Modified Version to |
| 1692 | whoever possesses a copy of it. In addition, you must do these |
| 1693 | things in the Modified Version: |
| 1694 | |
| 1695 | A. Use in the Title Page (and on the covers, if any) a title |
| 1696 | distinct from that of the Document, and from those of |
| 1697 | previous versions (which should, if there were any, be listed |
| 1698 | in the History section of the Document). You may use the |
| 1699 | same title as a previous version if the original publisher of |
| 1700 | that version gives permission. |
| 1701 | |
| 1702 | B. List on the Title Page, as authors, one or more persons or |
| 1703 | entities responsible for authorship of the modifications in |
| 1704 | the Modified Version, together with at least five of the |
| 1705 | principal authors of the Document (all of its principal |
| 1706 | authors, if it has fewer than five), unless they release you |
| 1707 | from this requirement. |
| 1708 | |
| 1709 | C. State on the Title page the name of the publisher of the |
| 1710 | Modified Version, as the publisher. |
| 1711 | |
| 1712 | D. Preserve all the copyright notices of the Document. |
| 1713 | |
| 1714 | E. Add an appropriate copyright notice for your modifications |
| 1715 | adjacent to the other copyright notices. |
| 1716 | |
| 1717 | F. Include, immediately after the copyright notices, a license |
| 1718 | notice giving the public permission to use the Modified |
| 1719 | Version under the terms of this License, in the form shown in |
| 1720 | the Addendum below. |
| 1721 | |
| 1722 | G. Preserve in that license notice the full lists of Invariant |
| 1723 | Sections and required Cover Texts given in the Document's |
| 1724 | license notice. |
| 1725 | |
| 1726 | H. Include an unaltered copy of this License. |
| 1727 | |
| 1728 | I. Preserve the section Entitled "History", Preserve its Title, |
| 1729 | and add to it an item stating at least the title, year, new |
| 1730 | authors, and publisher of the Modified Version as given on |
| 1731 | the Title Page. If there is no section Entitled "History" in |
| 1732 | the Document, create one stating the title, year, authors, |
| 1733 | and publisher of the Document as given on its Title Page, |
| 1734 | then add an item describing the Modified Version as stated in |
| 1735 | the previous sentence. |
| 1736 | |
| 1737 | J. Preserve the network location, if any, given in the Document |
| 1738 | for public access to a Transparent copy of the Document, and |
| 1739 | likewise the network locations given in the Document for |
| 1740 | previous versions it was based on. These may be placed in |
| 1741 | the "History" section. You may omit a network location for a |
| 1742 | work that was published at least four years before the |
| 1743 | Document itself, or if the original publisher of the version |
| 1744 | it refers to gives permission. |
| 1745 | |
| 1746 | K. For any section Entitled "Acknowledgements" or "Dedications", |
| 1747 | Preserve the Title of the section, and preserve in the |
| 1748 | section all the substance and tone of each of the contributor |
| 1749 | acknowledgements and/or dedications given therein. |
| 1750 | |
| 1751 | L. Preserve all the Invariant Sections of the Document, |
| 1752 | unaltered in their text and in their titles. Section numbers |
| 1753 | or the equivalent are not considered part of the section |
| 1754 | titles. |
| 1755 | |
| 1756 | M. Delete any section Entitled "Endorsements". Such a section |
| 1757 | may not be included in the Modified Version. |
| 1758 | |
| 1759 | N. Do not retitle any existing section to be Entitled |
| 1760 | "Endorsements" or to conflict in title with any Invariant |
| 1761 | Section. |
| 1762 | |
| 1763 | O. Preserve any Warranty Disclaimers. |
| 1764 | |
| 1765 | If the Modified Version includes new front-matter sections or |
| 1766 | appendices that qualify as Secondary Sections and contain no |
| 1767 | material copied from the Document, you may at your option |
| 1768 | designate some or all of these sections as invariant. To do this, |
| 1769 | add their titles to the list of Invariant Sections in the Modified |
| 1770 | Version's license notice. These titles must be distinct from any |
| 1771 | other section titles. |
| 1772 | |
| 1773 | You may add a section Entitled "Endorsements", provided it contains |
| 1774 | nothing but endorsements of your Modified Version by various |
| 1775 | parties--for example, statements of peer review or that the text |
| 1776 | has been approved by an organization as the authoritative |
| 1777 | definition of a standard. |
| 1778 | |
| 1779 | You may add a passage of up to five words as a Front-Cover Text, |
| 1780 | and a passage of up to 25 words as a Back-Cover Text, to the end |
| 1781 | of the list of Cover Texts in the Modified Version. Only one |
| 1782 | passage of Front-Cover Text and one of Back-Cover Text may be |
| 1783 | added by (or through arrangements made by) any one entity. If the |
| 1784 | Document already includes a cover text for the same cover, |
| 1785 | previously added by you or by arrangement made by the same entity |
| 1786 | you are acting on behalf of, you may not add another; but you may |
| 1787 | replace the old one, on explicit permission from the previous |
| 1788 | publisher that added the old one. |
| 1789 | |
| 1790 | The author(s) and publisher(s) of the Document do not by this |
| 1791 | License give permission to use their names for publicity for or to |
| 1792 | assert or imply endorsement of any Modified Version. |
| 1793 | |
| 1794 | 5. COMBINING DOCUMENTS |
| 1795 | |
| 1796 | You may combine the Document with other documents released under |
| 1797 | this License, under the terms defined in section 4 above for |
| 1798 | modified versions, provided that you include in the combination |
| 1799 | all of the Invariant Sections of all of the original documents, |
| 1800 | unmodified, and list them all as Invariant Sections of your |
| 1801 | combined work in its license notice, and that you preserve all |
| 1802 | their Warranty Disclaimers. |
| 1803 | |
| 1804 | The combined work need only contain one copy of this License, and |
| 1805 | multiple identical Invariant Sections may be replaced with a single |
| 1806 | copy. If there are multiple Invariant Sections with the same name |
| 1807 | but different contents, make the title of each such section unique |
| 1808 | by adding at the end of it, in parentheses, the name of the |
| 1809 | original author or publisher of that section if known, or else a |
| 1810 | unique number. Make the same adjustment to the section titles in |
| 1811 | the list of Invariant Sections in the license notice of the |
| 1812 | combined work. |
| 1813 | |
| 1814 | In the combination, you must combine any sections Entitled |
| 1815 | "History" in the various original documents, forming one section |
| 1816 | Entitled "History"; likewise combine any sections Entitled |
| 1817 | "Acknowledgements", and any sections Entitled "Dedications". You |
| 1818 | must delete all sections Entitled "Endorsements." |
| 1819 | |
| 1820 | 6. COLLECTIONS OF DOCUMENTS |
| 1821 | |
| 1822 | You may make a collection consisting of the Document and other |
| 1823 | documents released under this License, and replace the individual |
| 1824 | copies of this License in the various documents with a single copy |
| 1825 | that is included in the collection, provided that you follow the |
| 1826 | rules of this License for verbatim copying of each of the |
| 1827 | documents in all other respects. |
| 1828 | |
| 1829 | You may extract a single document from such a collection, and |
| 1830 | distribute it individually under this License, provided you insert |
| 1831 | a copy of this License into the extracted document, and follow |
| 1832 | this License in all other respects regarding verbatim copying of |
| 1833 | that document. |
| 1834 | |
| 1835 | 7. AGGREGATION WITH INDEPENDENT WORKS |
| 1836 | |
| 1837 | A compilation of the Document or its derivatives with other |
| 1838 | separate and independent documents or works, in or on a volume of |
| 1839 | a storage or distribution medium, is called an "aggregate" if the |
| 1840 | copyright resulting from the compilation is not used to limit the |
| 1841 | legal rights of the compilation's users beyond what the individual |
| 1842 | works permit. When the Document is included an aggregate, this |
| 1843 | License does not apply to the other works in the aggregate which |
| 1844 | are not themselves derivative works of the Document. |
| 1845 | |
| 1846 | If the Cover Text requirement of section 3 is applicable to these |
| 1847 | copies of the Document, then if the Document is less than one half |
| 1848 | of the entire aggregate, the Document's Cover Texts may be placed |
| 1849 | on covers that bracket the Document within the aggregate, or the |
| 1850 | electronic equivalent of covers if the Document is in electronic |
| 1851 | form. Otherwise they must appear on printed covers that bracket |
| 1852 | the whole aggregate. |
| 1853 | |
| 1854 | 8. TRANSLATION |
| 1855 | |
| 1856 | Translation is considered a kind of modification, so you may |
| 1857 | distribute translations of the Document under the terms of section |
| 1858 | 4. Replacing Invariant Sections with translations requires special |
| 1859 | permission from their copyright holders, but you may include |
| 1860 | translations of some or all Invariant Sections in addition to the |
| 1861 | original versions of these Invariant Sections. You may include a |
| 1862 | translation of this License, and all the license notices in the |
| 1863 | Document, and any Warrany Disclaimers, provided that you also |
| 1864 | include the original English version of this License and the |
| 1865 | original versions of those notices and disclaimers. In case of a |
| 1866 | disagreement between the translation and the original version of |
| 1867 | this License or a notice or disclaimer, the original version will |
| 1868 | prevail. |
| 1869 | |
| 1870 | If a section in the Document is Entitled "Acknowledgements", |
| 1871 | "Dedications", or "History", the requirement (section 4) to |
| 1872 | Preserve its Title (section 1) will typically require changing the |
| 1873 | actual title. |
| 1874 | |
| 1875 | 9. TERMINATION |
| 1876 | |
| 1877 | You may not copy, modify, sublicense, or distribute the Document |
| 1878 | except as expressly provided for under this License. Any other |
| 1879 | attempt to copy, modify, sublicense or distribute the Document is |
| 1880 | void, and will automatically terminate your rights under this |
| 1881 | License. However, parties who have received copies, or rights, |
| 1882 | from you under this License will not have their licenses |
| 1883 | terminated so long as such parties remain in full compliance. |
| 1884 | |
| 1885 | 10. FUTURE REVISIONS OF THIS LICENSE |
| 1886 | |
| 1887 | The Free Software Foundation may publish new, revised versions of |
| 1888 | the GNU Free Documentation License from time to time. Such new |
| 1889 | versions will be similar in spirit to the present version, but may |
| 1890 | differ in detail to address new problems or concerns. See |
| 1891 | `http://www.gnu.org/copyleft/'. |
| 1892 | |
| 1893 | Each version of the License is given a distinguishing version |
| 1894 | number. If the Document specifies that a particular numbered |
| 1895 | version of this License "or any later version" applies to it, you |
| 1896 | have the option of following the terms and conditions either of |
| 1897 | that specified version or of any later version that has been |
| 1898 | published (not as a draft) by the Free Software Foundation. If |
| 1899 | the Document does not specify a version number of this License, |
| 1900 | you may choose any version ever published (not as a draft) by the |
| 1901 | Free Software Foundation. |
| 1902 | |
| 1903 | A.2.1 ADDENDUM: How to use this License for your documents |
| 1904 | ---------------------------------------------------------- |
| 1905 | |
| 1906 | To use this License in a document you have written, include a copy of |
| 1907 | the License in the document and put the following copyright and license |
| 1908 | notices just after the title page: |
| 1909 | |
| 1910 | Copyright (C) YEAR YOUR NAME. |
| 1911 | Permission is granted to copy, distribute and/or modify this document |
| 1912 | under the terms of the GNU Free Documentation License, Version 1.2 |
| 1913 | or any later version published by the Free Software Foundation; |
| 1914 | with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. |
| 1915 | A copy of the license is included in the section entitled ``GNU |
| 1916 | Free Documentation License''. |
| 1917 | |
| 1918 | If you have Invariant Sections, Front-Cover Texts and Back-Cover |
| 1919 | Texts, replace the "with...Texts." line with this: |
| 1920 | |
| 1921 | with the Invariant Sections being LIST THEIR TITLES, with |
| 1922 | the Front-Cover Texts being LIST, and with the Back-Cover Texts |
| 1923 | being LIST. |
| 1924 | |
| 1925 | If you have Invariant Sections without Cover Texts, or some other |
| 1926 | combination of the three, merge those two alternatives to suit the |
| 1927 | situation. |
| 1928 | |
| 1929 | If your document contains nontrivial examples of program code, we |
| 1930 | recommend releasing these examples in parallel under your choice of |
| 1931 | free software license, such as the GNU General Public License, to |
| 1932 | permit their use in free software. |
| 1933 | |
| 1934 | |
| 1935 | File: ccrtp.info, Node: GNU ccRTP Linking Exception, Prev: GNU General Public License, Up: Licenses |
| 1936 | |
| 1937 | A.3 GNU ccRTP Linking Exception |
| 1938 | =============================== |
| 1939 | |
| 1940 | As a special exception to the GNU General Public License, permission is |
| 1941 | granted for additional uses of the text contained in its release of |
| 1942 | ccRTP. |
| 1943 | |
| 1944 | The exception is that, if you link the ccRTP library with other files |
| 1945 | to produce an executable, this does not by itself cause the resulting |
| 1946 | executable to be covered by the GNU General Public License. Your use |
| 1947 | of that executable is in no way restricted on account of linking the |
| 1948 | ccRTP library code into it. |
| 1949 | |
| 1950 | This exception does not however invalidate any other reasons why the |
| 1951 | executable file might be covered by the GNU General Public License. |
| 1952 | |
| 1953 | This exception applies only to the code released under the name |
| 1954 | ccRTP. If you copy code from other releases into a copy of ccRTP, as |
| 1955 | the General Public License permits, the exception does not apply to the |
| 1956 | code that you add in this way. To avoid misleading anyone as to the |
| 1957 | status of such modified files, you must delete this exception notice |
| 1958 | from them. |
| 1959 | |
| 1960 | If you write modifications of your own for ccRTP, it is your choice |
| 1961 | whether to permit this exception to apply to your modifications. If |
| 1962 | you do not wish that, delete this exception notice. |
| 1963 | |
| 1964 | |
| 1965 | File: ccrtp.info, Node: Class and Data Type Index, Next: Method and Function Index, Prev: Licenses, Up: Top |
| 1966 | |
| 1967 | Class and Data Type Index |
| 1968 | ************************* |
| 1969 | |
| 1970 | [index] |
| 1971 | * Menu: |
| 1972 | |
| 1973 | * AppDataUnit: ccRTP Overview. (line 59) |
| 1974 | * DynamicPayloadFormat <1>: Payload Types and Formats. |
| 1975 | (line 52) |
| 1976 | * DynamicPayloadFormat: ccRTP Overview. (line 59) |
| 1977 | * DynamicPayloadType: Upgrading. (line 58) |
| 1978 | * IncomingRTPPkt: RTP Packets Extensions. |
| 1979 | (line 6) |
| 1980 | * OutgoingRTPPkt: RTP Packets Extensions. |
| 1981 | (line 6) |
| 1982 | * Participant <1>: Participants. (line 6) |
| 1983 | * Participant: ccRTP Overview. (line 59) |
| 1984 | * PayloadFormat: Payload Types and Formats. |
| 1985 | (line 25) |
| 1986 | * PayloadType: Payload Types and Formats. |
| 1987 | (line 6) |
| 1988 | * RTPApplication: Participants. (line 6) |
| 1989 | * RTPPacket: RTP Packets Extensions. |
| 1990 | (line 6) |
| 1991 | * RTPSession <1>: Participants. (line 6) |
| 1992 | * RTPSession <2>: Initiating Sessions. (line 6) |
| 1993 | * RTPSession: ccRTP Overview. (line 47) |
| 1994 | * RTPSource: Upgrading. (line 31) |
| 1995 | * StaticPayloadFormat <1>: Payload Types and Formats. |
| 1996 | (line 35) |
| 1997 | * StaticPayloadFormat: ccRTP Overview. (line 59) |
| 1998 | * StaticPayloadType <1>: Upgrading. (line 58) |
| 1999 | * StaticPayloadType <2>: Payload Types and Formats. |
| 2000 | (line 6) |
| 2001 | * StaticPayloadType: ccRTP Overview. (line 59) |
| 2002 | * SyncSource <1>: Upgrading. (line 31) |
| 2003 | * SyncSource <2>: Participants. (line 6) |
| 2004 | * SyncSource: ccRTP Overview. (line 59) |
| 2005 | |
| 2006 | |
| 2007 | File: ccrtp.info, Node: Method and Function Index, Next: Concept Index, Prev: Class and Data Type Index, Up: Top |
| 2008 | |
| 2009 | Method and Function Index |
| 2010 | ************************* |
| 2011 | |
| 2012 | [index] |
| 2013 | * Menu: |
| 2014 | |
| 2015 | * ccxx_sleep: Upgrading. (line 22) |
| 2016 | * defaultApplication <1>: Upgrading. (line 40) |
| 2017 | * defaultApplication <2>: Participants. (line 73) |
| 2018 | * defaultApplication: Initiating Sessions. (line 30) |
| 2019 | * DynamicPayloadFormat::DynamicPayloadFormat: Payload Types and Formats. |
| 2020 | (line 52) |
| 2021 | * exit: Upgrading. (line 16) |
| 2022 | * getMRSenderInfo: ccRTP Overview. (line 47) |
| 2023 | * IncomingDataQueue::checkSSRCInIncomingRTPPkt: A.1. (line 6) |
| 2024 | * IncomingDataQueue::getData <1>: Upgrading. (line 43) |
| 2025 | * IncomingDataQueue::getData: Receiving Data. (line 6) |
| 2026 | * IncomingDataQueue::isWaiting: Receiving Data. (line 17) |
| 2027 | * IncomingDataQueue::onExpireRecv: RTP Packets Expiration. |
| 2028 | (line 6) |
| 2029 | * IncomingDataQueue::onNewSyncSource: Synchronization Source States. |
| 2030 | (line 6) |
| 2031 | * IncomingDataQueue::onRTPPacketRecv: RTP Packets Arrival. (line 6) |
| 2032 | * IncomingDataQueue::recordReception: A.8. (line 6) |
| 2033 | * IncomingDataQueue::takeInDataPacket: A.7. (line 35) |
| 2034 | * MembershipBookkeeping::SyncSourceLink::computeStats: A.3. (line 6) |
| 2035 | * onGotSR: ccRTP Overview. (line 47) |
| 2036 | * OutgoingDataQueue::addDestination: Initiating Sessions. (line 25) |
| 2037 | * OutgoingDataQueue::dispatchDataPacket: A.7. (line 38) |
| 2038 | * OutgoingDataQueue::onExpireSend: RTP Packets Expiration. |
| 2039 | (line 6) |
| 2040 | * OutgoingDataQueue::putData <1>: Upgrading. (line 52) |
| 2041 | * OutgoingDataQueue::putData: Sending Data. (line 6) |
| 2042 | * OutgoingDataQueue::setMark: Sending Data. (line 11) |
| 2043 | * OutgoingDataQueue::setPadding: Initiating Sessions. (line 38) |
| 2044 | * OutgoingDataQueue::setSchedulingTimeout: Upgrading. (line 47) |
| 2045 | * OutgoingDataQueueBase::getDefaultMaxSendSegmentSize: Sending Data. |
| 2046 | (line 16) |
| 2047 | * OutgoingDataQueueBase::setMaxSendSegmentSize: Sending Data. (line 16) |
| 2048 | * QueueRTCPMaanger::setControlBandwidth: Initiating Sessions. (line 45) |
| 2049 | * QueueRTCPManager::checkSSRCInRTCPPkt: A.1. (line 6) |
| 2050 | * QueueRTCPManager::dispatchBYE: A.7. (line 26) |
| 2051 | * QueueRTCPManager::dispatchControlPacket: A.7. (line 23) |
| 2052 | * QueueRTCPManager::end2EndDelayed: RTP Packets Expiration. |
| 2053 | (line 8) |
| 2054 | * QueueRTCPManager::onGotAPP: RTCP Packets Arrival. (line 15) |
| 2055 | * QueueRTCPManager::onGotGoodbye: Upgrading. (line 88) |
| 2056 | * QueueRTCPManager::onGotRR: RTCP Packets Arrival. (line 11) |
| 2057 | * QueueRTCPManager::onGotRRSRExtension: RTCP Packets Arrival. (line 17) |
| 2058 | * QueueRTCPManager::onGotSDES: A.5. (line 6) |
| 2059 | * QueueRTCPManager::onGotSDESChunk: RTCP Packets Arrival. (line 13) |
| 2060 | * QueueRTCPManager::onGotSR: RTCP Packets Arrival. (line 9) |
| 2061 | * QueueRTCPManager::onNewSyncSource: Upgrading. (line 85) |
| 2062 | * QueueRTCPManager::onSSRCCollision: SSRC Collisions. (line 6) |
| 2063 | * QueueRTCPManager::packSDES: A.4. (line 6) |
| 2064 | * RTCPCompoundHandler::checkCompountRTCPHeader: A.2. (line 6) |
| 2065 | * RTPApplication: Participants. (line 73) |
| 2066 | * RTPApplication::getSDESItem: Upgrading. (line 40) |
| 2067 | * RTPApplication::ParticipantsIterator: Participants. (line 86) |
| 2068 | * RTPApplication::setPRIVPrefix: Initiating Sessions. (line 30) |
| 2069 | * RTPPApplication::setSDESItem: Initiating Sessions. (line 30) |
| 2070 | * RTPQueue::getCNAME: Upgrading. (line 40) |
| 2071 | * RTPQueue::getCurrentRate: Upgrading. (line 79) |
| 2072 | * RTPQueue::getLocalInfo: Upgrading. (line 37) |
| 2073 | * RTPQueue::getLocalSSRC: Upgrading. (line 37) |
| 2074 | * RTPQueue::getPacket: Upgrading. (line 43) |
| 2075 | * RTPQueue::gotGoodbye: Upgrading. (line 88) |
| 2076 | * RTPQueue::gotHello: Upgrading. (line 85) |
| 2077 | * RTPQueue::putPacket: Upgrading. (line 52) |
| 2078 | * RTPQueue::setTimeout: Upgrading. (line 47) |
| 2079 | * RTPQueueBase::getCurrentRTPClockRate: Upgrading. (line 79) |
| 2080 | * RTPQueueBase::setPayloadFormat <1>: Upgrading. (line 52) |
| 2081 | * RTPQueueBase::setPayloadFormat: Initiating Sessions. (line 27) |
| 2082 | * RTPSession::enableStack: Initiating Sessions. (line 15) |
| 2083 | * RTPSession::startRunning <1>: Upgrading. (line 82) |
| 2084 | * RTPSession::startRunning: Initiating Sessions. (line 15) |
| 2085 | * RTPSession::SyncSourcesIterator: Participants. (line 46) |
| 2086 | * RTPSocket::Start: Upgrading. (line 82) |
| 2087 | * StaticPayloadFormat::StaticPayloadFormat: Payload Types and Formats. |
| 2088 | (line 41) |
| 2089 | * SyncSource::getParticipant(): Participants. (line 48) |
| 2090 | * Thread::sleep: Upgrading. (line 22) |
| 2091 | * Thread::terminate: Upgrading. (line 19) |
| 2092 | |
| 2093 | |
| 2094 | File: ccrtp.info, Node: Concept Index, Prev: Method and Function Index, Up: Top |
| 2095 | |
| 2096 | Concept Index |
| 2097 | ************* |
| 2098 | |
| 2099 | [index] |
| 2100 | * Menu: |
| 2101 | |
| 2102 | * /dev/urandom <1>: A.6. (line 6) |
| 2103 | * /dev/urandom: ccRTP Overview. (line 43) |
| 2104 | * A.1: A.1. (line 6) |
| 2105 | * A.2: A.2. (line 6) |
| 2106 | * A.3: A.3. (line 6) |
| 2107 | * A.4: A.4. (line 6) |
| 2108 | * A.5: A.5. (line 6) |
| 2109 | * A.6: A.6. (line 6) |
| 2110 | * A.7: A.7. (line 6) |
| 2111 | * A.8: A.8. (line 6) |
| 2112 | * Algoritms in the Standard: Algorithms in the Standard. |
| 2113 | (line 6) |
| 2114 | * APP: RTCP Packets Arrival. (line 15) |
| 2115 | * Audio/Video Working Group: Introduction. (line 6) |
| 2116 | * AVPF: Standards Tracking. (line 26) |
| 2117 | * C++: Introduction. (line 6) |
| 2118 | * ccRTP Internals: ccRTP Internals. (line 6) |
| 2119 | * ccRTP Overview: ccRTP Overview. (line 6) |
| 2120 | * class framework: Introduction. (line 6) |
| 2121 | * clock rate: Payload Types and Formats. |
| 2122 | (line 25) |
| 2123 | * Closing Sessions: Closing Sessions. (line 6) |
| 2124 | * CNAME <1>: Participants. (line 23) |
| 2125 | * CNAME: Initiating Sessions. (line 30) |
| 2126 | * collision: SSRC Collisions. (line 6) |
| 2127 | * Collisions and Loops: Collisions and Loops. (line 6) |
| 2128 | * Common C++: Introduction. (line 6) |
| 2129 | * const iterator: Participants. (line 46) |
| 2130 | * default bandwidth: Initiating Sessions. (line 45) |
| 2131 | * default value <1>: Participants. (line 73) |
| 2132 | * default value <2>: Sending Data. (line 11) |
| 2133 | * default value: Initiating Sessions. (line 27) |
| 2134 | * demo program: ccRTP Overview. (line 47) |
| 2135 | * destination: Upgrading. (line 68) |
| 2136 | * distribution: Distribution. (line 6) |
| 2137 | * duplicate packets: Receiving Data. (line 14) |
| 2138 | * FDL, GNU Free Documentation License: GNU Free Documentation License. |
| 2139 | (line 6) |
| 2140 | * free software: Distribution. (line 6) |
| 2141 | * Future, Future Work: Future Work. (line 6) |
| 2142 | * GNU ccRTP Linking Exception: GNU ccRTP Linking Exception. |
| 2143 | (line 6) |
| 2144 | * GNU FDL: Distribution. (line 6) |
| 2145 | * GNU GPL: Distribution. (line 6) |
| 2146 | * H.245: Payload Types and Formats. |
| 2147 | (line 25) |
| 2148 | * H.323: Introduction. (line 38) |
| 2149 | * Handling Events: Handling Events. (line 6) |
| 2150 | * header check <1>: A.2. (line 6) |
| 2151 | * header check: ccRTP Overview. (line 34) |
| 2152 | * header validity <1>: A.2. (line 6) |
| 2153 | * header validity: ccRTP Overview. (line 34) |
| 2154 | * IANA: Payload Types and Formats. |
| 2155 | (line 20) |
| 2156 | * IETF <1>: Standards Tracking. (line 6) |
| 2157 | * IETF: Introduction. (line 6) |
| 2158 | * IETF standards: Standards Tracking. (line 6) |
| 2159 | * incoming queue: Using ccRTP. (line 17) |
| 2160 | * Initiating Sessions: Initiating Sessions. (line 6) |
| 2161 | * interarrival jitter: A.8. (line 6) |
| 2162 | * Internals Overview: Internals Overview. (line 6) |
| 2163 | * Internet Ingeneering Task Force: Introduction. (line 6) |
| 2164 | * Introduction: Introduction. (line 6) |
| 2165 | * iterator: Participants. (line 46) |
| 2166 | * jitter: A.8. (line 6) |
| 2167 | * join: Initiating Sessions. (line 6) |
| 2168 | * linking exception: Distribution. (line 6) |
| 2169 | * loop detection: ccRTP Overview. (line 39) |
| 2170 | * marker bit: Sending Data. (line 11) |
| 2171 | * MD5 <1>: A.6. (line 6) |
| 2172 | * MD5 <2>: ccRTP Overview. (line 43) |
| 2173 | * MD5: Introduction. (line 19) |
| 2174 | * MIME: Payload Types and Formats. |
| 2175 | (line 25) |
| 2176 | * multicast: Initiating Sessions. (line 6) |
| 2177 | * outgoing queue: Using ccRTP. (line 24) |
| 2178 | * packet queue <1>: Using ccRTP. (line 6) |
| 2179 | * packet queue: ccRTP Overview. (line 10) |
| 2180 | * padding: Initiating Sessions. (line 38) |
| 2181 | * participant: Participants. (line 48) |
| 2182 | * Participant: Participants. (line 6) |
| 2183 | * Payload Formats: Payload Types and Formats. |
| 2184 | (line 6) |
| 2185 | * payload type: Upgrading. (line 52) |
| 2186 | * Payload Types: Payload Types and Formats. |
| 2187 | (line 6) |
| 2188 | * PCMU: Initiating Sessions. (line 27) |
| 2189 | * philosophy: Distribution. (line 6) |
| 2190 | * PRIV: Initiating Sessions. (line 30) |
| 2191 | * profile: Standards Tracking. (line 24) |
| 2192 | * Random numbers <1>: A.6. (line 6) |
| 2193 | * Random numbers: ccRTP Overview. (line 43) |
| 2194 | * Receiving Data: Receiving Data. (line 6) |
| 2195 | * reception queue: Using ccRTP. (line 17) |
| 2196 | * reconsideration: ccRTP Overview. (line 41) |
| 2197 | * redundancy: Upgrading. (line 68) |
| 2198 | * Related work: Related Work. (line 6) |
| 2199 | * reordering: Receiving Data. (line 14) |
| 2200 | * reverse reconsideration: ccRTP Overview. (line 41) |
| 2201 | * RR: RTCP Packets Arrival. (line 11) |
| 2202 | * RTCP APP: RTCP Packets Arrival. (line 15) |
| 2203 | * RTCP bandwidth: Initiating Sessions. (line 45) |
| 2204 | * RTCP compound packets: Initiating Sessions. (line 30) |
| 2205 | * RTCP header: A.2. (line 6) |
| 2206 | * RTCP Packet Arrival: RTCP Packets Arrival. (line 6) |
| 2207 | * RTCP packets: Initiating Sessions. (line 30) |
| 2208 | * RTCP Packets Extensions: RTCP Packets Extensions. |
| 2209 | (line 6) |
| 2210 | * RTCP RR: RTCP Packets Arrival. (line 11) |
| 2211 | * RTCP SDES: RTCP Packets Arrival. (line 13) |
| 2212 | * RTCP SR <1>: RTCP Packets Arrival. (line 9) |
| 2213 | * RTCP SR: ccRTP Overview. (line 47) |
| 2214 | * RTCP-based feedback: Standards Tracking. (line 26) |
| 2215 | * RTP clock rate: Payload Types and Formats. |
| 2216 | (line 25) |
| 2217 | * RTP Packet Arrival: RTP Packets Arrival. (line 6) |
| 2218 | * RTP Packets Expiration: RTP Packets Expiration. |
| 2219 | (line 6) |
| 2220 | * RTP Packets Extensions: RTP Packets Extensions. |
| 2221 | (line 6) |
| 2222 | * RTP parameters: Payload Types and Formats. |
| 2223 | (line 20) |
| 2224 | * RTP Sessions: RTP Sessions. (line 6) |
| 2225 | * RTP timestamp offset: Sending Data. (line 6) |
| 2226 | * rtphello: ccRTP Overview. (line 47) |
| 2227 | * rtplisten: ccRTP Overview. (line 47) |
| 2228 | * RTSP: Introduction. (line 38) |
| 2229 | * SAVPF: Standards Tracking. (line 30) |
| 2230 | * SDES: RTCP Packets Arrival. (line 13) |
| 2231 | * SDES item: Initiating Sessions. (line 30) |
| 2232 | * SDP: Payload Types and Formats. |
| 2233 | (line 25) |
| 2234 | * Secure RTP: Standards Tracking. (line 24) |
| 2235 | * segment size: Sending Data. (line 16) |
| 2236 | * Sending Data: Sending Data. (line 6) |
| 2237 | * Session control: Payload Types and Formats. |
| 2238 | (line 66) |
| 2239 | * Session Description Protocol: Payload Types and Formats. |
| 2240 | (line 25) |
| 2241 | * signalization: Introduction. (line 38) |
| 2242 | * Simple Receiver: Simple Receiver. (line 6) |
| 2243 | * Simple Transmitter: Simple Transmitter. (line 6) |
| 2244 | * SIP: Introduction. (line 38) |
| 2245 | * sockets: Introduction. (line 19) |
| 2246 | * Source of Synchronization: Participants. (line 6) |
| 2247 | * Specialized Payload Formats: Specialized Payload Formats. |
| 2248 | (line 6) |
| 2249 | * SR <1>: RTCP Packets Arrival. (line 9) |
| 2250 | * SR: ccRTP Overview. (line 47) |
| 2251 | * SRE Extension: RTCP Packets Arrival. (line 17) |
| 2252 | * SRTP: Standards Tracking. (line 24) |
| 2253 | * SSRC collision: SSRC Collisions. (line 6) |
| 2254 | * SSRC Collision: SSRC Collisions. (line 6) |
| 2255 | * SSRC collision: ccRTP Overview. (line 39) |
| 2256 | * Standards tracking: Standards Tracking. (line 6) |
| 2257 | * static payload type: Initiating Sessions. (line 27) |
| 2258 | * synchronization: Introduction. (line 19) |
| 2259 | * Synchronization Source States: Synchronization Source States. |
| 2260 | (line 6) |
| 2261 | * system services: Introduction. (line 19) |
| 2262 | * thread: Using ccRTP. (line 6) |
| 2263 | * threading: Introduction. (line 19) |
| 2264 | * timer reconsideration: ccRTP Overview. (line 41) |
| 2265 | * timestamp clock rate: Payload Types and Formats. |
| 2266 | (line 25) |
| 2267 | * timestamp offset: Sending Data. (line 6) |
| 2268 | * transmission queue: Using ccRTP. (line 24) |
| 2269 | * Types of Sessions: Types of Sessions. (line 6) |
| 2270 | * Upgrading: Upgrading. (line 6) |
| 2271 | * Using ccRTP: Using ccRTP. (line 6) |
| 2272 | |
| 2273 | |
| 2274 | |
| 2275 | Tag Table: |
| 2276 | Node: Top840 |
| 2277 | Node: Introduction2058 |
| 2278 | Ref: Introduction-Footnote-15455 |
| 2279 | Node: Distribution5532 |
| 2280 | Node: ccRTP Overview6807 |
| 2281 | Node: Simple Transmitter10143 |
| 2282 | Node: Simple Receiver10852 |
| 2283 | Node: Using ccRTP11842 |
| 2284 | Node: RTP Sessions14445 |
| 2285 | Node: Initiating Sessions15116 |
| 2286 | Node: Sending Data17436 |
| 2287 | Node: Receiving Data18816 |
| 2288 | Node: Closing Sessions19799 |
| 2289 | Node: Types of Sessions20591 |
| 2290 | Node: Payload Types and Formats20918 |
| 2291 | Ref: Payload Types and Formats-Footnote-124146 |
| 2292 | Node: Participants24247 |
| 2293 | Node: RTP Packets Extensions29070 |
| 2294 | Node: RTCP Packets Extensions29453 |
| 2295 | Node: Handling Events29768 |
| 2296 | Node: RTP Packets Arrival30418 |
| 2297 | Node: RTP Packets Expiration30860 |
| 2298 | Node: RTCP Packets Arrival31072 |
| 2299 | Node: Synchronization Source States31671 |
| 2300 | Node: SSRC Collisions31897 |
| 2301 | Node: Specialized Payload Formats32097 |
| 2302 | Node: Standards Tracking32366 |
| 2303 | Node: Upgrading33300 |
| 2304 | Ref: Upgrading-Footnote-136536 |
| 2305 | Ref: Upgrading-Footnote-236640 |
| 2306 | Ref: Upgrading-Footnote-336728 |
| 2307 | Node: ccRTP Internals36743 |
| 2308 | Node: Internals Overview37092 |
| 2309 | Node: Collisions and Loops37442 |
| 2310 | Node: Algorithms in the Standard38628 |
| 2311 | Node: A.139487 |
| 2312 | Node: A.240369 |
| 2313 | Node: A.340559 |
| 2314 | Node: A.440735 |
| 2315 | Node: A.540925 |
| 2316 | Node: A.641202 |
| 2317 | Node: A.741598 |
| 2318 | Node: A.842917 |
| 2319 | Node: Related Work43119 |
| 2320 | Node: Future Work43464 |
| 2321 | Node: Licenses43592 |
| 2322 | Node: GNU General Public License43960 |
| 2323 | Node: GNU Free Documentation License63225 |
| 2324 | Node: GNU ccRTP Linking Exception85652 |
| 2325 | Node: Class and Data Type Index86975 |
| 2326 | Node: Method and Function Index89452 |
| 2327 | Node: Concept Index95237 |
| 2328 | |
| 2329 | End Tag Table |
| 2330 | |
| 2331 | |
| 2332 | Local Variables: |
| 2333 | coding: iso-8859-1 |
| 2334 | End: |