CEG 4183

1. CEG 4183 "This report was prepared for Professor L. Orozco-Barbosa in partial fulfillment of the requirements for the course ELG/CEG 4183" Title page Title page

2. Table of Content RTP Overview Bit deeper into RTP Designed for multicasting RTP Header RTP Packet Size RTP Header Compression What is really the difference Audio/Video Transmission: RTP vs. TCP RTP Use Scenario Audio and Video Conference Table of ContentsTable of Contents

3. Overview What is RTP? RTP is the Internet-standard protocol for the transport of real-time data, including audio and video. RTP is both a proposed IETF standard (RFC 1889) and an ITU standard (H.225.0). -Connection oriented and connection less -Nope RTP does not guarantee real time deliveryRTP is the Internet-standard protocol for the transport of real-time data, including audio and video. RTP is both a proposed IETF standard (RFC 1889) and an ITU standard (H.225.0). -Connection oriented and connection less -Nope RTP does not guarantee real time delivery

4. Bit deeper into RTP RTP consists of a data and a control part The data part of RTP including timing reconstruction, loss detection, security and content identification. The Control part- RTCP Source identification Support for gateways like audio and video bridges as well as multicast-to-unicast translators

5. Designed for multicasting Work well with small session and large ones Scalability problem? RTCP packet transmissions from a host. increases linearly with the group size. group size estimate, L, computed locally at each host. The interval between packet transmissions is set to scale linearly with L. effect of giving each group member (independent of group size) a fair share of some fixed RTCP packet rate to the multicast group. Problems when applied to larger groups, particularly ones whose group membership is dynamic. The principle difficulty in achieving scalability to large group sizes is the rate of RTCP packet transmissions from a host. If each host sends packets at some fixed interval, the total packet rate sent to the multicast group increases linearly with the group size, N . The RTP specification requires that end systems utilizing RTP listen to the multicast group, and count the number of distinct RTP end systems which have sent an RTCP packet. This results in a group size estimate, L, computed locally at each host. The principle difficulty in achieving scalability to large group sizes is the rate of RTCP packet transmissions from a host. If each host sends packets at some fixed interval, the total packet rate sent to the multicast group increases linearly with the group size, N . The RTP specification requires that end systems utilizing RTP listen to the multicast group, and count the number of distinct RTP end systems which have sent an RTCP packet. This results in a group size estimate, L, computed locally at each host.

6. RTP Header Sequence number: 2bytes Timestamp: 4bytes Lighter than TCP: TCP: 20 bytes RTP: 12 bytesSequence number: 2bytes Timestamp: 4bytes Lighter than TCP: TCP: 20 bytes RTP: 12 bytes

7. RTP Header con�t Version (V) � 2 bits Padding (P) � 1 bit More octets Extension (X) � 1 bit Fixed header is followed by header extension CSRC count (CC): 4 bits Number of CSRC (Contributing resources) identifiers Marker (M): 1 bit Marking significant events, ie. Frame boundaries - Padding. When set, the packet contains one or more additional padding octets at the end, which are not part of the payload. Marker: For voice packets, the marker bits indicates the beginning of a talkspurt. Beginning of talkspurts are good opportunities to adjust the playout delay at the receiver to compensate for differences between the sender and receiver clock rates as well as changes in the network delay jitter. Packets during a talkspurt need to played out continuously, while listeners generally are not sensitive to slight variations in the durations of a pause. - Padding. When set, the packet contains one or more additional padding octets at the end, which are not part of the payload. Marker: For voice packets, the marker bits indicates the beginning of a talkspurt. Beginning of talkspurts are good opportunities to adjust the playout delay at the receiver to compensate for differences between the sender and receiver clock rates as well as changes in the network delay jitter. Packets during a talkspurt need to played out continuously, while listeners generally are not sensitive to slight variations in the durations of a pause.

8. RTP Header con�t Payload type (PT): 7 bits Packet encoding format to be interpreted by Application Could be used for Mappings for Audio/Video ie. Payload type 32, MPEG2 video Receiver ignores packets with unfamiliar type Sequence number: 16 bits Timestamp: 32 bits Of first octet in data field Payload type: Identifies the format of the RTP payload and determines its interpretation by the application. A profile specifies a default static mapping of payload type codes to payload formats. Additional payload type codes may be defined dynamically through non-RTP means. Timestamp: Reflects the sampling instant of the first octet in the RTP data packet. The sampling instnt must be derived from a clock that increments monotonically and lineraly in time to allow synchronization and mitter calculations. Payload type: Identifies the format of the RTP payload and determines its interpretation by the application. A profile specifies a default static mapping of payload type codes to payload formats. Additional payload type codes may be defined dynamically through non-RTP means. Timestamp: Reflects the sampling instant of the first octet in the RTP data packet. The sampling instnt must be derived from a clock that increments monotonically and lineraly in time to allow synchronization and mitter calculations.

9. RTP Header con�t SSRC: 32 bits Identifies synchronization source Chosen by random CSRC list: 0 to 15 items, 32 bits each List of contributing sources to payload type Size specified in CC field The CSRC list identifies the contributing sources for the payload contained in this packet. The number of identifiers is given by the CC field. If there are more than 15 contributing sources, only 15 can be identified. The CSRC list identifies the contributing sources for the payload contained in this packet. The number of identifiers is given by the CC field. If there are more than 15 contributing sources, only 15 can be identified.

10. RTP Packet Size IP+UDP+RTP headers = 40 bytes At 64 Kbps PCM 20 ms = 160 Bytes overall rate = 80 Kbps RTP packet size can adjust to different bandwidth rate.RTP packet size can adjust to different bandwidth rate.

11. RTP Packet Size con�t At 8 Kbps (e.g. over modem lines) 20 ms = 20 Bytes overall rate = 10 Kbps RTP packet size can adjust to different bandwidth rate. RTP packet size can adjust to different bandwidth rate.

12. RTP Header Compression Fixed fields removal parts of the headers remain unchanged between pkts Differential encoding some fields vary in a predictive, monotonic way Re-coding combinations of fields some fields may be combined and hash coded Techniques on compressing the packet headers.Techniques on compressing the packet headers.

13. What is really the difference? RTP is a protocol framework that is deliberately not complete. Conventional protocols, additional functionality added by making the protocol more general Adding an option mechanism that would require parsing RTP is intended to be tailored through modifications and/or additions to the headers as needed. Unlike conventional protocols in which additional functions might be accommodated by making the protocol more general or by adding an option mechanism that would require parsing, RTP is intended to be tailored through modifications and/or additions to the headers as needed.Unlike conventional protocols in which additional functions might be accommodated by making the protocol more general or by adding an option mechanism that would require parsing, RTP is intended to be tailored through modifications and/or additions to the headers as needed.

14. Audio/Video Transmission:RTP vs. TCP The RTP is preferred over TCP because of following advantages: Dealing with unreliable connections Multicast capability Lack of congestion control (ie. no slow start) For real-time delivery of audio and video, TCP and other reliable transport protocols such as XTP are inappropriate. The three main reasons are: Reliable transmission is inappropriate for delay-sensitive data such as real-time audio and video. By the time the sender has discovered the missing packet and retransmitted it, at least one round-trip time, likely more, has elapsed. The receiver either has to wait for the retransmission, increasing delay and incurring an audible gap in playout, or discard the retransmitted packet, defeating the TCP mechanism. Standard TCP implementations force the receiver application to wait, so that packet losses would always yield increased delay. Note that a single packet lost repeatedly could drastically increase delay, which would persist at least until the end of talkspurt. TCP cannot support multicast. The TCP congestion control mechanisms decreases the congestion window when packet losses are detected ("slow start"). Audio and video, on the other hand, have "natural" rates that cannot be suddenly decreased without starving the receiver. For example, standard PCM audio requires 64 kb/s, plus any header overhead, and cannot be delivered in less than that. Video could be more easily throttled simply by slowing the acquisition of frames at the sender when the transmitter's send buffer is full, with the corresponding delay. The correct congestion response for these media is to change the audio/video encoding, video frame rate, or video image size at the transmitter, based, for example, on feedback received through RTCP receiver report packets. For real-time delivery of audio and video, TCP and other reliable transport protocols such as XTP are inappropriate. The three main reasons are: Reliable transmission is inappropriate for delay-sensitive data such as real-time audio and video. By the time the sender has discovered the missing packet and retransmitted it, at least one round-trip time, likely more, has elapsed. The receiver either has to wait for the retransmission, increasing delay and incurring an audible gap in playout, or discard the retransmitted packet, defeating the TCP mechanism. Standard TCP implementations force the receiver application to wait, so that packet losses would always yield increased delay. Note that a single packet lost repeatedly could drastically increase delay, which would persist at least until the end of talkspurt. TCP cannot support multicast. The TCP congestion control mechanisms decreases the congestion window when packet losses are detected ("slow start"). Audio and video, on the other hand, have "natural" rates that cannot be suddenly decreased without starving the receiver. For example, standard PCM audio requires 64 kb/s, plus any header overhead, and cannot be delivered in less than that. Video could be more easily throttled simply by slowing the acquisition of frames at the sender when the transmitter's send buffer is full, with the corresponding delay. The correct congestion response for these media is to change the audio/video encoding, video frame rate, or video image size at the transmitter, based, for example, on feedback received through RTCP receiver report packets.

15. Simple Multicast Audio Conference Using the IP multicast services of the Internet for voice communications. One port is used for audio data, and other for control (RTCP) Each conference participant sends audio data in small chunks of, say, 20 ms duration Each chunk of audio data is preceded by an RTP header; RTP header and data are in turn contained in a UDP packet. The RTP header indicates what type of audio encoding is contained in each packet. senders can change the encoding during a conference RTP Use Scenarios In these examples, RTP is carried on top of IP and UDP, and follows the conventions established by the profile for audio and video specified in the companion RFC 1890 (updated by Internet-Draft draft-ietf-avt- profile-new ).In these examples, RTP is carried on top of IP and UDP, and follows the conventions established by the profile for audio and video specified in the companion RFC 1890 (updated by Internet-Draft draft-ietf-avt- profile-new ).

16. RTP Use Scenarios con�t The Internet, occasionally loses and reorders packets and delays them by variable amounts of time RTP header Timing info Sequence number members of the working group join and leave during the conference useful to know who is participating how well they are receiving each instance of the audio application in the conference periodically multicasts a reception report plus the name of its user on the RTCP (control) port. For that purpose, each instance of the audio application in the conference periodically multicasts a reception report plus the name of its user on the RTCP (control) port. The reception report indicates how well the current speaker is being received and may be used to control adaptive encodingsFor that purpose, each instance of the audio application in the conference periodically multicasts a reception report plus the name of its user on the RTCP (control) port. The reception report indicates how well the current speaker is being received and may be used to control adaptive encodings

17. Audio and Video Conference If both audio and video media are used in a conference, transmitted as separate RTP sessions RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses. There is no direct coupling at the RTP level between the audio and video sessions allow some participants in the conference to receive only one medium if they choose Synchronized playback of a source's audio and video can be achieved using timing information carried in the RTCP packets for both sessions.. If both audio and video media are used in a conference, they are transmitted as separate RTP sessions RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses. If both audio and video media are used in a conference, they are transmitted as separate RTP sessions RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses.

18. Questions What is RPT and RTCP? The data part -- RTP including timing reconstruction, loss detection, security and content identification. The Control part -- RTCP Source identification Support for gateways like audio and video bridges as well as multicast-to-unicast translators QuestionsQuestions

19. Questions continued 2) Draw the layered architecture of RPT relative to IP and Application Layers. 3) Name and describe two of the RTP Header fields. Payload type: Identifies the format of the RTP payload and determines its interpretation by the application. A profile specifies a default static mapping of payload type codes to payload formats. Additional payload type codes may be defined dynamically through non-RTP means.

20. Questions continued Timestamp: Reflects the sampling instant of the first octet in the RTP data packet. The sampling instnt must be derived from a clock that increments monotonically and lineraly in time to allow synchronization and mitter calculations. 4) Name and describe one of the RTP advantages over TCP in audio/video transferring. For real-time delivery of audio and video, TCP (reliable transport protocols) is inappropriate, retransmission of packet would cause unacceptable delay. Lack of congestion control (ie. no slow start) Low overhead

21. Questions continued 5) What makes RTP suitable for multicasting? The RTP specification requires that end systems utilizing RTP listen to the multicast group, and count the number of distinct RTP end systems which have sent an RTCP packet. This results in a group size estimate, L, computed locally at each host.

22. References Dr. Henning Schulzrinne, RTP, March 10, 2002 http://www.cs.columbia.edu/~hgs/rtp/ Schulzrinne, Casner, Frederick, Jacobson, �RTP: A transport Protocol for Real-Time Applications�, 26/02/1999 http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-rtp-new-03.txt Multicasting, by Jonathan Angel, 02/01/99 http://www.networkmagazine.com/article/NMG20000727S0026/2 CENTRE DE PHYSIQUE DES PARTICULES DE MARSEILLE ,�Transporting Audio-video over the Internet� , 05/03/2002 http://marwww.in2p3.fr/Jinfo/Fluckiger_IN2P3_Informatics_Days_Part3.pdf RTP Header, by protocols.com, 05/03/2002 http://www.protocols.com/voip/rtp_header.htm Professor Keith W. Ross ,�RTP header�, 05/03/2002 http://www.eurecom.fr/~ross/streaming/sld025.htm ReferencesReferences