rtp的报文基本格式
1 | 0 1 2 3 |
rtp的报文类型和格式
rtp的pt值指定了这个rtp包写到的载荷类型，rtp pt类型分为固定的和动态的，7bit的pt值可以支持2^7 种；
静态固定类型：0-95
https://en.wikipedia.org/wiki/RTP_payload_formats
截取一部分展示:
动态的类型：
96-127
什么叫动态的类型？其实是在rtc信令交互阶段，如sdp，会传递信息，指定支持的pt类型，这个时候就是动态指定了。
例如：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17Example (SDP excerpt):
m=audio 49200 RTP/AVP 97 98 99 100 101 102 //这里就是指定的pt值，下面是对每个pt值对应的协议类型名做指定
a=mid:foo
a=rtpmap:97 G711/8000
a=rtpmap:98 LPC/8000
a=rtpmap:99 OPUS/48000/1
a=rtpmap:100 RED/8000/1
a=rtpmap:101 CN/8000
a=rtpmap:102 telephone-event/8000
a=fmtp:99 useinbandfec=1; usedtx=0
a=fmtp:100 97/98
a=fmtp:102 0-15
a=ptime:20
a=maxptime:40
a=rid:5 send pt=99,102;max-br=64000
a=rid:6 send pt=100,97,101,102常见
- 视频媒体:
eg: rtp封装h264:
https://datatracker.ietf.org/doc/html/rfc6184
①single NAL unit packet 单包（1个RTP包：1个NALU）
②aggregation packets 聚合(组合)包（1个RTP包：多个NALU，提高传输效率），需要解包时在重组。
①STAP (Single-time aggregation packet)
STAP-A
STAP-B
② MTAP (Multi-time aggregation packet)
MTAP16
MTAP24
③Fragmentation Unit 拆包处理【一个NALU→多包 NALU＞最大传输单元MTU】
FU-A //非交错模式
FU-B //交错模式
方式1 ： 单个nalu封装在一个rtp包中：即开头1个字节表示NAL单元类型，接着1个或多个聚合单元，后面是可选的RTP填充。方式2： 组合封包，即一个RTP多个NALU :1
2
3
4
5
6
7
8
9
10
11
12
130 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NRI| Type | |
+-+-+-+-+-+-+-+-+ |
| |
| Bytes 2..n of a single NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. RTP payload format for single NAL unit packet
分别有4种组合方式: STAP-A, STAP-B, MTAP16, MTAP24.那么这里的类型值分别是 24, 25, 26 以及 27。1
2
3
4
5
6
7
8
9
10
11
12
130 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: |
+-+-+-+-+-+-+-+-+ |
| |
| single-time aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Payload format for STAP-A
方式3： 一个NALU有多个RTP ,即一个NALU跨越了多个RTP；多RTP一NALU，这种fu-a也适合带多个nalu,但是最后一个分片的情况(见srs的封装)
；https://datatracker.ietf.org/doc/html/rfc6184
- 音频媒体
- fec
red fec:如下是一个携带两个RED Header的RTP包结构：1
2
3
4
5m=audio 12345 RTP/AVP 121 0 5
a=rtpmap:121 red/8000/1
|RTP header| RED header | RED headr | RED encoding data | RED encoding data|
https://datatracker.ietf.org/doc/html/rfc2198 - rtx:
1
2
3
4
5
6
7
8
9
10
11
12rtx: pt值也是动态的， 这个是重传回复包，rtc是nack的方式，nack请求重传放在rtcp上的。
https://datatracker.ietf.org/doc/html/rfc4588
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original RTP Packet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
rtcp的报文基本格式
rtcp报文每个种类都不太一样，但基本都有一个类似的固定的头：
1 | 0 1 2 3 |
rtcp的报文类型和格式
pt值和类型：
204：application
https://tools.ietf.org/html/rfc3550#section-6.71
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
440 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| subtype | PT=APP=204 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The APP packet is intended for experimental use as new applications
and new features are developed, without requiring packet type value
registration. APP packets with unrecognized names SHOULD be ignored.
After testing and if wider use is justified, it is RECOMMENDED that
each APP packet be redefined without the subtype and name fields and
registered with IANA using an RTCP packet type.
version (V), padding (P), length:
As described for the SR packet (see Section 6.4.1).
subtype: 5 bits
May be used as a subtype to allow a set of APP packets to be
defined under one unique name, or for any application-dependent
data.
packet type (PT): 8 bits
Contains the constant 204 to identify this as an RTCP APP packet.
name: 4 octets
A name chosen by the person defining the set of APP packets to be
unique with respect to other APP packets this application might
receive. The application creator might choose to use the
application name, and then coordinate the allocation of subtype
values to others who want to define new packet types for the
application. Alternatively, it is RECOMMENDED that others choose
a name based on the entity they represent, then coordinate the use
of the name within that entity. The name is interpreted as a
sequence of four ASCII characters, with uppercase and lowercase
characters treated as distinct.
application-dependent data: variable length
Application-dependent data may or may not appear in an APP packet.
It is interpreted by the application and not RTP itself. It MUST
be a multiple of 32 bits long.200: SR 发送方报告
https://tools.ietf.org/html/rfc3550#section-6.4.11
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
1340 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=SR=200 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender | NTP timestamp, most significant word |
info +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sender report packet consists of three sections, possibly
followed by a fourth profile-specific extension section if defined.
The first section, the header, is 8 octets long. The fields have the
following meaning:
version (V): 2 bits
Identifies the version of RTP, which is the same in RTCP packets
as in RTP data packets. The version defined by this specification
is two (2).
padding (P): 1 bit
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). Padding may be needed by some encryption algorithms with
fixed block sizes. In a compound RTCP packet, padding is only
required on one individual packet because the compound packet is
encrypted as a whole for the method in Section 9.1. Thus, padding
MUST only be added to the last individual packet, and if padding
is added to that packet, the padding bit MUST be set only on that
packet. This convention aids the header validity checks described
in Appendix A.2 and allows detection of packets from some early
implementations that incorrectly set the padding bit on the first
individual packet and add padding to the last individual packet.
reception report count (RC): 5 bits
The number of reception report blocks contained in this packet. A
value of zero is valid.
packet type (PT): 8 bits
Contains the constant 200 to identify this as an RTCP SR packet.
length: 16 bits
The length of this RTCP packet in 32-bit words minus one,
including the header and any padding. (The offset of one makes
zero a valid length and avoids a possible infinite loop in
scanning a compound RTCP packet, while counting 32-bit words
avoids a validity check for a multiple of 4.)
SSRC: 32 bits
The synchronization source identifier for the originator of this
SR packet.
The second section, the sender information, is 20 octets long and is
present in every sender report packet. It summarizes the data
transmissions from this sender. The fields have the following
meaning:
NTP timestamp: 64 bits
Indicates the wallclock time (see Section 4) when this report was
sent so that it may be used in combination with timestamps
returned in reception reports from other receivers to measure
round-trip propagation to those receivers. Receivers should
expect that the measurement accuracy of the timestamp may be
limited to far less than the resolution of the NTP timestamp. The
measurement uncertainty of the timestamp is not indicated as it
may not be known. On a system that has no notion of wallclock
time but does have some system-specific clock such as "system
uptime", a sender MAY use that clock as a reference to calculate
relative NTP timestamps. It is important to choose a commonly
used clock so that if separate implementations are used to produce
the individual streams of a multimedia session, all
implementations will use the same clock. Until the year 2036,
relative and absolute timestamps will differ in the high bit so
(invalid) comparisons will show a large difference; by then one
hopes relative timestamps will no longer be needed. A sender that
has no notion of wallclock or elapsed time MAY set the NTP
timestamp to zero.
RTP timestamp: 32 bits
Corresponds to the same time as the NTP timestamp (above), but in
the same units and with the same random offset as the RTP
timestamps in data packets. This correspondence may be used for
intra- and inter-media synchronization for sources whose NTP
timestamps are synchronized, and may be used by media-independent
receivers to estimate the nominal RTP clock frequency. Note that
in most cases this timestamp will not be equal to the RTP
timestamp in any adjacent data packet. Rather, it MUST be
calculated from the corresponding NTP timestamp using the
relationship between the RTP timestamp counter and real time as
maintained by periodically checking the wallclock time at a
sampling instant.
sender's packet count: 32 bits
The total number of RTP data packets transmitted by the sender
since starting transmission up until the time this SR packet was
generated. The count SHOULD be reset if the sender changes its
SSRC identifier.
sender's octet count: 32 bits
The total number of payload octets (i.e., not including header or
padding) transmitted in RTP data packets by the sender since
starting transmission up until the time this SR packet was
generated. The count SHOULD be reset if the sender changes its
SSRC identifier. This field can be used to estimate the average
payload data rate.
....201: RR 接收方报告
https://tools.ietf.org/html/rfc3550#section-6.4.21
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
350 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P| RC | PT=RR=201 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_1 (SSRC of first source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | fraction lost | cumulative number of packets lost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extended highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
report | SSRC_2 (SSRC of second source) |
block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| profile-specific extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the receiver report (RR) packet is the same as that of
the SR packet except that the packet type field contains the constant
201 and the five words of sender information are omitted (these are
the NTP and RTP timestamps and sender's packet and octet counts).
The remaining fields have the same meaning as for the SR packet.
An empty RR packet (RC = 0) MUST be put at the head of a compound
RTCP packet when there is no data transmission or reception to
report.205，206: 表示rtcp feedback message，是一个大类：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43This is the RTCP packet type that identifies the packet as being
an RTCP FB message. Two values are defined by the IANA:
Name | Value | Brief Description
----------+-------+------------------------------------
RTPFB | 205 | Transport layer FB message
PSFB | 206 | Payload-specific FB message
基本格式：
FCI系列：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Feedback message type (FMT): 5 bits
This field identifies the type of the FB message and is
interpreted relative to the type (transport layer, payload-
specific, or application layer feedback). The values for each of
the three feedback types are defined in the respective sections
below.
对RTPFB:
FMT对应值如下：
NACK = 1,
https://tools.ietf.org/html/rfc4585#section-6.1
nack Feedback Control Information (FCI)
The Generic NACK message is identified by PT=RTPFB and FMT=1.
TMMBR = 3,
TMMBN = 4,
SR_REQ = 5,
RAMS = 6,
TLLEI = 7,
ECN = 8,
PS = 9,
TCC = 15,
https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01#section-3.1 TCC0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| FMT=15 | PT=205 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of media source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | base sequence number | packet status count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reference time | fb pkt. count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | packet chunk | packet chunk | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | packet chunk | recv delta | recv delta | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | recv delta | recv delta | zero padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits This field identifies the RTP version. The current version is 2.padding (P): 1 bit If set, the padding bit indicates that the packet
contains additional padding octets at the end that are
not part of the control information but are included in
the length field.
feedback message type (FMT): 5 bits This field identifies the type
of the FB message. It must have the value 15.
payload type (PT): 8 bits This is the RTCP packet type that
identifies the packet as being an RTCP FB message. The
value must be RTPFB = 205.
SSRC of packet sender: 32 bits The synchronization source identifier
for the originator of this packet.
SSRC of media source: 32 bits The synchronization source identifier
of the media source that this piece of feedback
information is related to. TODO: This is transport wide,
do we just pick any of the media source SSRCs?
base sequence number: 16 bits The transport-wide sequence number of
the first packet in this feedback. This number is not
necessarily increased for every feedback; in the case of
reordering it may be decreased.
packet status count: 16 bits The number of packets this feedback
contains status for, starting with the packet identified
by the base sequence number.
reference time: 24 bits Signed integer indicating an absolute
reference time in some (unknown) time base chosen by the
sender of the feedback packets. The value is to be
interpreted in multiples of 64ms. The first recv delta
in this packet is relative to the reference time. The
reference time makes it possible to calculate the delta
between feedbacks even if some feedback packets are lost,
since it always uses the same time base.
feedback packet count: 8 bits A counter incremented by one for each
feedback packet sent. Used to detect feedback packet
losses.
packet chunk: 16 bits A list of packet status chunks. These
indicate the status of a number of packets starting with
the one identified by base sequence number. See below
for details.
recv delta: 8 bits For each “packet received” status, in the packet
status chunks, a receive delta block will follow. See
details below.
1 | "sender: add global seqnum to all RTP packet sent; and remember their send time |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=15 | PT=206 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique identifier ‘R’ ‘E’ ‘M’ ‘B’ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num SSRC | BR Exp | BR Mantissa |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC feedback |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| … |
The fields V, P, SSRC, and length are defined in the RTP
specification [2], the respective meaning being summarized below:
version (V): (2 bits): This field identifies the RTP version. The
current version is 2.
padding (P) (1 bit): If set, the padding bit indicates that the
packet contains additional padding octets at the end that
are not part of the control information but are included
in the length field. Always 0.
Feedback message type (FMT) (5 bits): This field identifies the type
of the FB message and is interpreted relative to the type
(transport layer, payload- specific, or application layer
feedback). Always 15, application layer feedback
message. RFC 4585 section 6.4.
Payload type (PT) (8 bits): This is the RTCP packet type that
identifies the packet as being an RTCP FB message.
Always PSFB (206), Payload-specific FB message. RFC 4585
section 6.4.
Length (16 bits): The length of this packet in 32-bit words minus
one, including the header and any padding. This is in
line with the definition of the length field used in RTCP
sender and receiver reports [3]. RFC 4585 section 6.4.
SSRC of packet sender (32 bits): The synchronization source
identifier for the originator of this packet. RFC 4585
section 6.4.
SSRC of media source (32 bits): Always 0; this is the same
convention as in [RFC5104] section 4.2.2.2 (TMMBN).
Unique identifier (32 bits): Always ‘R’ ‘E’ ‘M’ ‘B’ (4 ASCII
characters).
Num SSRC (8 bits): Number of SSRCs in this message.
BR Exp (6 bits): The exponential scaling of the mantissa for the
maximum total media bit rate value, ignoring all packet
overhead. The value is an unsigned integer [0..63], as
in RFC 5104 section 4.2.2.1. 关键值
BR Mantissa (18 bits): The mantissa of the maximum total media bit
rate (ignoring all packet overhead) that the sender of
the REMB estimates. The BR is the estimate of the
traveled path for the SSRCs reported in this message.
The value is an unsigned integer in number of bits per
second. 关键值
SSRC feedback (32 bits) Consists of one or more SSRC entries which
this feedback message applies to.
1 | " |
202: source decription message
https://datatracker.ietf.org/doc/html/rfc3550#section-6.5203: Bye Message
https://datatracker.ietf.org/doc/html/rfc3550#section-6.6