The combination of the IP, UDP and RTP control information adds up to a significant overhead for small media samples, particularly over low speed links, commonly in use by the domestic and small office user dialling up their Internet Service Provider at a few tens of kilobits per second. An Internet Protocol Datagram has a 20 byte header, while the UDP header is 8 bytes (source and destination ports, plus length and checksum field). The RTP header adds 12 bytes to this, making a total of 40 bytes of control for a single sample, in some cases (especially where sampling/serialising delay is a problem) as little as 20ms worth of 8KHz speech.
Luckily, by far the common case of such usage is as stated when dialling up an ISP, where the access router is connected to a high speed backbone. There is already a technique for reducing the overhead of packets in such circumstances, designed for compressing TCP/IP headers specified in RFC 1144 by Jacobson[#!ctcp!#]. Casner and Jacobson adapted this technique to RTP headers[#!crtp!#], noting certain particular differences.
The technique consists of two parts: noting fields in the packet headers that do not change over the life of a flow; and noting that there are few flows at the ``edge of the network'' so that such information can be conveyed over the first hop by a single packet, and subsequently referred to by a short ``connection identifier'', which serves to index the full state so that the first hop router can reconstruct the full Internetwork packet. In RTP, it turns out that there are also fields that change only by the same amount from each packet to the next, except in exceptional circumstances, so that this second order information can also be stored in the compression state vector at the first hop routers. Note also that this compression state is ``soft state'' in that it can be recovered simply by loss since the packet conveys enough implicit information that end-to-end checksums are still computed, and hop-wise recomputed from the state vector and from the remaining data in the compressed header. In other words, if the router resets, or the route changes, or the end system radically alters state, the invalid checksum causes a reset of the compressed state, and an exchange of a full packet re-creates the necessary state from full anew. The work is still in progress, although there are several implementations in common use, and shows a typical reduction to a header size of 3-4 bytes (better than ten-fold reduction in control overhead).