ta and examine the header's timing and sequence information. Using this information the application performs sequencing, synchronization, and duplicate packet elimination. The result is a coherent media stream within which varying degrees of network latency are compensated. The application may also use RTP payload information (also included in the header) to select a codec to be used for the exchange (e.g., MPEG or H.261). The Future of RTP RTP is being integrated into many video communication and audio products. One of its shortcomings is that it is limited to IP networks. On the other hand, IP seems to be the direction in which the networking world is headed. Still, no single Real-Time protocol has emerged as the industry standard. Nevertheless, RTP has gained a tremendous amount of attention as is demonstrated by the proliferation of RTP based IETF drafts: RFC 2032: Describes a scheme to packetize an H.261 video stream for transport using RTP with any of the underlying protocols that carry RTP. RFC 2190: Specifies the payload format for encapsulating an H.263 bitstream in the RTP. Three modes are defined for the H.263 payload header. An RTP packet can use one of the three modes for H.263 video streams depending on the desired network packet size and H.263 encoding options employed. The shortest H.263 payload header (mode A) supports fragmentation at Group of Block (GOB) boundaries. The long H.263 payload headers (mode B and C) support fragmentation at Macroblock boundaries. RFC 2198: Describes a payload format for use with RTP, version 2, for encoding Standards for Conferencing over IP Networks redundant audio data. The primary motivation for the scheme is the development of audio conferencing tools for use with lossy packet networks such as the Internet MBONE, although this scheme is not limited to such applications. RFC 2250: Describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP.