uvgrtp-base/docs
Aaro Altonen d80abd580e Document pull_frame() 2021-03-23 01:19:47 +02:00
..
examples Document push_frame() 2021-03-23 01:19:47 +02:00
html Document pull_frame() 2021-03-23 01:19:47 +02:00
README.md Rename RCE_HEVC_NO_INTRA_DELAY to RCE_NO_H26X_INTRA_DELAY 2021-03-23 01:18:59 +02:00
arch.png Add Doxygen documentation support 2021-03-23 01:18:59 +02:00

README.md

Documentation for uvgRTP

This file provides documentation of uvgRTP's usage and public API.

Architecture

The top-level object for uvgRTP is the uvgrtp::context object. It is used to create RTP sessions that are bound to certain IP addresses and to provide CNAME namespace isolation if that is required by the application. Most of the time only one context object is enough per application.

RTP sessions, uvgrtp::session objects, are allocated from uvgrtp::context. For each remote IP address, a session object should be created. uvgRTP supports UDP holepunching so during session creation a source IP address can be specified and uvgRTP binds itself to that address before it starts streaming.

Each session contains 1..n uvgrtp::media_stream objects. These objects are bidirectional streams, i.e. you use the same object to send and receive RTP frames. The object can be used as unidirectional stream too, a user then just doesn't either send or receive RTP frames using the object. Each uvgrtp::media_stream object contains source and destination ports, media format for the stream and a collection of context configuration flags that enable, for example, SRTP or RTCP.

Public API

The public API for uvgRTP is very short. Functions not listed in the public API should not be called by an application using uvgRTP as they are for internal usage only. All of the features are provided as either built-in or they are enabled/modified through context configuration that is specified below.

Read the documentation for uvgRTP's public API here

Supported media formats

Currently uvgRTP has a built-in support for the following media formats:

  • AVC
  • HEVC
  • VVC
  • Opus

uvgRTP also features a generic media frame API that can be used to fragment and send any media format, see this example code for more details. Fragmentation of generic media formats is a uvgRTP exclusive feature and does not work with other RTP libraries so please use it only if you are using uvgRTP for both sending and receiving.

Context configuration

RCE_* flags are used to enable/disable functionality of an individual uvgrtp::media_stream object. Table below lists all supported flags and what they enable/disable. RCE_* flags are passed to create_stream() as the last parameter and they can be OR'ed together

session->create_stream(..., RCE_SRTP | RCE_SRTP_KMNGMNT_ZRTP | RCE_SRTP_NULL_CIPHER);
Flag Explanation
RCE_SRTP Enable SRTP, must be coupled with either RCE_SRTP_KMNGMNT_ZRTP or RCE_SRTP_KMNGMNT_USER
RCE_SRTP_KMNGMNT_ZRTP Use ZRTP to manage keys (see section SRTP for more details)
RCE_SRTP_KMNGMNT_USER Let user manage keys (see section SRTP for more details)
RCE_NO_H26X_INTRA_DELAY placeholder
RCE_FRAGMENT_GENERIC Fragment generic media frames into RTP packets of 1500 bytes (size is configurable, see RCC_MTU_SIZE)
RCE_SRTP_INPLACE_ENCRYPTION Perform ciphering directly on the input frame. Saves a memory copy but makes the input frame unusable for the application
RCE_NO_SYSTEM_CALL_CLUSTERING Disable System Call Clustering, see the publication for more details
RCE_SRTP_NULL_CIPHER Use NULL cipher for SRTP, i.e. do not encrypt packets
RCE_SRTP_AUTHENTICATE_RTP Add RTP authentication tag to each RTP packet and verify authenticity of each received packet before they are returned to the user
RCE_SRTP_REPLAY_PROTECTION Monitor and reject replayed RTP packets
RCE_RTCP Enable RTCP
RCE_H26X_PREPEND_SC Prepend a 4-byte start code (0x00000001) before each NAL unit
RCE_HOLEPUNCH_KEEPALIVE Keep the hole made in the firewall open in case the streaming is unidirectional. If holepunching has been enabled during session creation and this flag is given to create_stream() and uvgRTP notices that the application has not sent any data in a while (unidirectionality), it sends a small UDP datagram to the remote participant to keep the connection open

RCC_* flags are used to modify the default values used by uvgRTP. Table below lists all supported flags and what they modify.

Flag Explanation Default
RCC_UDP_RCV_BUF_SIZE Specify UDP receive buffer size 4 MB
RCC_UDP_SND_BUF_SIZE Specify UDP send buffer size 4 MB
RCC_PKT_MAX_DELAY How many milliseconds is each frame waited until they're dropped (for fragmented frames only) 100 ms
RCC_DYN_PAYLOAD_TYPE Override uvgRTP's payload type used in RTP headers Format-specific, see include/util.hh
RCC_MTU_SIZE Set a maximum value for the Ethernet frame size assumed by uvgRTP (for enabling, for example, jumbo frame support) 1500 bytes

Configuration done using RCC_* flags are done by calling configure_ctx() with a flag and a value

stream->configure_ctx(RCC_PKT_MAX_DELAY, 150);

SRTP

uvgRTP provides two ways for an application to deal with SRTP key-management: ZRTP or user-managed. Out of the two, ZRTP is simpler but requires message exchanging before media encryption can take place whereas for user-managed keys the calling application must provide an encryption key and a salt.

ZRTP-based SRTP

uvgRTP supports Diffie-Hellman and Multistream modes of ZRTP. The mode selection is done transparently and the only thing an application must do is to provide RCE_SRTP | RCE_SRTP_KMNGMNT_ZRTP flag combination to create_stream(). See ZRTP Multistream example for more details.

User-managed SRTP

The second way of handling key-management of SRTP is to do it yourself. uvgRTP supports 128-bit keys and and 112-bit salts which must be given to the uvgrtp::media_stream object using add_srtp_ctx() right after create_stream() has been called. All calls that try to modify or use the stream (other than add_srtp_ctx()) will fail with RTP_NOT_INITIALIZED. See this example code for more details.