media tools hold tremendous promise. On the minus side, it presents a colossal challenge because video communication is perhaps the most bandwidth-intensive of applications. Video communication is challenging because there are many bits in a frame of video, because the delivery of this data must be smoothly paced, and because it involves multiple participants. In the worst-case scenario, everyone wants to interact with everyone else. In such a case, each participant-pair requires a stream of synchronized audio and video. The additional traffic crowds the network and creates traffic jams. The problem of streaming media over a data network (e.g., a LAN or the Internet) has attracted a great deal of attention. User Data Protocol (UDP) offers no guarantee of packet delivery and allows packets to be dropped when the network is busy. On the other hand, Transmission Control Protocol (TCP) does guarantee delivery through the retransmission of dropped packets. However, TCP presents two essential problems. First, it introduces overhead delay that interrupts the smooth flow of media streams when congestion is present. Second, TCP retransmits dropped packets. This is valuable in text-based communications, but is a liability in streaming video. Streaming Media's pacing and sequence are sensitive; packets are only of use if Personal Conferencing they are available chronologically. Moreover, audiences hardly notice a single dropped video frame. The Internet Engineering Task Force (IETF) and, specifically, the IETF's Audio Video Transport Working Group has developed protocols to deal with time-sensitive media streams. Three of those are the Real-Time Transport Protocol (RTP), the Real-Time Transport Control Protocol (RTCP), and RSVP (ReSerVation Protocol). The AVT group works to provide end-to-end network transport functions that suit applications that transmit real-time data (streaming media) via multicast (one-to- many) or unicast (one-to-one) services. In the IETF Request for Comments (RFC) 1889, the RTP described RTP: A Tran