Emeric Vigier | 2f62582 | 2012-08-06 11:09:52 -0400 | [diff] [blame] | 1 | \input texinfo @c -*-texinfo-*- |
| 2 | @c %** start of header |
| 3 | @setfilename ccrtp.info |
| 4 | @settitle GNU ccRTP Manual |
| 5 | @afourpaper |
| 6 | @setchapternewpage odd |
| 7 | @documentlanguage en |
| 8 | @documentencoding ISO-8859-1 |
| 9 | @c %** end of header |
| 10 | |
| 11 | @set EDITION 1.3 |
| 12 | @set VERSION 1.3 |
| 13 | @set UPDATED Jan 2006 |
| 14 | |
| 15 | @dircategory Development |
| 16 | @direntry |
| 17 | * GNU ccRTP: (ccrtp). GNU ccRTP Real-Time Transport Protocol Framework. |
| 18 | @end direntry |
| 19 | |
| 20 | |
| 21 | @c ----------------------------------------------------------------------- |
| 22 | |
| 23 | @c %** start of summary description and copyright |
| 24 | @ifnottex |
| 25 | GNU ccRTP is a C++ class framework for the development of Real Time |
| 26 | Transport Protocol (@acronym{RTP}) based applications. It is based on |
| 27 | GNU Common C++. |
| 28 | |
| 29 | Copyright @copyright{} 2001, 2002, 2003, 2004, 2005, 2006 Federico Montesino Pouzols |
| 30 | @email{fedemp@@altern.org}. |
| 31 | @include fdlnotice.texi |
| 32 | @end ifnottex |
| 33 | @c %** end of summary description and copyright |
| 34 | |
| 35 | @c ----------------------------------------------------------------------- |
| 36 | |
| 37 | @c %** start of title and copyright page |
| 38 | @shorttitlepage @titlefont{GNU ccRTP} |
| 39 | @titlepage |
| 40 | @sp 10 |
| 41 | @title GNU ccRTP Manual |
| 42 | @subtitle A Real-Time Transport Protocol Framework based on GNU Common C++ |
| 43 | @subtitle @value{EDITION}th Edition, covering ccRTP version @value{VERSION} |
| 44 | @subtitle @value{UPDATED} |
| 45 | @author Federico Montesino Pouzols |
| 46 | |
| 47 | @page |
| 48 | @vskip 0pt plus 1filll |
| 49 | @center{Copyright @copyright{} 2001, 2002, 2003, 2004, 2005 Federico Montesino Pouzols} |
| 50 | @include fdlnotice.texi |
| 51 | @page |
| 52 | @end titlepage |
| 53 | @c %** end of title and copyright page |
| 54 | |
| 55 | |
| 56 | @c ----------------------------------------------------------------------- |
| 57 | |
| 58 | @c %** start of top node and master menu |
| 59 | @ifnottex |
| 60 | @node Top |
| 61 | @top |
| 62 | This manual describes GNU ccRTP, a C++ class framework for the |
| 63 | development of Real Time Transport Protocol (@acronym{RTP}) based |
| 64 | applications. |
| 65 | |
| 66 | This is the edition @value{EDITION} of this manual and documents |
| 67 | GNU ccRTP version @value{VERSION}. |
| 68 | @end ifnottex |
| 69 | |
| 70 | |
| 71 | @contents |
| 72 | |
| 73 | |
| 74 | @menu |
| 75 | * Introduction:: What @acronym{RTP} and ccRTP are. |
| 76 | * Distribution:: How to get @acronym{GNU} ccRTP. |
| 77 | * ccRTP Overview:: The library at a glance. |
| 78 | * Using ccRTP:: Programming with GNU ccRTP overview. |
| 79 | * Specialized Payload Formats:: Supported payload specific extensions. |
| 80 | * Standards Tracking:: @acronym{IETF} Standards conformance. |
| 81 | * Upgrading:: Upgrading applications based on old releases. |
| 82 | * ccRTP Internals:: How @acronym{GNU} ccRTP is done. |
| 83 | * Related Work:: Other @acronym{RTP} related libraries and tools. |
| 84 | * Future Work:: Future of @acronym{RTP} and ccRTP. |
| 85 | * Licenses:: Library and documentation licenses. |
| 86 | * Class and Data Type Index:: Index of classes and data types in ccRTP. |
| 87 | * Method and Function Index:: Index of methods and functions in ccRTP. |
| 88 | * Concept Index:: Index of concepts. |
| 89 | @end menu |
| 90 | @c %** end of top node and master menu |
| 91 | |
| 92 | @c %** start of body |
| 93 | |
| 94 | @c ----------------------------------------------------------------------- |
| 95 | @node Introduction |
| 96 | @chapter Introduction |
| 97 | @cindex Introduction |
| 98 | |
| 99 | @cindex Common C++ |
| 100 | @cindex C++ |
| 101 | @cindex IETF |
| 102 | @cindex Internet Ingeneering Task Force |
| 103 | @cindex Audio/Video Working Group |
| 104 | @cindex class framework |
| 105 | ccRTP is a C++ framework for developing applications based on the Real |
| 106 | Time Transport Protocol (@acronym{RTP} henceforth). @acronym{RTP} |
| 107 | provides end-to-end delivery services for data with real-time |
| 108 | characteristics and is being developed by the Audio/Video Working |
| 109 | Group of the Internet Engineering Task Force (@acronym{IETF}). |
| 110 | |
| 111 | ccRTP aims to be an efficient and flexible framework valid for almost |
| 112 | any kind of application that uses @acronym{RTP}, ranging from high |
| 113 | loaded servers and gateways to personal phone applications. Default |
| 114 | constructs and values are provided however for the most common choices |
| 115 | in the use of @acronym{RTP}. ccRTP conforms to the latest |
| 116 | @acronym{RTP} specifications (@pxref{Standards Tracking}). |
| 117 | |
| 118 | @cindex MD5 |
| 119 | @cindex Common C++ |
| 120 | @cindex system services |
| 121 | @cindex threading |
| 122 | @cindex synchronization |
| 123 | @cindex sockets |
| 124 | ccRTP is based on the @acronym{GNU} Common C++ framework, though most |
| 125 | of the library does not require it. Common C++ provides basic system |
| 126 | services such as threading, synchronization and sockets@footnote{As |
| 127 | well as other more specialized services, such as MD5 computation.}, |
| 128 | which makes it possible to provide a complete solution for the use of |
| 129 | @acronym{RTP}. However, although ccRTP provides facilities and |
| 130 | abstractions useful for the @acronym{RTP} specific components of |
| 131 | applications that use @acronym{RTP}, such applications generally |
| 132 | require similar system services for other tasks. Besides supporting |
| 133 | ccRTP, Common C++ provides a portable and efficient framework for |
| 134 | these kind of services. |
| 135 | |
| 136 | @acronym{RTP} has been defined as an application level protocol |
| 137 | framework rather than a typical Internet transport protocol such as |
| 138 | TCP and UDP. Thus, @acronym{RTP} is hardly ever implemented as a layer |
| 139 | separated from the application. Consequently, @acronym{RTP} |
| 140 | applications often must customize the adaptable @acronym{RTP} packet |
| 141 | layout and processing rules, timing constraints, session membership |
| 142 | rules as well as other @acronym{RTP} and @acronym{RTCP} |
| 143 | mechanisms. ccRTP aims to provide a framework for the @acronym{RTP} |
| 144 | framework, rather than being just an @acronym{RTP} packet manipulation |
| 145 | library. |
| 146 | |
| 147 | @cindex signalization |
| 148 | @cindex RTSP |
| 149 | @cindex SIP |
| 150 | @cindex H.323 |
| 151 | As a clarification of the scope of the ccRTP library and the |
| 152 | @acronym{RTP} protocol, we note that ccRTP exclusively deals with the |
| 153 | transport of data over the @acronym{RTP} protocol. Once parameters such |
| 154 | as destination IP address and transport port, payload type identifier |
| 155 | and timestamp frequency are known, ccRTP can be used to open an |
| 156 | @acronym{RTP} session and send and receive RTP and RTCP packets. A |
| 157 | multimedia application will have those parameters previously set or, |
| 158 | more usually, they can be fetched for example from SDP multimedia |
| 159 | session descriptions, which can be interchanged (and negotiated) between |
| 160 | servers and clients by means of some signaling protocol: @acronym{SIP}, |
| 161 | @acronym{RTSP}, or even H.323. Signaling functions are not handled by |
| 162 | ccRTP. |
| 163 | |
| 164 | This document is an introductory programmer's manual, for a more |
| 165 | exhaustive reference see the reference manual distributed with GNU |
| 166 | ccRTP. In @ref{ccRTP Overview}, the most important concepts and some |
| 167 | basic examples are introduced. A deeper and step by step description |
| 168 | as well as short examples are provided in @ref{Using ccRTP}. |
| 169 | |
| 170 | Finally, if after reading this document and/or using ccRTP you think |
| 171 | it fails to provide some functionality that seems to be needed for |
| 172 | some application, we encourage you to contact the developers of ccRTP |
| 173 | and ask or propose them improvements and/or additions. You are also |
| 174 | encouraged to provide these improvements and to join the development |
| 175 | team. Bug reports, suggestions and criticisms are gladly accepted. |
| 176 | |
| 177 | |
| 178 | @c ----------------------------------------------------------------------- |
| 179 | @node Distribution |
| 180 | @chapter Distribution |
| 181 | @cindex distribution |
| 182 | |
| 183 | @cindex free software |
| 184 | @cindex GNU GPL |
| 185 | @cindex linking exception |
| 186 | @cindex GNU FDL |
| 187 | @cindex philosophy |
| 188 | @acronym{GNU} ccRTP is free software (see |
| 189 | @url{http://www.gnu.org/philosophy/philosophy.html}. It is licensed |
| 190 | under the terms of the @acronym{GNU} General Public License, @xref{GNU |
| 191 | General Public License}, plus a linking exception, @xref{GNU ccRTP |
| 192 | Linking Exception}. |
| 193 | |
| 194 | The linking exception is the same that is used for gcc libstdc++. This |
| 195 | was done in the case of libstdc++ because the language of the LGPL is |
| 196 | neither clear nor correct if one uses C++ features such as templates and |
| 197 | method implimentation directly in headers, as the division between the |
| 198 | C++ library and another's application is no longer purely a linking one. |
| 199 | From the practical standpoint, the exact effect is the same as the LGPL, |
| 200 | but with language that matches these C++ features. This is all |
| 201 | explained at |
| 202 | @url{http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html}. |
| 203 | |
| 204 | This manual is licensed under the terms of the @acronym{GNU} Free |
| 205 | Documentation License, @xref{GNU Free Documentation License}. |
| 206 | |
| 207 | There are several ways to get @acronym{GNU} ccRTP, refer to |
| 208 | @url{http://www.gnu.org} and |
| 209 | @url{http://www.gnu.org/software/ccrtp/}. The development of ccRTP is |
| 210 | hosted at Savannah @url{http://sv.gnu.org/projects/ccrtp/}. |
| 211 | |
| 212 | |
| 213 | @c ----------------------------------------------------------------------- |
| 214 | @node ccRTP Overview |
| 215 | @chapter ccRTP Overview |
| 216 | @cindex ccRTP Overview |
| 217 | |
| 218 | At its highest level, ccRTP provides classes for the real-time |
| 219 | transport of data through @acronym{RTP} sessions, as well as the |
| 220 | control functions of @acronym{RTCP}. |
| 221 | |
| 222 | @cindex packet queue |
| 223 | The main concept in the ccRTP implementation of @acronym{RTP} sessions |
| 224 | is the use of packet queues to handle transmission and reception of |
| 225 | @acronym{RTP} data packets/application data units. In ccRTP, a data |
| 226 | block is transmitted by putting it into the transmission (outgoing |
| 227 | packets) queue, and received by getting it from the reception |
| 228 | (incoming packets) queue. |
| 229 | |
| 230 | Starting with 1.0 releases, ccRTP fully supports @acronym{RTP} and |
| 231 | @acronym{RTCP}. Here is a brief list of some features of ccRTP: |
| 232 | |
| 233 | @itemize |
| 234 | |
| 235 | @item Highly extensible to specialized stacks. |
| 236 | |
| 237 | @item Supports unicast, multi-unicast and multicast. Handles multiple sources (including synchronization sources and contributing sources) and destinations. Also supports symmetric RTP. |
| 238 | |
| 239 | @item Automatic RTCP functions handling, such as association of synchronization sources from the same participant or NTP-RTP timestamp mapping. |
| 240 | |
| 241 | @item Genericity as for underlying network and transport protocols through templates. |
| 242 | |
| 243 | @item It is threadsafe and supports almost any threading model. |
| 244 | |
| 245 | @cindex header check |
| 246 | @cindex header validity |
| 247 | @item Generic and extensible @acronym{RTP} and @acronym{RTCP} header validity checks. |
| 248 | |
| 249 | @item Handles source states and information as well as statistics recording. |
| 250 | |
| 251 | @cindex SSRC collision |
| 252 | @cindex loop detection |
| 253 | @item Automatically handles SSRC collisions and performs loop detection. |
| 254 | |
| 255 | @cindex reconsideration |
| 256 | @cindex timer reconsideration |
| 257 | @cindex reverse reconsideration |
| 258 | @item Implements timer reconsideration and reverse reconsideration. |
| 259 | |
| 260 | @cindex Random numbers |
| 261 | @cindex /dev/urandom |
| 262 | @cindex MD5 |
| 263 | @item Provides good random numbers, based on @file{/dev/urandom} or, alternatively, on MD5. |
| 264 | |
| 265 | @end itemize |
| 266 | |
| 267 | @cindex demo program |
| 268 | @cindex rtphello |
| 269 | @cindex rtplisten |
| 270 | @tindex RTPSession |
| 271 | @findex onGotSR |
| 272 | @findex getMRSenderInfo |
| 273 | @cindex SR |
| 274 | @cindex RTCP SR |
| 275 | There are several levels of interface (public interface, public or |
| 276 | protected inheritance, etc) in ccRTP. For instance, the |
| 277 | @code{rtphello} demo program distributed with ccRTP just uses the |
| 278 | public interface of the @code{RTPSession} class and does not redefine |
| 279 | the virtual method @code{onGotSR}, thus what this program knows about |
| 280 | SR reports is the information conveyed in the last sender report from |
| 281 | any source, which can be retrieved via the @code{getMRSenderInfo} |
| 282 | method of the @code{SyncSource} class. On the contrary, the |
| 283 | @code{rtplisten} demo program redefines @code{onGotSR} by means of |
| 284 | inheritance and could do specialized processing of these RTCP |
| 285 | packets. Generally, both data and control packets are not directly |
| 286 | accessible through the most external interface. |
| 287 | |
| 288 | @tindex StaticPayloadType |
| 289 | @tindex StaticPayloadFormat |
| 290 | @tindex DynamicPayloadFormat |
| 291 | @tindex RTPSession |
| 292 | @tindex AppDataUnit |
| 293 | @tindex SyncSource |
| 294 | @tindex Participant |
| 295 | @tindex AppDataUnit |
| 296 | All these functions are performed through a few essential classes and |
| 297 | types. The most basic ones are the enumerated type |
| 298 | @code{StaticPayloadType}, and the classes @code{StaticPayloadFormat} and |
| 299 | @code{DynamicPayloadFormat}. The most important ones are the classes |
| 300 | @code{RTPSession}, @code{SyncSource}, @code{Participant} and |
| 301 | @code{AppDataUnit}, that represent @acronym{RTP} sessions, |
| 302 | synchronization sources, participants in an @acronym{RTP} application, |
| 303 | and application data units conveyed in @acronym{RTP} data packets, |
| 304 | respectively. |
| 305 | |
| 306 | @cindex demo program |
| 307 | In the next sections, two basic examples are presented. These examples |
| 308 | are intended to provide a concrete idea of what the code of a ccRTP |
| 309 | based application looks like, they are not complete or compilable |
| 310 | programs. You can find some real examples under the demo directory in |
| 311 | the source distribution of ccRTP. |
| 312 | |
| 313 | @menu |
| 314 | * Simple Transmitter:: Skeleton of a simple transmitter. |
| 315 | * Simple Receiver:: Skeleton of a simple receiver. |
| 316 | @end menu |
| 317 | |
| 318 | |
| 319 | @c ----------------------------------------------------------------------- |
| 320 | @node Simple Transmitter |
| 321 | @section Simple Transmitter |
| 322 | @cindex Simple Transmitter |
| 323 | |
| 324 | The following snippet illustrates the required steps to send an |
| 325 | application data unit over @acronym{RTP}. |
| 326 | |
| 327 | @cartouche |
| 328 | @example |
| 329 | RTPSession s(InetHostAddress("127.0.0.1"),8000); // @r{bind reception socket} |
| 330 | |
| 331 | // @r{Initialization} |
| 332 | cout << "Local SSRC identifier: " << s.getLocalSSRC() << endl; |
| 333 | s.addDestination("www.example.com",9000); // @r{set one destination for packets} |
| 334 | s.setPayloadFormat(staticPayloadFormat(sptPCMU)); |
| 335 | s.startRunning(); // @r{start running the packet queue scheduler} |
| 336 | |
| 337 | // @r{Send data} |
| 338 | s.putData(0,buffer,bufferLen); // @r{buffer holds bufferLen payload octets} |
| 339 | @end example |
| 340 | @end cartouche |
| 341 | |
| 342 | |
| 343 | @c ----------------------------------------------------------------------- |
| 344 | @node Simple Receiver |
| 345 | @section Simple Receiver |
| 346 | @cindex Simple Receiver |
| 347 | |
| 348 | The required actions to receive an application data unit over RTP are |
| 349 | listed in the following code snippet. |
| 350 | |
| 351 | @cartouche |
| 352 | @example |
| 353 | RTPSession s(InetHostAddress("127.0.0.1"),9000); // @r{bind reception socket.} |
| 354 | |
| 355 | // @r{Initialization.} |
| 356 | cout << "Local SSRC identifier: " << s.getLocalSSRC() << endl; |
| 357 | s.setPayloadFormat(staticPayloadFormat(sptPCMU)); |
| 358 | s.startRunning(); // @r{start running the packet queue scheduler.} |
| 359 | |
| 360 | // @r{Receive data.} |
| 361 | const AppDataUnit* adu; |
| 362 | adu = s.getData(0); // @r{get data with initial -0- timestamp.} |
| 363 | if ( adu != NULL ) |
| 364 | // @r{do something with adu.} |
| 365 | // adu->getType() @r{provides the payload type.} |
| 366 | // adu->getData() @r{provides a const uint8 pointer to a data buffer.} |
| 367 | // adu->getSize() @r{provides the number of octets in the buffer.} |
| 368 | // @r{see other methods in the class AppDataUnit, such as} getSource(). |
| 369 | @end example |
| 370 | @end cartouche |
| 371 | |
| 372 | |
| 373 | @c ----------------------------------------------------------------------- |
| 374 | @node Using ccRTP |
| 375 | @chapter Using ccRTP |
| 376 | @cindex Using ccRTP |
| 377 | |
| 378 | @cindex packet queue |
| 379 | @cindex thread |
| 380 | When using ccRTP, both sending and receiving of data transported over |
| 381 | @acronym{RTP} sessions is done through reception and transmission |
| 382 | queues handled by the @acronym{RTP} stack. In the most common case, a |
| 383 | separate execution thread for each @acronym{RTP} session handles the |
| 384 | queues. This case is the threading model that we will generally assume |
| 385 | throughout this document. Note however that ccRTP supports other |
| 386 | threading models, particularly ccRTP supports the use of a single |
| 387 | execution thread to serve a set of @acronym{RTP} sessions. It is also |
| 388 | possible to not associate any separate thread with any @acronym{RTP} |
| 389 | session, manually calling the main data and control service methods |
| 390 | from whatever other thread. |
| 391 | |
| 392 | @cindex reception queue |
| 393 | @cindex incoming queue |
| 394 | The basic idea for packet reception with ccRTP is that the application |
| 395 | does not directly read packets from sockets but gets them from a |
| 396 | reception queue. The stack is responsible for inserting received |
| 397 | packets in the reception queue and handling this queue. In general, a |
| 398 | packet reception and insertion in the reception queue does not occur |
| 399 | at the same time the application gets it from the queue. |
| 400 | |
| 401 | @cindex transmission queue |
| 402 | @cindex outgoing queue |
| 403 | Conversely, the basic idea for packet transmission with ccRTP is that |
| 404 | packets are not directly written to sockets but inserted in a |
| 405 | transmission queue handled by the stack. In general, packet insertion |
| 406 | and transmission occur at different times, though it is not necessary. |
| 407 | |
| 408 | In order to use ccRTP, you must include the main header |
| 409 | (@file{#include <ccrtp/rtp.h>}. Two additional headers are provided by |
| 410 | ccRTP: |
| 411 | |
| 412 | @table @code |
| 413 | |
| 414 | @item @file{#include <ccrtp/rtppool.h} |
| 415 | Classes for pools of RTP service threads. |
| 416 | |
| 417 | @item @file{#include <ccrtp/rtpext.h>} |
| 418 | Classes for RTP extensions which are not mature yet. |
| 419 | |
| 420 | @end table |
| 421 | |
| 422 | You must also link in the library, currently @file{ccrtp1}. |
| 423 | |
| 424 | As presented in the last examples, before starting to send or receive |
| 425 | data, RTP sessions must be created, the payload format to use must be |
| 426 | set and the stack must be signaled to start running. The following |
| 427 | sections describe the use of ccRTP during the different phases of RTP |
| 428 | sessions and RTP applications in general. |
| 429 | |
| 430 | @menu |
| 431 | * RTP Sessions:: Using ccRTP to establish @acronym{RTP} sessions. |
| 432 | * Payload Types and Formats:: Payload types and formats. |
| 433 | * Participants:: Participants and sources of synchronization. |
| 434 | * RTP Packets Extensions:: Extensions to @acronym{RTP} data packets handling. |
| 435 | * RTCP Packets Extensions:: Extensions to @acronym{RTCP} packets handling. |
| 436 | * Handling Events:: Table of ccRTP plug-ins to react to events. |
| 437 | @end menu |
| 438 | |
| 439 | |
| 440 | @c ----------------------------------------------------------------------- |
| 441 | @node RTP Sessions |
| 442 | @section RTP Sessions |
| 443 | @cindex RTP Sessions |
| 444 | |
| 445 | This section discusses the use of @code{RTPSession} objects. Some |
| 446 | other classes and concepts are also used, these are just briefly |
| 447 | presented here; deeper explanations are provided in next sections. |
| 448 | |
| 449 | @menu |
| 450 | * Initiating Sessions:: @acronym{RTP} sessions initialization with ccRTP. |
| 451 | * Sending Data:: Sending @acronym{RTP} data packets. |
| 452 | * Receiving Data:: Receiving @acronym{RTP} data packets. |
| 453 | * Closing Sessions:: Extensions to @acronym{RTP} data packets handling. |
| 454 | * Types of Sessions:: Choosing a threading and socket model. |
| 455 | @end menu |
| 456 | |
| 457 | |
| 458 | @c ----------------------------------------------------------------------- |
| 459 | @node Initiating Sessions |
| 460 | @subsection Initiating Sessions |
| 461 | @cindex Initiating Sessions |
| 462 | |
| 463 | @tindex RTPSession |
| 464 | @cindex multicast |
| 465 | @cindex join |
| 466 | Initiating @acronym{RTP} sessions with ccRTP involves the construction |
| 467 | of an object of the class @code{RTPSession} and calling some optional |
| 468 | initialization methods. @code{RTPSession} constructors take two |
| 469 | mandatory arguments: local network address and local transport port |
| 470 | (where incoming packets are expected). There are two constructors, one |
| 471 | of them takes a host address as first parameter, while the other takes |
| 472 | a multicast address. In the latter case, the application will join to |
| 473 | a multicast group. |
| 474 | |
| 475 | @findex RTPSession::startRunning |
| 476 | @findex RTPSession::enableStack |
| 477 | General purpose @acronym{RTP} stacks of ccRTP, such as |
| 478 | @code{RTPSession} objects, must be signaled to start execution. This |
| 479 | is done calling the @code{startRunning()} method. Note there is also a |
| 480 | @code{enableStack()} method, this only activates the stack but does not |
| 481 | start the execution of the stack thread. |
| 482 | |
| 483 | After the steps above, the application can receive data, but will not |
| 484 | transmit to any destination. This and other session parameters can be |
| 485 | set as follows: |
| 486 | |
| 487 | @itemize |
| 488 | |
| 489 | @findex OutgoingDataQueue::addDestination |
| 490 | @item Add destinations: calling the method @code{addDestination}. |
| 491 | |
| 492 | @findex RTPQueueBase::setPayloadFormat |
| 493 | @cindex static payload type |
| 494 | @cindex PCMU |
| 495 | @cindex default value |
| 496 | @item Set payload format. Method @code{setPayloadFormat}. By default, the static payload type 0 is assumed (PCMU format at 8Khz). |
| 497 | |
| 498 | @cindex RTCP packets |
| 499 | @cindex RTCP compound packets |
| 500 | @cindex SDES item |
| 501 | @cindex CNAME |
| 502 | @cindex default value |
| 503 | @cindex PRIV |
| 504 | @findex RTPPApplication::setSDESItem |
| 505 | @findex RTPApplication::setPRIVPrefix |
| 506 | @findex defaultApplication |
| 507 | @item Set local SDES Items. For common applications, the CNAME item value is automatically guessed as user@@host. Other items have no default value and are not sent in RTCP packets unless a value is specified by the application. For those items that should be sent in @acronym{RTCP} packets along with the mandatory CNAME, its values can be set calling the @code{setSDESItem} and @code{setPRIVPrefix} methods over the object returned by the @code{defaultApplication} global function. |
| 508 | |
| 509 | @findex OutgoingDataQueue::setPadding |
| 510 | @cindex padding |
| 511 | @item Enable padding of data packets. Calling setPadding(uint8) on outgoing data queues enables transparent padding of data packets to a multiple of the padding maximum length specified. By default, padding is off (maximum length of padding is 0). |
| 512 | |
| 513 | @item setting addresses: |
| 514 | |
| 515 | |
| 516 | @findex QueueRTCPMaanger::setControlBandwidth |
| 517 | @cindex default value |
| 518 | @cindex default bandwidth |
| 519 | @cindex RTCP bandwidth |
| 520 | @item Set session bandwidth calling the @code{setSessionBandwidth} method of the session object. If not called, a default bandwidth of 64Kbps is assumed, and 5% of this bandwidth is used for RTCP. This percentage can be changed through the setControlBandwidth method. |
| 521 | |
| 522 | @end itemize |
| 523 | |
| 524 | |
| 525 | @c ----------------------------------------------------------------------- |
| 526 | @node Sending Data |
| 527 | @subsection Sending Data |
| 528 | @cindex Sending Data |
| 529 | |
| 530 | @findex OutgoingDataQueue::putData |
| 531 | @cindex RTP timestamp offset |
| 532 | @cindex timestamp offset |
| 533 | Data packets are sent through the method @code{putData}, that takes as |
| 534 | first parameter the RTP timestamp for the data specified as second |
| 535 | parameter. ccRTP handles the random offset for the RTP timestamp |
| 536 | internally, so the timestamp value that corresponds to the session |
| 537 | creation time is 0. |
| 538 | |
| 539 | @findex OutgoingDataQueue::setMark |
| 540 | @cindex default value |
| 541 | @cindex marker bit |
| 542 | By default, the marker bit of the sent packets is not set. Its value |
| 543 | for the next packet (the one that will convey the data provided in the |
| 544 | next call to @code{putData}) can be set through the @code{setMark} |
| 545 | method, which takes a boolean as argument. |
| 546 | |
| 547 | @findex OutgoingDataQueueBase::setMaxSendSegmentSize |
| 548 | @findex OutgoingDataQueueBase::getDefaultMaxSendSegmentSize |
| 549 | @cindex default value |
| 550 | @cindex segment size |
| 551 | ccRTP also supports fragmenting data blocks into several RTP |
| 552 | packets. The @code{setMaxSendSegmentSize} method can be used to |
| 553 | request that no @acronym{RTP} packet be transmitted with a payload |
| 554 | length greater than the value specified through |
| 555 | @code{setMaxSendSegmentSize}. The default value of this parameter can |
| 556 | be retrieved via @code{getDefaultMaxSendSegmentSize}, which currently |
| 557 | should return 65536. When data blocks greater than the maximum segment |
| 558 | size are provided through @code{putData}, two or more packet will be |
| 559 | inserted in the outgoing packet queue. All these packets but the last |
| 560 | one will have length equal to the maximum segment size, whereas the |
| 561 | last one's size will be lower or equal to the maximum segment size. |
| 562 | |
| 563 | |
| 564 | @c ----------------------------------------------------------------------- |
| 565 | @node Receiving Data |
| 566 | @subsection Receiving Data |
| 567 | @cindex Receiving Data |
| 568 | |
| 569 | @findex IncomingDataQueue::getData |
| 570 | Received data is retrieved from the incoming packet queue through the |
| 571 | @code{getData} method, which, given a timestamp and an optional source |
| 572 | of synchronization. This method returns a pointer to an |
| 573 | @code{AppDataUnit} object as opposed to a pointer to a memory |
| 574 | block. In ccRTP application data units are represented through objects |
| 575 | of the @code{AppDataUnit} class, that provides access to the |
| 576 | synchronization source of the data and other related properties. |
| 577 | |
| 578 | @cindex duplicate packets |
| 579 | @cindex reordering |
| 580 | The incoming packet queue takes care of functions such as packet |
| 581 | reordering or filtering out duplicate packets. |
| 582 | |
| 583 | @findex IncomingDataQueue::isWaiting |
| 584 | You can guess if there are packets in the reception queue calling |
| 585 | @code{isWaiting}. Both @code{getData} and @code{isWaiting} take an |
| 586 | optional parameter which selects a particular synchronization source |
| 587 | of data units. If not specified, data units are returned regardless of |
| 588 | its source. |
| 589 | |
| 590 | |
| 591 | @c ----------------------------------------------------------------------- |
| 592 | @node Closing Sessions |
| 593 | @subsection Closing Sessions |
| 594 | @cindex Closing Sessions |
| 595 | |
| 596 | RTP sessions can be closed deleting or destroying @code{RTPSession} |
| 597 | objects. The stack sends a BYE packet to every destination when the |
| 598 | destructor of sessions is called. It is also possible to explicitly send |
| 599 | a BYE packet through the dispatchBYE method, which takes the leaving |
| 600 | reason string as argument. Note that dispatchBYE will honor a number of |
| 601 | rules for sending BYE packets specified in the RTP standard: a BYE |
| 602 | packet is not sent if no RTP/RTCP packet was sent, and BYE floods |
| 603 | avoiding mechanisms are employed. |
| 604 | |
| 605 | Note that when a BYE RTCP packet is received from a remote |
| 606 | participant, the virtual @code{onGotGoodbye} will be called. |
| 607 | |
| 608 | @c ----------------------------------------------------------------------- |
| 609 | @node Types of Sessions |
| 610 | @subsection Types of Sessions |
| 611 | @cindex Types of Sessions |
| 612 | |
| 613 | @emph{TODO:} explain how to instantiate templates depending on the |
| 614 | threading model and the number of sockets to use. Also symmetric |
| 615 | channels/sessions. Describe what's a channel and a session. |
| 616 | |
| 617 | |
| 618 | @c ----------------------------------------------------------------------- |
| 619 | @node Payload Types and Formats |
| 620 | @section Payload Types and Formats |
| 621 | @cindex Payload Types |
| 622 | @cindex Payload Formats |
| 623 | |
| 624 | @tindex PayloadType |
| 625 | @tindex StaticPayloadType |
| 626 | In the context of @acronym{RTP}, an @acronym{RTP} payload type is a |
| 627 | 7-bit numeric identifier that identifies a payload format. For |
| 628 | payload types, GNU ccRTP defines the integer type |
| 629 | @code{PayloadType}. ccRTP also defines The enumerated type |
| 630 | @code{StaticPayloadType}, as the enumeration of the @acronym{RTP} |
| 631 | Payload Types statically assigned for standard audio and video |
| 632 | formats. |
| 633 | |
| 634 | These codes were initially specified in @cite{RFC 1890, ``RTP Profile |
| 635 | for Audio and Video Conferences with Minimal Control'' (AVP profile)}, |
| 636 | superseded by @cite{RFC 3550}, and are registered as MIME types in |
| 637 | @cite{RFC 3555}. Codes below 96 may be assigned statically, although |
| 638 | the default bindings for many of them are already reserverd. Codes in |
| 639 | the range 96-127 are assigned dinamically by means outside of the |
| 640 | @acronym{RTP} profile or protocol specification. |
| 641 | |
| 642 | @cindex IANA |
| 643 | @cindex RTP parameters |
| 644 | See the ``RTP Parameters'' list at @acronym{IANA} |
| 645 | @url{http://www.iana.org/assignments/rtp-parameters}. Note however |
| 646 | that registering static payload types is now considered a deprecated |
| 647 | practice in favor of dynamic payload type negotiation. |
| 648 | |
| 649 | @tindex PayloadFormat |
| 650 | |
| 651 | @cindex MIME |
| 652 | @cindex SDP |
| 653 | @cindex Session Description Protocol |
| 654 | @cindex H.245 |
| 655 | @cindex clock rate |
| 656 | @cindex timestamp clock rate |
| 657 | @cindex RTP clock rate |
| 658 | The properties of a payload format that, as an @acronym{RTP} stack, |
| 659 | ccRTP takes into account are the payload type (numeric identifier) and |
| 660 | the @acronym{RTP} clock rate. Other properties, such as @acronym{MIME} |
| 661 | type, number of audio channels, ``ptime'' and ``maxptime'' are not |
| 662 | considered. These are only of interest for higher level protocols, |
| 663 | such as @acronym{SDP} and H.245. |
| 664 | |
| 665 | GNU ccRTP defines a hierarchy of payload format classes. Its root is |
| 666 | @code{PayloadFormat}, which is a base class for |
| 667 | @code{StaticPayloadFormat} and @code{DynamicPayloadFormat}. |
| 668 | |
| 669 | @tindex StaticPayloadFormat |
| 670 | @tindex StaticPayloadType |
| 671 | Static payload format objects are built from a static payload |
| 672 | code. These are defined in the enumerated type |
| 673 | @code{StaticPayloadType}. The following example constructs a |
| 674 | @code{StaticPayloadFormat} object corresponding to the payload type 0 |
| 675 | (statically bounded to PCMA in @cite{RFC 3551}): |
| 676 | |
| 677 | @findex StaticPayloadFormat::StaticPayloadFormat |
| 678 | @example |
| 679 | StaticPayloadType pt = sptPCMU; |
| 680 | StaticPayloadFormat* spf = new StaticPayloadFormat(pt); |
| 681 | @end example |
| 682 | |
| 683 | Of course, we could have said: |
| 684 | |
| 685 | @example |
| 686 | StaticPayloadFormat* spf = new StaticPayloadFormat(sptPCMA); |
| 687 | @end example |
| 688 | |
| 689 | StaticPayloadFormat objects build like the ones above hold the |
| 690 | necessary parameters so that the @acronym{RTP} stack can handle |
| 691 | incoming and outgoing packets. |
| 692 | |
| 693 | @tindex DynamicPayloadFormat |
| 694 | @findex DynamicPayloadFormat::DynamicPayloadFormat |
| 695 | Regarding dynamic payload formats, a call to |
| 696 | @code{DynamicPayloadFormat::DynamicPayloadFormat(100,90000)} like the |
| 697 | following: |
| 698 | |
| 699 | @example |
| 700 | DynamicPayloadFormat* dpf = new DynamicPayloadFormat(100,90000); |
| 701 | @end example |
| 702 | |
| 703 | Will construct a dynamic payload format object that ties together the |
| 704 | '100' payload type numeric identifier and an @acronym{RTP} clock rate |
| 705 | of 90 Khz. Note that the numeric identifier does not have to be in the |
| 706 | dynamic range. The static payload types are default bindings and MAY |
| 707 | be overriden, thus, DynamicPayloadFormat(0,90000) is a valid construct |
| 708 | provided 0 has been established as the payload type through a previous |
| 709 | negotiation process@footnote{Despite the fact that RFC 3551 defines a |
| 710 | static binding of the 0 code to mu-law PCM at 8Khz.}. |
| 711 | |
| 712 | @cindex Session control |
| 713 | Whether and how the payload has been negotiated is outside of the |
| 714 | scope of @acronym{RTP} and ccRTP, so applications must choose between |
| 715 | @code{StaticPayloadFormat} and @code{DynamicPayloadFormat} accordingly |
| 716 | to their multimedia session control mechanisms. |
| 717 | |
| 718 | |
| 719 | @c ----------------------------------------------------------------------- |
| 720 | @node Participants |
| 721 | @section Participants And Sources of Synchronization |
| 722 | @cindex Source of Synchronization |
| 723 | @cindex Participant |
| 724 | |
| 725 | @tindex RTPApplication |
| 726 | @tindex Participant |
| 727 | @tindex SyncSource |
| 728 | @tindex RTPSession |
| 729 | In GNU ccRTP, there are classes that represent @acronym{RTP} |
| 730 | applications (@code{RTPApplication}), participants |
| 731 | (@code{Participant}), synchronizacion sources (@code{SyncSource}) and |
| 732 | RTP sessions (@code{RTPSession}). The relations among these entities |
| 733 | are shown in the following diagram: |
| 734 | |
| 735 | @image{srcmodel,8cm,,{Relations between applications, participants, |
| 736 | sources and sessions}} |
| 737 | |
| 738 | @cindex CNAME |
| 739 | An @acronym{RTP} application establishes a space of CNAME identifiers, |
| 740 | whereas an @acronym{RTP} session establishes a space of SSRC |
| 741 | identifiers. |
| 742 | |
| 743 | For each source of synchronization seen in an @acronym{RTP} session, a |
| 744 | @code{SyncSource} object identified by a SSRC numeric identifier is |
| 745 | created. Thus, at the beginning of an @acronym{RTP} session there are |
| 746 | no @code{SyncSource} objects related. Note that, if the local source |
| 747 | sends packets to itself during an @acronym{RTP} session, a |
| 748 | @code{SyncSource} object will be created for it. |
| 749 | |
| 750 | The list of sources of synchronization identified in an RTP session |
| 751 | can be retrived through STL-like iterators of type |
| 752 | @code{RTPSession::SyncSourcesIterator}, as shown in the following |
| 753 | example. |
| 754 | |
| 755 | @cartouche |
| 756 | @example |
| 757 | // rx is an RTPSession object |
| 758 | RTPSession::SyncSourcesIterator it; |
| 759 | for (it = rx.begin() ; it != rx.end(); it++) @{ |
| 760 | const SyncSource &s = *it; |
| 761 | cout << s.getID(); |
| 762 | if ( s.isSender() ) |
| 763 | cout << "is an active sender"; |
| 764 | cout << endl; |
| 765 | @} |
| 766 | @end example |
| 767 | @end cartouche |
| 768 | |
| 769 | @findex RTPSession::SyncSourcesIterator |
| 770 | @cindex const iterator |
| 771 | @cindex iterator |
| 772 | Note @code{RTPSession::SyncSourcesIterator} is a const iterator. |
| 773 | |
| 774 | @findex SyncSource::getParticipant() |
| 775 | @cindex participant |
| 776 | When using RTCP, it is possible to associate several synchronization |
| 777 | source objects to a participant in the multimedia session, which is |
| 778 | represented through the association between @code{Participant} and |
| 779 | @code{SyncSource} objects. The participant object linked to a source |
| 780 | of synchronization can be retrieved through the |
| 781 | @code{SyncSource::getParticipant()} method, as the following examples |
| 782 | shows: |
| 783 | |
| 784 | @cartouche |
| 785 | @example |
| 786 | // s is a source of synchronization object (SyncSource) |
| 787 | Participant *p = s.getParticipant(); |
| 788 | cerr << p->getSDESItem(SDESItemTypeCNAME) << endl; |
| 789 | @end example |
| 790 | @end cartouche |
| 791 | |
| 792 | When RTCP is not being used or the CNAME identifier corresponding to a |
| 793 | synchronization source has not been received yet, the participant |
| 794 | associated with a synchronization source is not known. In these cases, |
| 795 | the method @code{SyncSource::getParticipant()} will return a NULL |
| 796 | pointer. On the contrary, a participant is always related to a |
| 797 | synchronization source at least. It can also be related to more than |
| 798 | one synchronization source (for instance, when a participant in a |
| 799 | videoconference sends two video streams from two different |
| 800 | chameras). Note that, if the local source sends data and control |
| 801 | packets to itself, a @code{Participant} object will be created for it. |
| 802 | |
| 803 | Thus, the @code{SyncSource::getParticipant} provides a facility for |
| 804 | inter-media synchronization. |
| 805 | |
| 806 | @findex defaultApplication |
| 807 | @findex RTPApplication |
| 808 | @cindex default value |
| 809 | @cindex CNAME |
| 810 | The association of @acronym{RTP} sessions and participants with |
| 811 | @code{RTPApplication} objects makes it possible to implement several |
| 812 | ``RTP applications'' in the same application or process, each one |
| 813 | having a separate CNAME space. By default, all @acronym{RTP} sessions |
| 814 | are associated to an @acronym{RTP} application provided by the global |
| 815 | method @code{defaultApplication()}. The local CNAME for the default |
| 816 | application is guessed from the user and machine name, as specified in |
| 817 | @cite{RFC 3550}. |
| 818 | |
| 819 | However, other applications may be created through the constructor |
| 820 | @code{RTPApplication::RTPApplication(const std::string& cname)}. @acronym{RTP} sessions are associated with applications other |
| 821 | than the default via an optional constructor parameter. |
| 822 | |
| 823 | @findex RTPApplication::ParticipantsIterator |
| 824 | @cindex const iterator |
| 825 | @cindex iterator |
| 826 | Similarly to the list of synchronization sources, the list of |
| 827 | participants in a session can be retrieved using iterators of type |
| 828 | @code{RTPApplication::ParticipantsIterator}, see the following |
| 829 | example, which shows the list of CNAMEs of the participants in the |
| 830 | default application: |
| 831 | |
| 832 | @cartouche |
| 833 | @example |
| 834 | RTPApplication &app = defaultApplication(); |
| 835 | RTPApplication::ParticipantsIterator ai; |
| 836 | for ( ai = app.begin(); ai != app.end(); ai++ ) @{ |
| 837 | const Participant &p = *ai; |
| 838 | cerr << p.getSDESItem(SDESItemTypeCNAME) << endl; |
| 839 | @} |
| 840 | @end example |
| 841 | @end cartouche |
| 842 | |
| 843 | @findex RTPApplication::ParticipantsIterator |
| 844 | @cindex const iterator |
| 845 | @cindex iterator |
| 846 | Note @code{RTPApplication::ParticipantsIterator} is a const iterator. |
| 847 | |
| 848 | @emph{TODO: SyncSource states}. |
| 849 | |
| 850 | |
| 851 | @c ----------------------------------------------------------------------- |
| 852 | @node RTP Packets Extensions |
| 853 | @section RTP Packets Extensions |
| 854 | @cindex RTP Packets Extensions |
| 855 | |
| 856 | @tindex RTPPacket |
| 857 | @tindex IncomingRTPPkt |
| 858 | @tindex OutgoingRTPPkt |
| 859 | @emph{TODO.} Describe @code{RTPPacket}, @code{IncomingRTPPkt} and |
| 860 | @code{OutgoingRTPPkt} classes. @xref{RTP Packets Arrival}, for a |
| 861 | discussion of event handling virtuals that allow for specialized |
| 862 | processing of data packets. |
| 863 | |
| 864 | |
| 865 | @c ----------------------------------------------------------------------- |
| 866 | @node RTCP Packets Extensions |
| 867 | @section RTCP Packets Extensions |
| 868 | @cindex RTCP Packets Extensions |
| 869 | |
| 870 | @xref{RTCP Packets Arrival}, for a discussion of event handling |
| 871 | virtuals that allow for specialized processing of control packets. |
| 872 | |
| 873 | |
| 874 | @c ----------------------------------------------------------------------- |
| 875 | @node Handling Events |
| 876 | @comment node-name, next, previous, up |
| 877 | @section Handling Events |
| 878 | @cindex Handling Events |
| 879 | |
| 880 | There are a number of events that may require special response from |
| 881 | the application. ccRTP defines plug-ins to handle these events. |
| 882 | |
| 883 | @menu |
| 884 | * RTP Packets Arrival:: Filtering and extending @acronym{RTP} packets parsing. |
| 885 | * RTCP Packets Arrival:: Filtering and extending @acronym{RTCP} packets parsing. |
| 886 | * Synchronization Source States:: Handling state transitions. |
| 887 | * SSRC Collisions:: Handling SSRC identifier collisions. |
| 888 | * RTP Packets Expiration:: Outgoing and incoming @acronym{RTP} packets expiration. |
| 889 | @end menu |
| 890 | |
| 891 | |
| 892 | @c ----------------------------------------------------------------------- |
| 893 | @node RTP Packets Arrival |
| 894 | @comment node-name, next, previous, up |
| 895 | @subsection RTP Packets Arrival |
| 896 | @cindex RTP Packet Arrival |
| 897 | |
| 898 | @findex IncomingDataQueue::onRTPPacketRecv |
| 899 | @code{onRTPPacketRecv} is the virtual method that may be redefined in |
| 900 | any subclass of @code{IncomingDataQueue}, particularly in subclasses |
| 901 | of @code{RTPSession}. It takes an @code{IncomingRTPPkt} object as |
| 902 | argument and returns a boolean indicating whether the packet should be |
| 903 | inserted in the reception queue. |
| 904 | |
| 905 | |
| 906 | @c ----------------------------------------------------------------------- |
| 907 | @node RTP Packets Expiration |
| 908 | @comment node-name, next, previous, up |
| 909 | @subsection RTP Packets Expiration |
| 910 | @cindex RTP Packets Expiration |
| 911 | |
| 912 | @findex OutgoingDataQueue::onExpireSend |
| 913 | @findex IncomingDataQueue::onExpireRecv |
| 914 | @code{onExpireSend} and @code{onExpireRecv} |
| 915 | |
| 916 | @findex QueueRTCPManager::end2EndDelayed |
| 917 | @code{end2EndDelayed} |
| 918 | |
| 919 | |
| 920 | @c ----------------------------------------------------------------------- |
| 921 | @node RTCP Packets Arrival |
| 922 | @comment node-name, next, previous, up |
| 923 | @subsection RTCP Packets Arrival |
| 924 | @cindex RTCP Packet Arrival |
| 925 | Incoming RTCP packets are automatically handled by ccRTP. However, |
| 926 | this does not mean you can't track the reception of RTCP packets. |
| 927 | |
| 928 | @itemize |
| 929 | |
| 930 | @cindex SR |
| 931 | @cindex RTCP SR |
| 932 | @findex QueueRTCPManager::onGotSR |
| 933 | @item @code{onGotSR} |
| 934 | |
| 935 | @cindex RR |
| 936 | @cindex RTCP RR |
| 937 | @findex QueueRTCPManager::onGotRR |
| 938 | @item @code{onGotRR} |
| 939 | |
| 940 | @cindex SDES |
| 941 | @cindex RTCP SDES |
| 942 | @findex QueueRTCPManager::onGotSDESChunk |
| 943 | @item @code{onGotSDESChunk} |
| 944 | |
| 945 | @cindex APP |
| 946 | @cindex RTCP APP |
| 947 | @findex QueueRTCPManager::onGotAPP |
| 948 | @item @code{onGotAPP} |
| 949 | |
| 950 | @cindex SRE Extension |
| 951 | @findex QueueRTCPManager::onGotRRSRExtension |
| 952 | @item @code{onGotRRSRExtension} |
| 953 | |
| 954 | @end itemize |
| 955 | |
| 956 | Note that this events correspond to RTCP packets, not RTCP compound |
| 957 | packets, and probably the reception of a compound packet will trigger |
| 958 | more than one of these events. |
| 959 | |
| 960 | |
| 961 | @c ----------------------------------------------------------------------- |
| 962 | @node Synchronization Source States |
| 963 | @comment node-name, next, previous, up |
| 964 | @subsection Synchronization Source States |
| 965 | @cindex Synchronization Source States |
| 966 | |
| 967 | @findex IncomingDataQueue::onNewSyncSource |
| 968 | @code{onNewSyncSource}. |
| 969 | |
| 970 | |
| 971 | @c ----------------------------------------------------------------------- |
| 972 | @node SSRC Collisions |
| 973 | @comment node-name, next, previous, up |
| 974 | @subsection SSRC Collisions |
| 975 | @cindex SSRC Collision |
| 976 | |
| 977 | @cindex collision |
| 978 | @cindex SSRC collision |
| 979 | @findex QueueRTCPManager::onSSRCCollision |
| 980 | @code{onSSRCCollision}. |
| 981 | |
| 982 | @c ----------------------------------------------------------------------- |
| 983 | @node Specialized Payload Formats |
| 984 | @chapter Specialized Payload Formats |
| 985 | @cindex Specialized Payload Formats |
| 986 | |
| 987 | @emph{TODO:} finish 2833bis and CN. |
| 988 | |
| 989 | @emph{TODO:} comment H.261 specific RTCP packets: FIR and NACK. |
| 990 | |
| 991 | |
| 992 | @c ----------------------------------------------------------------------- |
| 993 | @node Standards Tracking |
| 994 | @chapter Standards Tracking |
| 995 | @cindex Standards tracking |
| 996 | |
| 997 | @cindex IETF |
| 998 | @cindex IETF standards |
| 999 | |
| 1000 | @emph{TODO: explain what is done/being done/planned}. |
| 1001 | |
| 1002 | @itemize |
| 1003 | |
| 1004 | @item @cite{RTP: A Transport Protocol for Real-Time Applications (RFC 3550, which supersedes RFC 1889)}. |
| 1005 | |
| 1006 | @item @cite{RTP Profile for Audio and Video Conferences with Minimal Control (RFC 3551, which supersedes RFC 1890)}. |
| 1007 | |
| 1008 | @item @cite{MIME Type Registration of RTP Payload Formats (RFC 3555)}. |
| 1009 | |
| 1010 | @item @cite{IANA RTP Parameters}. |
| 1011 | |
| 1012 | @item @cite{RTP Payload Format for H.261 Video Streams (RFC 2032)}. Defines H.261 specific FIR and NACK RTCP packets. |
| 1013 | |
| 1014 | |
| 1015 | @end itemize |
| 1016 | |
| 1017 | @itemize |
| 1018 | |
| 1019 | Not yet implemented: |
| 1020 | |
| 1021 | @cindex profile |
| 1022 | @cindex SRTP |
| 1023 | @cindex Secure RTP |
| 1024 | @item @cite{The Secure Real-time Transport Protocol}. SRTP provile. |
| 1025 | |
| 1026 | @cindex AVPF |
| 1027 | @cindex RTCP-based feedback |
| 1028 | @item @cite{Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)}. |
| 1029 | |
| 1030 | @cindex AVPF |
| 1031 | @cindex RTCP-based feedback |
| 1032 | @item @cite{Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)}. |
| 1033 | |
| 1034 | @cindex SAVPF |
| 1035 | @item @cite{Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)}. |
| 1036 | |
| 1037 | @end itemize |
| 1038 | |
| 1039 | |
| 1040 | @c ----------------------------------------------------------------------- |
| 1041 | @node Upgrading |
| 1042 | @chapter Upgrading |
| 1043 | @cindex Upgrading |
| 1044 | |
| 1045 | This chapter outlines the main steps required to upgrade applications |
| 1046 | written for old releases of ccRTP (0.6.x, 0.7.x and 0.9.x series) to |
| 1047 | the 1.0 series. It is written mostly as a recipe of replacements for |
| 1048 | old constructs. |
| 1049 | |
| 1050 | Replace @code{#include <cc++/rtp.h>} with @code{#include |
| 1051 | <ccrtp/rtp.h>}@footnote{Note that unfortunately ccRTP 1.0pre0 used |
| 1052 | @code{#include <cc++/rtp/rtp.h}, which is now deprecated.}. |
| 1053 | |
| 1054 | Changes that have to do more with Common C++ 2 than with ccRTP: |
| 1055 | |
| 1056 | @table @code |
| 1057 | |
| 1058 | @item exit(int) |
| 1059 | @findex exit |
| 1060 | Replace with exit() |
| 1061 | |
| 1062 | @item Thread::Terminate() |
| 1063 | @findex Thread::terminate |
| 1064 | Replace with Thread::terminate() |
| 1065 | |
| 1066 | @item ccxx_sleep(timeout_t) |
| 1067 | @findex ccxx_sleep |
| 1068 | @findex Thread::sleep |
| 1069 | Replace with sleep(timeout_t). |
| 1070 | |
| 1071 | @item Thread::Run() |
| 1072 | Replace with Thread::run() |
| 1073 | |
| 1074 | @end table |
| 1075 | |
| 1076 | Changes required by ccRTP itself: |
| 1077 | |
| 1078 | @table @code |
| 1079 | @item RTPSource |
| 1080 | @tindex RTPSource |
| 1081 | @tindex SyncSource |
| 1082 | Now @code{SyncSource}, and is a somewhat different concept. For |
| 1083 | instance, calls to RTPSource::getID() must be replaced with calls to |
| 1084 | SyncSource::getID(), which in most cases will not imply any change to |
| 1085 | this part of the code. |
| 1086 | |
| 1087 | @item RTPQueue::getLocalInfo()->getID() |
| 1088 | @findex RTPQueue::getLocalInfo |
| 1089 | @findex RTPQueue::getLocalSSRC |
| 1090 | Replace with @code{RTPQueueBase::getLocalSSRC()} |
| 1091 | |
| 1092 | @item RTPQueue::getCNAME() |
| 1093 | @findex RTPQueue::getCNAME |
| 1094 | @findex defaultApplication |
| 1095 | @findex RTPApplication::getSDESItem |
| 1096 | Replace with @code{defaultApplication().getSDESItem(SDESItemTypeSDES)}. |
| 1097 | |
| 1098 | @item RTPQueue::getPacket() |
| 1099 | @findex RTPQueue::getPacket |
| 1100 | @findex IncomingDataQueue::getData |
| 1101 | @code{getPacket()} has been removed and now there is only a |
| 1102 | @code{getData()} method in the @acronym{RTP} queues. |
| 1103 | |
| 1104 | @item RTPQueue::setTimeout() |
| 1105 | @findex RTPQueue::setTimeout |
| 1106 | @findex OutgoingDataQueue::setSchedulingTimeout |
| 1107 | Replace calls to RTPQueue::setTimeout(microtimeout_t) with calls to |
| 1108 | OutgoingDataQueue(microtimeout_t), whose purpose and working is |
| 1109 | exactly the same. |
| 1110 | |
| 1111 | @item RTPQueue::putPacket() |
| 1112 | @findex RTPQueue::putPacket |
| 1113 | @findex OutgoingDataQueue::putData |
| 1114 | @cindex payload type |
| 1115 | @findex RTPQueueBase::setPayloadFormat |
| 1116 | @code{putPacket()} has been removed and now there is only a |
| 1117 | @code{putData()} method in the @acronym{RTP} queues. Note also that now the |
| 1118 | payload type is not specified for each outgoing @acronym{RTP} data block, |
| 1119 | instead use RTPQueueBase::setPayloadFormat each time the payload type |
| 1120 | changes. |
| 1121 | |
| 1122 | @item PayloadType |
| 1123 | @tindex DynamicPayloadType |
| 1124 | @tindex StaticPayloadType |
| 1125 | The definition of payload types has deeply changed in order to allow |
| 1126 | all standard uses of dynamic payload negotiation. Refer to |
| 1127 | @ref{Payload Types and Formats}, for an explanation of the new payload |
| 1128 | types and formats related classes. |
| 1129 | |
| 1130 | For example, @code{RTP_PAYLOAD_PCMU} must be replaced with something |
| 1131 | like @code{StaticPayloadFormat pcmu(sptPCMU)}, where @code{pcmu} is |
| 1132 | the name of a static payload object that binds an statically assigned |
| 1133 | @code{PayloadType} @footnote{The static payload type 0 corresponds to |
| 1134 | the audio format PCMU, see @cite{RFC 3550}.}. to its corresponding |
| 1135 | @acronym{RTP} clock rate@footnote{8 khz.}. |
| 1136 | |
| 1137 | @cindex destination |
| 1138 | @cindex redundancy |
| 1139 | @item RTPSocket::Connect |
| 1140 | The call connect has been removed. Now, in order to send packets to a |
| 1141 | destination @code{OutgoingDataQueue::addDestination} must be used. It |
| 1142 | allows for setting more than one destination. Any destination can |
| 1143 | actually be added more than one time with addDestination, which can be |
| 1144 | used a simple trick to perform redundant transmission: each packet -both |
| 1145 | RTP and RTCP- will be transmitted to the destination as many times as it |
| 1146 | has been added to the list of destinations through calling |
| 1147 | addDestination. |
| 1148 | |
| 1149 | @item RTPQueue::getCurrentRate |
| 1150 | @findex RTPQueue::getCurrentRate |
| 1151 | @findex RTPQueueBase::getCurrentRTPClockRate |
| 1152 | Replace with @code{RTPQueueBase::getCurrentRTPClockRate()}. |
| 1153 | |
| 1154 | @item RTPSocket::Start |
| 1155 | @findex RTPSocket::Start |
| 1156 | @findex RTPSession::startRunning |
| 1157 | Replace with @code{RTPSession::startRunning}. |
| 1158 | |
| 1159 | @item RTPQueue::gotHello |
| 1160 | @findex RTPQueue::gotHello |
| 1161 | @findex QueueRTCPManager::onNewSyncSource |
| 1162 | Replace with @code{QueueRTCPManager::onNewSyncSource}. |
| 1163 | |
| 1164 | @item RTPQueue::gotGoodbye |
| 1165 | @findex RTPQueue::gotGoodbye |
| 1166 | @findex QueueRTCPManager::onGotGoodbye |
| 1167 | Replace with @code{QueueRTCPManager::onGotGoodbye}. |
| 1168 | |
| 1169 | @end table |
| 1170 | |
| 1171 | |
| 1172 | @c ----------------------------------------------------------------------- |
| 1173 | @node ccRTP Internals |
| 1174 | @comment node-name, next, previous, up |
| 1175 | @chapter ccRTP Internals |
| 1176 | @cindex @acronym{ccRTP} Internals |
| 1177 | |
| 1178 | |
| 1179 | @menu |
| 1180 | * Internals Overview:: ccRTP internals overview. |
| 1181 | * Collisions and Loops:: Collision Resolution and Loop Detection. |
| 1182 | * Algorithms in the Standard:: Implementation of algorithms in the standard. |
| 1183 | @end menu |
| 1184 | |
| 1185 | |
| 1186 | @c ----------------------------------------------------------------------- |
| 1187 | @node Internals Overview |
| 1188 | @section Internals Overview |
| 1189 | @cindex Internals Overview |
| 1190 | |
| 1191 | @emph{TODO: Explain where on how timer reconsideration/reverse recons. is |
| 1192 | performed}. |
| 1193 | |
| 1194 | Performance: |
| 1195 | |
| 1196 | @itemize |
| 1197 | @item Zero copy stack. |
| 1198 | @item RW/R multithreading. |
| 1199 | @item Fast specialized linked list and hash mechanisms. |
| 1200 | @end itemize |
| 1201 | |
| 1202 | @c ----------------------------------------------------------------------- |
| 1203 | @node Collisions and Loops |
| 1204 | @section Collisions and Loops |
| 1205 | @cindex Collisions and Loops |
| 1206 | |
| 1207 | ccRTP performs loop detection (following 8.2 in @cite{RFC 3550}, |
| 1208 | though the algorithm in ccRTP differs is structure because of two |
| 1209 | reasons: |
| 1210 | |
| 1211 | @itemize |
| 1212 | |
| 1213 | @item ccRTP holds a table of source for which some packet has been received, instead of a table with all the sources in the session (i.e. the local source is not included in the table unless it sends packets to itself). |
| 1214 | |
| 1215 | @item RTP and RTCP packets are handled separately whereas the algorithm in 8.2 treats both. |
| 1216 | |
| 1217 | Note that the first two conditions in 8.2 (creating new source entries |
| 1218 | and setting source transport address) are handled in the SSRC |
| 1219 | bookkeeping methods rather than mixing them with the real collisions |
| 1220 | and loop handling. |
| 1221 | |
| 1222 | Unlike the algorithm given in 8.2, the ccRTP algorithm detects the |
| 1223 | very rare case when two sources on the same host use the same SSRC |
| 1224 | identifier and the first @acronym{RTP} packet for that identifier is |
| 1225 | received from one source and the first RTCP is received from the |
| 1226 | other. |
| 1227 | |
| 1228 | @end itemize |
| 1229 | |
| 1230 | @c ----------------------------------------------------------------------- |
| 1231 | @node Algorithms in the Standard |
| 1232 | @section Algorithms in the Standard |
| 1233 | @cindex Algoritms in the Standard |
| 1234 | |
| 1235 | The following sections summarizes how the algorithms specified in |
| 1236 | appendixes from @cite{RFC 3550} are implemented in ccRTP. A |
| 1237 | ``mapping'' between routines in the RFC and methods/routines in ccRTP |
| 1238 | is provided. |
| 1239 | |
| 1240 | @menu |
| 1241 | * A.1:: @acronym{RTP} Data Header Validity Checks. |
| 1242 | * A.2:: RTCP Header Validity Checks. |
| 1243 | * A.3:: Determining the Number of @acronym{RTP} Packets Expected and Lost. |
| 1244 | * A.4:: Generating SDES RTCP Packets. |
| 1245 | * A.5:: Parsing RTCP SDES Packets. |
| 1246 | * A.6:: Generating a Random 32-bit Identifier. |
| 1247 | * A.7:: Computing the RTCP Transmission Interval. |
| 1248 | * A.8:: Estimating the Interarrival Jitter. |
| 1249 | @end menu |
| 1250 | |
| 1251 | |
| 1252 | @c ----------------------------------------------------------------------- |
| 1253 | @node A.1 |
| 1254 | @subsection A.1 |
| 1255 | @cindex A.1 |
| 1256 | |
| 1257 | @findex IncomingDataQueue::checkSSRCInIncomingRTPPkt |
| 1258 | @findex QueueRTCPManager::checkSSRCInRTCPPkt |
| 1259 | ccRTP performs @acronym{RTP} data header validity check in two stages: |
| 1260 | the first stage, performed at the constructor of @code{IncomingRTPPkt} |
| 1261 | (which is extensible with virtual methods) validates the header fields |
| 1262 | independent of the source. The second stage, performed at |
| 1263 | @code{IncomingDataQueue::checkSSRCInIncomingRTPPkt} and |
| 1264 | @code{QueueRTCPManager::checkSSRCInRTCPPkt}, validates those fields |
| 1265 | specific to the source of the packet (number sequence, etc). |
| 1266 | |
| 1267 | Additionally, the following table specifies which methods of ccRTP |
| 1268 | implement the functions init_seq and update_seq from A.1. |
| 1269 | |
| 1270 | @table @code |
| 1271 | |
| 1272 | @item void init_seq(source*, u_int16) |
| 1273 | void MembershipBookkeeping::SyncSourceLink::initSequence(uint16) |
| 1274 | |
| 1275 | @item int update_seq(source*, u_int16) |
| 1276 | bool RTPQueue::recordReception(SyncSourceLink&, const IncomingRTPPkt&) |
| 1277 | |
| 1278 | @end table |
| 1279 | |
| 1280 | @c ----------------------------------------------------------------------- |
| 1281 | @node A.2 |
| 1282 | @subsection A.2 |
| 1283 | @cindex A.2 |
| 1284 | |
| 1285 | @cindex header check |
| 1286 | @cindex header validity |
| 1287 | @cindex RTCP header |
| 1288 | @findex RTCPCompoundHandler::checkCompountRTCPHeader |
| 1289 | The code in A.2 corresponds to |
| 1290 | @code{RTCPCompoundHandler::checkCompountRTCPHeader}. |
| 1291 | |
| 1292 | |
| 1293 | @c ----------------------------------------------------------------------- |
| 1294 | @node A.3 |
| 1295 | @subsection A.3 |
| 1296 | @cindex A.3 |
| 1297 | |
| 1298 | @findex MembershipBookkeeping::SyncSourceLink::computeStats |
| 1299 | Code in A.3 corresponds to @code{MembershipBookeeping::computeStats}. |
| 1300 | |
| 1301 | |
| 1302 | @c ----------------------------------------------------------------------- |
| 1303 | @node A.4 |
| 1304 | @subsection A.4 |
| 1305 | @cindex A.4 |
| 1306 | |
| 1307 | @findex QueueRTCPManager::packSDES |
| 1308 | Code in A.4 is implemented as part of the method |
| 1309 | @code{QueueRTCPManager::packSDES}. |
| 1310 | |
| 1311 | |
| 1312 | @c ----------------------------------------------------------------------- |
| 1313 | @node A.5 |
| 1314 | @subsection A.5 |
| 1315 | @cindex A.5 |
| 1316 | |
| 1317 | @findex QueueRTCPManager::onGotSDES |
| 1318 | Code in A.5 is implemented in the method |
| 1319 | @code{QueueRTCPManager::onGotSDES}, which calls the virtual method |
| 1320 | @code{QueueRTCPManager::onGotSDESChunk} to process each SDES chunk. |
| 1321 | |
| 1322 | |
| 1323 | @c ----------------------------------------------------------------------- |
| 1324 | @node A.6 |
| 1325 | @subsection A.6 |
| 1326 | @cindex A.6 |
| 1327 | |
| 1328 | @cindex Random numbers |
| 1329 | @cindex /dev/urandom |
| 1330 | @cindex MD5 |
| 1331 | On POSIX systems, ccRTP uses @file{/dev/urandom} when available. If |
| 1332 | there is no such device, it defaults to the MD5 based algorithm given |
| 1333 | in appendix A.6. |
| 1334 | |
| 1335 | Code in A.6 corresponds to @code{uint32 MD5BasedRandom32()}, which is |
| 1336 | called by @code{uint32 random32()} when no random device is available. |
| 1337 | |
| 1338 | |
| 1339 | @c ----------------------------------------------------------------------- |
| 1340 | @node A.7 |
| 1341 | @subsection A.7 |
| 1342 | @cindex A.7 |
| 1343 | |
| 1344 | Mapping: |
| 1345 | |
| 1346 | @table @code |
| 1347 | |
| 1348 | @item double rtcp_interval(int, int, double, int, double, int) |
| 1349 | virtual timeval QueueRTCPManager::computeRTCPInterval(), and in timeval |
| 1350 | (seconds + microseconds) units, instead of seconds. |
| 1351 | |
| 1352 | @item OnExpire(event, int, int, double, int, double, int time_tp, time_tp, int) |
| 1353 | QueueRTCPManager::runControlService(microtimeout_t) (this method also |
| 1354 | implements part of SendRTCPReport(e)) |
| 1355 | |
| 1356 | @item OnReceive(packet, event, int, int, int, double, double, double, double) |
| 1357 | void QueueRTCPManager::takeInControlPacket() and |
| 1358 | QueueRTCPManager::runControlService(microtimeout_t) |
| 1359 | |
| 1360 | @item Schedule(time, event) and Reschedule(time, event) |
| 1361 | No equivalent. |
| 1362 | |
| 1363 | @findex QueueRTCPManager::dispatchControlPacket |
| 1364 | @item SendRTCPReport(event) |
| 1365 | @code{dispatchControlPacket}. |
| 1366 | |
| 1367 | @findex QueueRTCPManager::dispatchBYE |
| 1368 | @item SendBYEPacket(event) |
| 1369 | @code{QueueRTCPManager::dispatchBYE(const std::string& reason)}. |
| 1370 | |
| 1371 | @item TypeOfEvent(event) |
| 1372 | No equivalent. |
| 1373 | |
| 1374 | @item PacketType(p) |
| 1375 | No equivalent. |
| 1376 | |
| 1377 | @findex IncomingDataQueue::takeInDataPacket |
| 1378 | @item ReceivedPacketSize() |
| 1379 | @code{size_t IncomingDataQueue::takeInDataPacket()}. |
| 1380 | |
| 1381 | @findex OutgoingDataQueue::dispatchDataPacket |
| 1382 | @findex QueueRTCPManager::dispatchControlPacket |
| 1383 | @item SentPacketSize() |
| 1384 | @code{size_t OutgoingDataQueue::dispatchDataPacket()} -data, and |
| 1385 | @code{size_t QueueRTCPManager::dispatchControlPacket()} -control. |
| 1386 | |
| 1387 | @item NewMember(p) |
| 1388 | |
| 1389 | @item NewSender(p) |
| 1390 | |
| 1391 | @item AddMember() and RemoveMember() |
| 1392 | |
| 1393 | @item AddSender() and RemoveSender() |
| 1394 | |
| 1395 | @end table |
| 1396 | |
| 1397 | |
| 1398 | @c ----------------------------------------------------------------------- |
| 1399 | @node A.8 |
| 1400 | @subsection A.8 |
| 1401 | @cindex A.8 |
| 1402 | |
| 1403 | @cindex jitter |
| 1404 | @cindex interarrival jitter |
| 1405 | @findex IncomingDataQueue::recordReception |
| 1406 | Interarrival jitter is estimated as specified in A.8, in |
| 1407 | @code{recordReception}. Jitter is kept as a float. |
| 1408 | |
| 1409 | |
| 1410 | @c ----------------------------------------------------------------------- |
| 1411 | @node Related Work |
| 1412 | @comment node-name, next, previous, up |
| 1413 | @chapter Related Work |
| 1414 | @cindex Related work |
| 1415 | |
| 1416 | @emph{TODO}. Other free @acronym{RTP} stacks and tools: |
| 1417 | |
| 1418 | @itemize |
| 1419 | |
| 1420 | @item jrtplib |
| 1421 | |
| 1422 | @item oRTP |
| 1423 | |
| 1424 | @item LIVE.COM Streaming Media |
| 1425 | |
| 1426 | @item UCL Common Code Library. Note this library is distributed under a BSD license @emph{with} the obnoxious clausule. |
| 1427 | @end itemize |
| 1428 | |
| 1429 | |
| 1430 | @c ----------------------------------------------------------------------- |
| 1431 | @node Future Work |
| 1432 | @comment node-name, next, previous, up |
| 1433 | @chapter Future Work |
| 1434 | @cindex Future, Future Work |
| 1435 | |
| 1436 | @emph{TODO}. |
| 1437 | |
| 1438 | |
| 1439 | @c %** end of body |
| 1440 | |
| 1441 | @c ----------------------------------------------------------------------- |
| 1442 | @node Licenses |
| 1443 | @appendix Licenses |
| 1444 | |
| 1445 | @menu |
| 1446 | * GNU Free Documentation License:: License for this document. |
| 1447 | * GNU General Public License:: ccRTP Base License. |
| 1448 | * GNU ccRTP Linking Exception:: ccRTP linking exception. |
| 1449 | @end menu |
| 1450 | |
| 1451 | @include gpl.texi |
| 1452 | |
| 1453 | @include fdl.texi |
| 1454 | |
| 1455 | |
| 1456 | @c ----------------------------------------------------------------------- |
| 1457 | @node GNU ccRTP Linking Exception |
| 1458 | @appendixsec GNU ccRTP Linking Exception |
| 1459 | @cindex GNU ccRTP Linking Exception |
| 1460 | |
| 1461 | As a special exception to the GNU General Public License, permission |
| 1462 | is granted for additional uses of the text contained in its release of |
| 1463 | ccRTP. |
| 1464 | |
| 1465 | The exception is that, if you link the ccRTP library with other files |
| 1466 | to produce an executable, this does not by itself cause the resulting |
| 1467 | executable to be covered by the GNU General Public License. Your use |
| 1468 | of that executable is in no way restricted on account of linking the |
| 1469 | ccRTP library code into it. |
| 1470 | |
| 1471 | This exception does not however invalidate any other reasons why the |
| 1472 | executable file might be covered by the GNU General Public License. |
| 1473 | |
| 1474 | This exception applies only to the code released under the name ccRTP. |
| 1475 | If you copy code from other releases into a copy of ccRTP, as the |
| 1476 | General Public License permits, the exception does not apply to the |
| 1477 | code that you add in this way. To avoid misleading anyone as to the |
| 1478 | status of such modified files, you must delete this exception notice |
| 1479 | from them. |
| 1480 | |
| 1481 | If you write modifications of your own for ccRTP, it is your choice |
| 1482 | whether to permit this exception to apply to your modifications. If |
| 1483 | you do not wish that, delete this exception notice. |
| 1484 | |
| 1485 | |
| 1486 | |
| 1487 | |
| 1488 | @c ----------------------------------------------------------------------- |
| 1489 | |
| 1490 | @c %** start of end |
| 1491 | @node Class and Data Type Index |
| 1492 | @unnumbered Class and Data Type Index |
| 1493 | |
| 1494 | @printindex tp |
| 1495 | |
| 1496 | @node Method and Function Index |
| 1497 | @unnumbered Method and Function Index |
| 1498 | |
| 1499 | @printindex fn |
| 1500 | |
| 1501 | @node Concept Index |
| 1502 | @unnumbered Concept Index |
| 1503 | |
| 1504 | @printindex cp |
| 1505 | |
| 1506 | @bye |
| 1507 | @c %** end of end |