rtp

Type Members

1. case class RTCPHeader(version: codec.RTPVersion.Value, padding: Boolean, elements: Int, length: Int, tpe: RTCPPacketType.Value) extends Product with Serializable

   

   Class describing RTCP Header in each RTCP Packet.

   Class describing RTCP Header in each RTCP Packet. Header consist of first two words (64 bits)

   version

   RTCP Protocol version

   padding

   If the padding bit is set, this individual RTCP packet contains some additional padding octets at the end which are not part of the control information but are included in the length field. The last octet of the padding is a count of how many padding octets should be ignored, including itself (it will be a multiple of four). *

   elements

   Elements in the rctp packet. These may be reports, source descriptors etc.

   length

   Length of the packet in words (32 bits) - 1

2. case class RTCPPacket(version: codec.RTPVersion.Value, body: RTCPPacketBody) extends Product with Serializable

   

   RTCP Packet in full

   RTCP Packet in full

   version

   RTCP Protocol version

   body

   Body and Type of the packet

3. sealed trait RTCPPacketBody extends AnyRef

   

4. case class RTPHeaderExtension(flag: Int, content: ByteVector) extends Product with Serializable

   

5. case class RTPPacket(version: codec.RTPVersion.Value, marker: Boolean, payloadType: Int, sequenceNumber: Int, timestamp: Long, ssrc: Int, csrc: Seq[Int], payload: ByteVector, extensionHeader: Option[RTPHeaderExtension]) extends Product with Serializable

   

   Models simple RTP Packet according to RFC 3550 (https://www.ietf.org/rfc/rfc3550.txt)

   Models simple RTP Packet according to RFC 3550 (https://www.ietf.org/rfc/rfc3550.txt)

   version

   This field identifies the version of RTP. The version defined by this specification is two (2).

   marker

   The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame boundaries to be marked in the packet stream. A profile MAY define additional marker bits or specify that there is no marker bit by changing the number of bits in the payload type field (see Section 5.3).

   payloadType

   This field identifies the format of the RTP payload and determines its interpretation by the application. A profile MAY specify a default static mapping of payload type codes to payload formats. Additional payload type codes MAY be defined dynamically through non-RTP means (see Section 3). A set of default mappings for audio and video is specified in the companion RFC 3551 [1]. An RTP source MAY change the payload type during a session, but this field SHOULD NOT be used for multiplexing separate media streams (see Section 5.2). A receiver MUST ignore packets with payload types that it does not understand.

   sequenceNumber

   The sequence number increments by one for each RTP data packet sent, and may be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number SHOULD be random (unpredictable) to make known-plaintext attacks on encryption more difficult, even if the source itself does not encrypt according to the method in Section 9.1, because the packets may flow through a translator that does. Techniques for choosing unpredictable numbers are discussed in [17].

   timestamp

   The timestamp reflects the sampling instant of the first octet in the RTP data packet. The sampling instant MUST be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations (see Section 6.4.1).

   ssrc

   The SSRC field identifies the synchronization source. This identifier SHOULD be chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC identifier. An example algorithm for generating a random identifier is presented in Appendix A.6. Although the probability of multiple sources choosing the same identifier is low, all RTP implementations must be prepared to detect and resolve collisions. Section 8 describes the probability of collision along with a mechanism for resolving collisions and detecting RTP-level forwarding loops based on the uniqueness of the SSRC identifier. If a source changes its source transport address, it must also choose a new SSRC identifier to avoid being interpreted as a looped source (see Section 8.2).

   csrc

   The CSRC list identifies the contributing sources for the payload contained in this packet. The number of identifiers is given by the CC field. If there are more than 15 contributing sources, only 15 can be identified. CSRC identifiers are inserted by mixers (see Section 7.1), using the SSRC identifiers of contributing sources. For example, for audio packets the SSRC identifiers of all sources that were mixed together to create a packet are listed, allowing correct talker indication at the receiver.

   payload

   Payload of this RTP Packet.

   extensionHeader

   Extension header, if present

6. case class Report(ssrc: Int, fractionLost: Int, packetsLost: Int, hiSeqNoReceived: Long, jitter: Int, lastSRTimestamp: Long, delaySinceLastSR: Long) extends Product with Serializable

   

   Sender or Receive report bloc for each SSRC

   Sender or Receive report bloc for each SSRC

   ssrc

   The SSRC identifier of the source to which the information in this reception report block pertains.

   fractionLost

   The fraction of RTP data packets from source SSRC_n lost since the previous SR or RR packet was sent, expressed as a fixed point number with the binary point at the left edge of the field. (That is equivalent to taking the integer part after multiplying the loss fraction by 256.)

   packetsLost

   The total number of RTP data packets from source SSRC_n that have been lost since the beginning of reception.

   hiSeqNoReceived

   The low 16 bits contain the highest sequence number received in an RTP data packet from source SSRC_n, and the most significant 16 bits extend that sequence number with the corresponding count of sequence number cycles, which may be maintained according to the algorithm in Appendix A.1. Note that different receivers within the same session will generate different extensions to the sequence number if their start times differ significantly

   jitter

   An estimate of the statistical variance of the RTP data packet interarrival time, measured in timestamp units and expressed as an unsigned integer.

   lastSRTimestamp

   The middle 32 bits out of 64 in the NTP timestamp (as explained in Section 4) received as part of the most recent RTCP sender report (SR) packet from source SSRC_n. If no SR has been received yet, the field is set to zero.

   delaySinceLastSR

   The delay, expressed in units of 1/65536 seconds, between receiving the last SR packet from source SSRC_n and sending this reception report block. If no SR packet has been received yet from SSRC_n, the DLSR field is set to zero.

7. case class SourceDescriptor(ssrc: Int, attributes: Vector[(SourceDescriptorType.Value, String)]) extends Product with Serializable