BLANKOM HDE-(4)264B/265B User Manual
Version 1.1 – 02-2019
Page - 46 -
techn. data are subject to change w/o notice!
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 header
+ 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
