What is the complete summary of this paper

Applications Transport Protocols The best example of a media server is RTSP, the Real Time Streaming Protocol, which acts as a control protocol for an RTP (Real Time Protocol) stream, and is almost invariably (although not exclusively, as we will see below) transported on UDP. RTP essentially sequences the packets and sends them onto the net- work, and the recipient client, the media player," reassembles all the packets into sequence in a buffer before playing it to the user. Missing packets are ignored, and timestamps in the packets allow for the correct timing of the play-back, even if packets are missing. RTSP also allows the user to request a live stream from the server or to seek various places in the stream if the stream is a playback of an on-demand file. While common internally on private networks, and still used today for many IPTV installations, RTSP (which collectively refers to RTP too) has a few short-comings. Natural address translation (NAT), which allows a router with a sin- gle public IP address to then provide gateway access to multiple machines, is a common way to put enterprises or groups of computers online with a shared single Internet connection. For a number of reasons, however, UDP is quite complex to route into a NAT ted LAN. The router receives the UDP from the offsite server, but without an additional application controlling the UDP packet forwarding, the router doesn't know where (on the LAN) to forward the packet. For this reason RTSP struggled for many years in scenarios where publishers wanted to deliver that content into enterprises and homes with more than one computer. The two major vendors during this era (1996 to 2004), Real Networks and Microsoft, had to implement "fallback strategies so that when the optimal UDP-based RTSP streams could not be received by media players inside NATted LANs the media players could then explicitly request the stream over RTSP using the "reliable Transport Control Protocol (TCP). RTSP also requires fairly specific firewall configurations, allowing RTSP requests and responses in and out of the LAN, and the resulting stream (be it TCP or UDP) to "flow" into the LAN on ports, which, by default, were often closed. To receive the stream inside the LAN, home users would then be required to open up such firewalls - something that was usually beyond their expertise. For enterprise administrators, this made streaming using RTSP very much an "opt-in" process, which then meant building a business case for allowing streaming video and audio into the enterprise. Anecdotally this was, in the late 1990s, akin to "building a business case to bring a TV to work and was blocked by most network administrators. Interestingly, streaming was, in the culture of engineers of the era, seen to be something that nee its own transports. Because network bandwide was a relatively scarce commodity, optimization was required, and retransmission of lost video packets was one of the fundamental "waste of bandwidth" elements that contributed to that culture. UDP-based streaming protocols such as RTSP PNA and even MPEG-TS (over IP) were refined to ensure that in controlled network conditions the bare minimum network utilization occurred, ensuring that one user's use of a video impacted other users on the network as little as possible. Despite this collective work, there were some interesting external factors that eventually meant that by the end of the first decade of this century, less optimal methods for streaming have become the dominant players in the market