CP to see who is engaging in multicasts. The RTP was adapted for use in videoconferences as RFC 1890: RTP Profile for Audio and Video Conferences with Minimal Control. RFC 1890 specifies a scheme to packetize the H.261 video stream for transport over a TCP/IP network. For instance, Video Communications: The Whole Picture RTP packets identify the type of payload contained in the packet. Depending upon the type of information the packet contains, the header may be appended with a timestamp. The header can also indicate encoding methods such as whether formal or de facto standards (G.728 or H.261, or MPEG) define the format of the media stream. The specification outlines the ports that are to be used for each payload encoding type and the port's clock rate. It also, on a per-port basis, defines whether the media stream consists of audio, video, or audio/video components and, when audio is present, how many channels are in use. Another critical protocol for video communication over the Internet is RSVP, which enables a user to reserve bandwidth to provide a specified quality of service to a media stream or flow. Routers that offer RSVP support can accommodate such requests and reserve capacity for audio and video streams at a given time and day, and thereby lessen the chances that unpredictable delays will cause bothersome degradation. Once all routers have granted the reservation, the stream can move over the TCP/IP network free from frame-freezes and audio break-up. The result is usable and natural voice and video, to the user's desktop. Unfortunately, the operative phrase is, "Once all routers have granted the reservation." One router in the path that is not capable of or (more likely) is not programmed to recognize RSVP voids the work of the others. In October 1996, T. Turletti and C. Huitema published RFC 2032, RTP Payload Format for H.261 Video Streams, in which they defined a way for H.261 information to be carried as payload data within the RTP protocol. The RTP payload format described in RFC 2032 specifies 