RSS
Twitter
Facebook
RTP, which provides end-to-end
delivery services for data with real-time characteristics, such as interactive
audio and video. Those services include payload
type identication, sequence
numbering, time stamping and delivery monitoring. Applications typically run
RTP on top of UDP to make use of its multiplexing and
check-sum services; both
protocols contribute parts of the transport protocol functionality. However,
RTP may be used with other suitable underlying network or transport protocols .
RTP supports data transfer to multiple destinations using
multicast distribution if
provided by the underlying network.
Note that RTP itself does not
provide any mechanism to ensure timely delivery or provide other quality-of-service
guarantees, but relies on lower-layer services to do so. It does not guarantee
delivery or prevent out-of-order delivery, nor does it assume that the
underlying network is reliable and delivers packets in sequence. The sequence numbers
included in RTP allow the receiver to reconstruct the sender's packet sequence,
but sequence numbers might also be used to determine the proper location of a
packet, for example in video decoding, without necessarily decoding packets in sequence.
RTP, consisting of two
closely-linked parts:
the real-time transport protocol
(RTP), to carry data that has real-time properties.
the RTP control protocol (RTCP),
to monitor the quality of service and to convey
information about the
participants in an on-going session. The latter aspect of RTCP may be
sufficient for \loosely controlled" sessions, i.e., where there is no
explicit membership control and set-up, but it is not necessarily intended to
support all of an application's control communication requirements. This
functionality may be fully or partially subsumed by a separate session control
protocol, which is beyond the scope of this document.
If both audio and video media are
used in a conference, they are transmitted as separate RTP sessions. That is,
separate RTP and RTCP packets are transmitted
for each medium using two
different UDP port pairs and/or multicast addresses.
There is no direct coupling at
the RTP level between the audio and video sessions, except that a user
participating in both sessions should use the same distinguished (canonical)
name in the RTCP packets for both so that the sessions can be associated. One
motivation for this separation is to allow some participants in the conference
to receive only one medium if they choose.
0 comments