RTP was developed to provide real-time service among a number of participants in a session. The latter is defined by the RTP port number, the RTCP3.4 port number, and the participant IP addresses. One of the main features of RTP is that it supports multicast connections by including a source identifier pointing to the member of the multicast groups that generated the data. It also includes a timestamp for synchronisation at the receiver, and a payload format identifier.
Identifying a series of packets as a data flow, is the first step in order to provide QoS functionality, similar to the ATM. The second step is to manage the network resources and guarantee delivery within QoS constraints, such as throughput and delay. This is accomplished by the Resource ReserVation Protocol (RSVP), which permits applications to reserve resources for an IP packet flow without establishing an explicit connection [Bra97b]. RSVP supports multicast efficiently by making the receivers responsible for requesting and reserving resources according to their QoS requirements.
With the development of the above mechanisms, it has become possible to the IETF to define classes of service for the Internet, which are roughly in line with those developed for ATM and presented in the previous paragraph. The most important of these are controlled-load service and guaranteed service. The former does not guarantee bandwidth or delay, as the latter does, but relies on admission control functions to avoid network overload and congestion [Bra97b]. It targets adaptive real-time video applications, while guaranteed service is more suitable for applications with hard delay requirements.
