Blankom-Encoder-EN-V3-2019-RR.docx
- 41 -
RRI 26. Februar 2019
Packet structure
UDP Header
Offsets
Octet
0
1
2
3
Octet
Bit
0 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
0
0
Source port
Destination port
4
32
Length
Checksum
The UDP header consists of 4 fields, each of which is 2 bytes (16 bits).
[1]
The use of the fields "Checksum" and "Source port" is optional in IPv4
(pink background in table). In IPv6 only the source port is optional (see below).
Source port number
This field identifies the sender's port when meaningful and should be assumed to be the port to reply to if needed. If not used, then it
should be zero. If the source host is the client, the port number is likely to be an ephemeral port number. If the source host is the
server, the port number is likely to be a well-known port number.
[4]
Destination port number
This field identifies the receiver's port and is required. Similar to source port number, if the client is the destination host then the port
number will likely be an ephemeral port number and if the destination host is the server then the port number will likely be a well-
known port number.
[4]
Length
A field that specifies the length in bytes of the UDP header and UDP data. The minimum length is 8 bytes because that is the length of
the header. The field size sets a theoretical limit of 65,535 bytes (8 byte 65,527 bytes of data) for a UDP datagram. However
the actual limit for the data length, which is imposed by the underlying
IPv4
protocol, is 65,507 bytes (65,535 − 8 byte UDP header − 20
byte
IP header
).
[4]
In IPv6
jumbograms
it is possible to have UDP packets of size greater than 65,535 bytes.
[5]
RFC 2675
specifies that the length field is set
to zero if the length of the UDP header plus UDP data is greater than 65,535.
Checksum
The
checksum
field may be used for error-checking of the header and data. This field is optional in IPv4, and mandatory in IPv6.
[6]
The
field carries all-zeros if unused.
[7]
RTP:
a part from: https://tools.ietf.org/html/rfc3550
Chapter 11:
RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP
SHOULD use an
even
destination port number and the corresponding RTCP stream SHOULD use the next higher (odd) destination port number.
For applications that take a single port number as a parameter and derive the RTP and RTCP port pair from that number, if an odd number is
supplied then the application SHOULD replace that number with the next lower (even) number to use as the base of the port pair. For
applications in which the RTP and RTCP destination port numbers are specified via explicit, separate parameters (using a signaling protocol or
other means), the application MAY disregard the restrictions that the port numbers be even/odd and consecutive although the use of an
even/odd port pair is still encouraged. The RTP and RTCP port numbers MUST NOT be the same since RTP relies on the port numbers to
demultiplex the RTP data and RTCP control streams.
In a unicast session, both participants need to identify a port pair for receiving RTP and RTCP packets. Both participants MAY use the same
port pair. A participant MUST NOT assume that the source port of the incoming RTP or RTCP packet can be used as the destination port for
outgoing RTP or RTCP packets. When RTP data packets are being sent in both directions, each participant's RTCP SR packets MUST be sent to
the port that the other participant has specified for reception of RTCP. The RTCP SR packets combine sender information for the outgoing data
plus reception report information for the incoming data. If a side is not actively sending data (see
Section
6.4
), an RTCP RR packet is sent
instead.
any port (even, not odd > 1024)
