User Manual professional h.264 & MPEG2 encoder MPE-4000
MPE-4000-MPEG-encoder-manual-RR-03-2018.docx
Page 42 / 44
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
