Voice in Packets RTP RTCP Header Compression Playout

Voice in Packets: RTP, RTCP, Header Compression, Playout Algorithms, Terminal Requirements and Implementations Jani Lakkakorpi S-38. 130 Licentiate Course on Telecommunications Technology April 6, 2001

Problems with Voice over IP IP Cloud 24 60 Sent packets Received packets Synchronized packets Time z Received packet stream has to be playout buffered in order to restore the original packet spacing (and possibly packet order). z The large overhead in small Vo. IP packets. y For example: 24 bytes of payload (G. 723. 1) and 60 bytes of overhead (RTP/UDP/IPv 6) y Header compression is necessary to reduce delay on slow links. z Terminal requirements usually grow with the voice compression ratio.

RTP and RTCP z Real-Time Transport Protocol (RTP) provides end-to-end transport functions for applications that transmit real time data, such as Vo. IP. z RTP does not provide any Quality of Service guarantees but it is only responsible of synchronizing the received packets. y Timestamps and sequence numbers. z Real-Time Control Protocol (RTCP) gives feedback on the quality of data transmission and information about participants of the session. z RFC 1889

RTP Header (1) V PX CC M PT Sequence Number Timestamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifiers. . . Profile-specific Extensions z Version (V, 2 bits) y RFC 1889: V=2. z Padding (P, 1 bit) y If P=1, padding octets at the end of the payload. Last payload octet contains the number of padding octets. z Extension (X, 1 bit) y If X=1, fixed header is followed by extensions (RFC 1889). z CSRC Count (CC, 4 bits) y The number of contributing source identifiers.

RTP Header (2) V PX CC M PT Sequence Number Timestamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifiers. . . Profile-specific Extensions z Marker (M, 1 bit) y Marks significant events such as first packets in talkspurts. z Payload Type (PT, 7 bits) y The format of RTP payload. z Sequence Number (16 bits) y Starts from a random value and is incremented by one for each sent packet. y Used by the receiver to detect packet losses and to restore original packet sequence.

RTP Header (3) V PX CC M PT Sequence Number Timestamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifiers. . . Profile-specific Extensions z Timestamp (32 bits) y The sampling instant of the first payload octet. y Clock frequency defined for each payload type, and the clock is initialized with a random value. z SSRC (32 bits) y Identifies the synchronization source. y Randomly chosen. z CSRC list (0… 15 items, 32 bits each) y Identifies the contributing sources for the payload of this packet. y Inserted by mixers.

RTCP z RTCP provides feedback on the quality of data distribution. z RTCP packet types: y Sender Report (SR) contains transmission and reception statistics for active senders. y Receiver Report (RR) contains reception statistics for participants that are not active senders. y Source Description Items (SDES) describe various parameters about the source. y BYE packet is sent when participant leaves the session. y APP: Application specific functions.

RTCP Header: Sender Report (1) V P RC PT=SR=200 Length SSRC of Sender NTP Timestamp, Most Significant Word NTP Timestamp, Least Significant Word RTP Timestamp Sender's Packet Count Sender's Octet Count SSRC_n Fraction Lost Cumulative Number of Packets Lost Extended Highest Sequence Number Received Interarrival Jitter Last SR Timestamp Delay Since Last SR … Profile-specific Extensions z Version (V, 2 bits) y RFC 1889: 2. z Padding (P, 1 bit) y If P=1, padding octets at the end. z Reception Report Count (RC, 5 bits) y The number of report blocks in this report. z Packet Type (PT, 8 bits) y Sender Report: 200. z Length (16 bits) y Includes header & padding. z SSRC (32 bits) y Synchronization source ID of the originator of this report.

RTCP Header: Sender Report (2), Sender Information Section (Only present in SRs) V P RC PT=SR=200 Length SSRC of Sender NTP Timestamp, Most Significant Word NTP Timestamp, Least Significant Word RTP Timestamp Sender's Packet Count Sender's Octet Count SSRC_n Fraction Lost Cumulative Number of Packets Lost Extended Highest Sequence Number Received Interarrival Jitter Last SR Timestamp Delay Since Last SR … Profile-specific Extensions z NTP Timestamp (64 bits) y The wallclock time when this report was sent. z RTP Timestamp (32 bits) y Represents the same time as the NTP timestamp, but with the same units and random offset as in the timestamps of RTP packets. y May be used for synchronization. z Sender's Packet Count (32 bits) y From the start of transmission until the time this report was generated. z Sender's Octet Count (32 bits) y Only payload included.

RTCP Header: Sender Report (3), Reception Report Blocks V P RC PT=SR=200 Length SSRC of Sender NTP Timestamp, Most Significant Word NTP Timestamp, Least Significant Word RTP Timestamp Sender's Packet Count Sender's Octet Count SSRC_n Fraction Lost Cumulative Number of Packets Lost Extended Highest Sequence Number Received Interarrival Jitter Last SR Timestamp Delay Since Last SR … Profile-specific Extensions z One block for each source that we have heard of since the last SR/RR. z SSRC_n (32 bits) y Synchronization source ID of the source that we are reporting about. z Fraction Lost (8 bits) z Cumulative Number of Packets Lost (24 bits) y Since the beginning of reception. z Extended Highest Sequence Number Received (32 bits) y The highest sequence number received in an RTP packet & the corresponding count of sequence number cycles.

RTCP Header: Sender Report (4), Reception Report Blocks V P RC PT=SR=200 Length SSRC of Sender NTP Timestamp, Most Significant Word NTP Timestamp, Least Significant Word RTP Timestamp Sender's Packet Count Sender's Octet Count SSRC_n Fraction Lost Cumulative Number of Packets Lost Extended Highest Sequence Number Received Interarrival Jitter Last SR Timestamp Delay Since Last SR … Profile-specific Extensions z Interarrival Jitter (32 bits) y An estimate of the variance of the RTP packet interarrival time. z Last SR Timestamp (LSR, 32 bits) y The middle 32 bits of the NTP timestamp from the most recent RTCP sender report issued by SSRC_n. If no sender report has been received yet, this field is set to zero. z Delay Since Last SR (32 bits) y The sender of this last SR can use it to compute the round trip time together with the last SR timestamp.

Playout Algorithms (1) z In most packet audio applications, the receiving host has to buffer packets in order to compensate for variable network delay. y Playout delay can be constant or adaptively adjusted. z Adaptive playout delay can be either per-talkspurt or per-packet based: y In the former approach, playout delay remains constant throughout the talkspurt and the adjustments are done between talkspurts. y The latter approach introduces gaps in speech not suitable for Vo. IP. z There is a tradeoff between packet playout delay and packet playout loss. y If constant playout delay is too short or adaptive algorithm reacts slowly to delay "spikes", packets are lost.

Playout Algorithms (2) z Here we present a simple algorithm for adaptive playout delay adjustment: y For each received packet (except the first one), waiting time in the playout buffer is calculated with the following formula: Twait = (Time. Stampi - Time. Stampi-1) - (Received. Ati - Play. Ati-1) x If the result is negative, packet has arrived too late and it is discarded. Otherwise, packet is played out at: Play. Ati = Received. Ati + Twait, i y Whenever playout delay is adjusted, it will be the maximum of the initial playout delay and the current playout delay subtracted by the minimum T wait of the latest measurement period. y The following events trigger the delay adjustment process: x If N or more packets among the last M packets (measurement period) arrive late, playout delay is adjusted upwards at the next talkspurt. x Similarly, if M successive packets have been received all in time, playout delay is adjusted downwards at the next talkspurt.

Playout Algorithms (3) z Example: y First packet of the connection arrives at 0 ms. It has Sent packets a timestamp of 10 ms. Waiting time for the first TS=70 TS=40 TS=10 packet is set to, for example, 30 ms. (We don't assume that the sender and receiver clocks would be synchronized. ) Received packets y Second packet of the connection arrives at 35 ms. It T=35 T=0 has a timestamp of 40 ms. Waiting time is calculated T=80 in the following way: T=90 T=60 T=30 Twait = (40 - 10) - (35 - 30) = 25 ms. y Third packet of the connection arrives at 80 ms. It Synchronized packets has a timestamp of 70 ms. Waiting time is calculated in the following way: Twait = (70 - 40) - (80 - 60) = 10 ms.

Playout Algorithms (4) z Example (continued): y Too many packets have been lost during last measurement period It is time to adjust delay: x Let's assume that minimum Twait of the latest measurement period is -5 ms. x We subtract this value from the waiting time of first packet of next talkspurt: Twait = (Time. Stampi - Time. Stampi-1) - (Received. Ati - Play. Ati-1) - (-5 ms). x Example values: Twait = (3020 - 2000) - (3030 - 2020) - (-5 ms) = 10 + 5 = 15 ms.

Header Compression z TCP header compression: RFC 1144. z RTP header compression: RFC 2508. y Basic idea: Since the difference in successive RTP packets is often constant, it is enough to convey an indication that the second-order difference was zero. Next packet header can thus be constructed from the previous one by adding the first-order differences. z Other proposals: ROCCO (Ericsson), ACE (Nokia). y Should perform slightly better than the mechanism described in RFC 2508.

RTP/UDP/IP Header Compression (1) Version IHL Type of Service Packet ID Time to Live Total Length Flags Protocol Fragment Offset Header Checksum Source Address Destination Address z In IPv 4 header, only the total length, packet ID, and header checksum fields typically change. y Total length can be excluded (provided by the link layer). y Header checksum can be dropped, too. Link layer provides good error detection. y Changes in packet ID are transmitted. Usually packet ID is incremented by one for each packet. z In IPv 6 base header, only the payload field changes.

RTP/UDP/IP Header Compression (2) Source Port Destination Port Length Checksum z In UDP header, port numbers are not likely to change during Vo. IP connection. z Length field is redundant with the IP total length field and the length indicated by the link layer. z If source generates UDP checksums, they must be sent intact in order to preserve lossless compression.

RTP/UDP/IP Header Compression (3) V PX CC M PT Sequence Number Timestamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifiers. . . Profile-specific Extensions z In most RTP headers, only the sequence number and timestamp change from packet to packet. y If packets are not lost and they arrive in correct order, the sequence number is incremented by one for each packet. y For Vo. IP packets of constant duration, the timestamp is incremented by the number of sample periods conveyed in each packet. z One bit in the compressed header is reserved for the marker bit. y If treated as a constant field, the compression would become inefficient.

Some Terminal Requirements and Implementations z All terminals that support real time voice must have considerable processing capacity. y The computational requirements of voice codecs increase with the compression ratio. z Microsoft Net. Meeting is popular video conferencing tool. y Pentium 90 processor or higher, 24 MB of RAM. z Vocal. Tec Internet Phone Lite is mainly targeted for pure voice connections. y Pentium 75 processor or higher.

Conclusions z RTP/RTCP protocol suite provides the means for sending packetized voice by introducing timestamps and sequence numbers. z Playout buffering is needed to re-synchronize the received voice stream. z RTP/UDP/IP overhead problem can be solved by efficient header compression. z Terminals that support real time interactive voice must have considerable processing power. The computational requirements of the voice codecs typically increase with the voice compression ratio.