---------------------------------------------------------------------------------------------------------------------------
Multimedia and RTP/RTCP
---------------------------------------------------------------------------------------------------------------------------
This week I was primarily going through the last
Lecture’s materials.
First of all why not to use well known TCP or UDP protocol for transferring voice and video over the internet? The Transmission Control Protocol (TCP) is the most widely used transport-level protocol in the Internet. However, there are several facts that make TCP quite unsuitable for the real-time traffic. Firstly, TCP includes an in-built retransmission mechanism, which may be useless with strict real-time constraints. Secondly, TCP is a point-to-point protocol without direct support for multicast transmission. Thirdly, there is not any timing information carried, which is needed by most real-time applications. On the other hand User Datagram Protocol (UDP), does not either include any timing information. So, a new transport level protocol, called Real Time Transport Protocol (RTP), was specified.
RTP is a real-time end-to-end transport protocol. However, considering RTP as a transport protocol may be misleading because it is mostly used upon UDP, which is also considered as a transport protocol. On the other hand, RTP is very closely coupled to the application it carries. So, RTP is best viewed as a framework that applications can use to implement a new single protocol. RTP doesn't guarantee timely delivery of packets, nor does it keep the packets in sequence. RTP gives the responsibility for recovering lost segments and resequencing of the packets for the application layer. There are a couple of benefits in doing so. The application may accept less than perfect delivery and with video or speech there usually is no time for retransmissions. Also the sender may provide, instead of retransmission, new or updated data that tries to fix the consequences of the original loss. What RTP then provides the following, which are required by most multimedia applications:
· Payload type identification
· Source identification
· Sequence numbering
· Timestamping
.
The accompanying RTP Control Protocol (RTCP) provides feedback of the quality of the data delivery and information about session participants. A RTP session usually is composed of a RTP port number (UDP port), a RTCP port number (consecutive UDP port) and the participant's IP address. The following are the packet formats of RTP and RTCP:
Round-trip delay
Receiver reports may be used to estimate the round-trip delay between sender and receiver. The receiver report includes the LSR (timestamp from the last sender report received) and DLSR (delay since last sender report received) fields, from which the sender can directly calculate the round-trip delay according the following formula, where A is the time instant when the receiver report was received by the sender.
D = A-LSR-DLSR
The middle 32-bits of NTP timestamp are copied by the receiver to LSR field and the delay since last particular sender's report is stored until a corresponding receiver report is sent.
Inter-arrival jitter
The receivers observe continuously the variance of the inter-arrival time of incoming RTP packets. An estimate for inter-arrival jitter is calculated as follows. Firstly, the difference D in packet spacing at the receiver compared to the packet spacing at the sender is calculated according to this formula,
D = (Rj-Ri)-(Sj-Si)
where R is the time of arrival and S is the RTP timestamp for a certain packet.
This delay variation value is calculated after every RTP packet. To avoid temporary fluctuations the final value for inter-arrival jitter estimate is smoothed according to the next equation
Ji = (15/16)Ji-1+(1/16)D
Packet loss
The receiver reports also contain information about the lost packets. The fraction of lost packets is defined to be the number of packets lost divided by the number of packets expected, which are calculated based on actually received packets and the highest sequence number received in RTP packets. A cumulative number of packets lost is also maintained. These packet loss measures may be used as congestion indication for the sender to reduce the application's sending rate.
Dynamic QoS Control
The feedback provided by the RTCP reports may be used to implement a flow control mechanism at the application level.
The software video codecs support this kind of adjustment well because the sending rate can be reduced easily with trade-offs in spatial resolution and quantization. Most voice codecs use fixed length frame sizes so the sending rate is easily changed only by changing the codec on the fly. The smooth switching, preferably on a frame basis, on the quality-rate scale is the main challenge when designing a variable rate speech codec. On receiving a RTCP receiver report, the sender analyses the packet loss and delay measures and classifies each receiver either as unloaded, loaded or congested. After that the sender's bandwidth is adjusted.
The adjustment is done either based on the receiver with the highest average loss rate or based on certain proportions of unloaded, loaded and congested receivers. The bad thing in the former approach is that a receiver with a low speed link may provide low quality also to all the other receivers. On the other hand, the latter approach will let some amount of congested receivers to suffer continuously. The bandwidth is adjusted using a multiplicative decrease but only an additive increase to be able to react rapidly to congestion, still being beware of too rapid increase after the congestion.