In essence, very briefly, a bit stream of audio or video real-time
data would not use TCP at all. It uses UDP over IP.
The IP layer does its usual thing: it is used to route the packet
from source to destination. In this case, that routing might be
unicast routing, from a server to a client, or multicast, from a
server to any number of clients in a multicast group, where
membership can vary over time.
The UDP layer does very little at this point. It is used to provide
error checking of the data in the packet, it provides packet length
info, and it provides source and destination Port ID numbers to
specifically identify each stream. RTP depends on these Port IDs.
In an overall philosophical sense, what RTP does is to allow
real-time media streams to be used effectively over the Internet (or
an internet) WITHOUT having to depend on any quality of service
guarantees. RTP identifies the program source(s), provides a time
stamp on the data packets of each source so the link quality can be
determined, provides a packet sequence number so the destination can
ensure that it's decoding packets in the correct order, identifies
the type of media packet being delivered.
RTCP is needed to identify the members of each session in a way a
human can understand, and it is used to provide feedback to the
source(s) so they can adjust their encoding to match the quality of
the link. So this is a dynamic function, to accommodate possibly
varying quality levels throughout a session.
What I meant was, it seems that this is a homework question and thatQuote:> RFCs 1889 and 1890 are the direct reference on RTP and the
> associated real time control protocol (RTCP). You should go to
> sources first, before asking any more questions or before taking
> anyone's word for what really goes on.
If this was not a homework question, but simply someone asking, then
I apologize profusely. My previous explanation holds, but is no
substitute for the RFC.
Ok. That is SUN's second patch to its TCP/IP stack according to the article at
www.pcweek.com. We are a predominantly 16 bit windows site but the TCP/IP
stack in use for most of our PC's is netware v.3.x. I don't know anything
about this particular stack but would like to know if it is similar to
Microsoft's or is otherwise likely to cause performance problems connecting
via TCP/IP to a Solaris 2.5 server - web, proxy mostly.
4. Scroll Bars