Irenis BLANKOM HDE-4K5, User Manual

Page: 43 / 54

BLANKOM HDE-4K5 User Manual
Version 1.0 – 12-2018 Page - 43 -
techn. data are subject to change w/o notice!
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