1. Real-Time Transport Protocol
Tung Dao Manh
Future Internet Class, 1

2. Agenda Introduction Motivation RTP outline
Fundamental design philosophies of RTP
Application-level framing
The end-to-end principle
Flexibility
Standard elements of RTP
RTP Specification
RTP Profile
RTP Payload Format
RTP Packet Format
Potential further development of RTP
Related Protocol
RTCP
Conclusion 2

3. Introduction Motivation Requirements for delivery of media stream
Examples of real-time applications:
Videoconferencing
VoIP, IP telephone system
Game online…
Real-time data: interactive audio and video
Receivers: playing out immediately and synchronously, rather than playing back
Requirements for transport protocols:
Predictable variation in network transit time
Reliable delivery of all packets 8

4. Introduction Motivation
Requirements drive the choice of transport protocols
TCP/IP
It favors reliability over timeliness, but these applications require timely delivery. Retransmissions can lead to high delay and cause delay jitter
Does not support multicast
Congestion control mechanism not suitable for audio-video (AV) media
UDP/IP
A UDP/IP-based should be suitable, provided that the variation in transit time of the network can be characterized and loss rates are acceptable. But it is:
No defined technique for synchronizing
Streams from different servers may collide
A feedback channel must be defined for quality control 8

5. Introduction Motivation
The standard real-time transport protocol was developed by the Audio-Video Transport Working Group of the IETF and first published in 1996 as RFC 1889 – A solution to these described problems. 8

6. Introduction Real-time data transport at glance 8
Encoded frames are produced
They are assigned a timestamp and a sequence number
Then, they are load into RTP packet and ready for transmission
The sender also generates periodic status reports in the form of RTCP packets to participants
The participants also send quality feedback to the sender.
Collect packets from network, and insert them into a per-sender input queue.
Packets then are passed to a channel- coding routine for loss correct.
Next, they are put into a playout-buffer, and any variation in interpacket timing caused by the network has been smoothed.
They are then grouped to form complete frames that are decoded to play out. 8

7. Introduction RTP Outline
RTP: Defines a standardized packet format for delivering audio and video over the internet.
Internet standard for real-time data
Interactive and streamed audio and video
Designed for multi-user multimedia conferencing
Provides end-to-end transport functions for real-time applications
Delay-oriented rather than loss-oriented (such as TCP) 8

8. RTP Fundamental design philosophies of RTP Application-Level Framing
A transport protocol should accept data in application-meaningful units (ADUs)
A transport protocol should expose the details of the data delivery as much as possible
The end-to-end principle
The system can pass responsibility for the correct delivery of data along that with data, meaning it relies on the lower protocols.
Intelligence is at the endpoints, not within the network (smart, network-aware endpoints and a dumb network)
Achieving flexibility
Provides a unifying framework for real-time audio/video transport, satisfying most application directly. 8

9. RTP Standard elements of RTP Framework RTP specifications RTP profiles
RTP payload formats
Optional elements 8

10. Introduction RTP Outline
A session consists of an RTP/RTCP pair of channels, containing two closely linked parts: Data + Control.
RTP to transport real-time data
RTCP: RTP control protocol
QoS monitoring and feedback
Session control
Protocol architecture: usually works over UDP/IP
Media Application
RTP IP
RTCP
UDP 8

11. Introduction
RTP Outline 8

12. Introduction RTP Outline RTP Issues: The protocol itself does not
provide mechanisms to ensure timely delivery
Relies on lower-layer protocols
prevent out-of-order delivery of packets
give any Quality of Service (QoS) Guarantee.
RTP Timestamp (TS) and Sequence Number (SN)
TS is used to order packets in correct timing order
SN detect packet loss 8

13. RTP RTP Features Multicasting Payload type identification
Time stamping
Enable timing recovery
Sequencing
Loss detection
Delivery monitoring 8

14. RTP
RTP Packet Format
|V=2|P|X| CC |M| PT | sequence number |
| timestamp |
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| (0~15 items) |
| Header extension (optional) |
| Payload (real time data) |
| |
Padding (size X 8 bits)
Padding size (8 bits)
Version (V):
Padding (P)
Extension (X)
CSRC Count (CC)
Marker (M)
Payload Type (PT)
Sequence Number
Timestamp
Synchronization Source (SSRC)
Contributing Source (CSRC) 8

15. RTP
RTP header
Version (V, 2 bits): indicate the version of the protocol (Current version is 2)
Padding (P, 1 bit): if set, last byte of payload is padding size
Extension (X, 1 bit): if set, variable-size header extension exists
CSRC Count (CC, 4 bit): number of SCRC identifiers
Marker (M, 1 bit): defined in profile, mark significant event
Payload type (7 bits): audio/video encoding scheme
Sequence number: random initial value, increase by one for each RTP packet; for loss detection and sequence restoration
SSRC: identify source; chosen randomly and locally; collision needs to be resolved
CSRC list: identifiers of contributing sources, inserted by mixer 8

16. RTP RTP header: SSRC and CSRC
All packets from a given synchronizing source (with a given SSRC identifier) will use the same timing and sequence number space to allow receivers to recreate the packet sequence
A mixer receives RTP packets from multiple sources, combines packets, makes timing adjustments, and forwards new RTP packets with a new timing sequence
All packets in the new sequence will have mixer SSRC as their synchronization source
The mixer inserts in each RTP packet header a CSRC list of the sources that contributed to this combined stream 8

17. RTP RTP header: Timestamp
Reflects sampling instance of the first byte in payload
Clock frequency depends on data type; specified in profile
Random initial value
Example: CBR audio, clock increment by 1 for each sample
Consecutive RTP packets may have same timestamp (logically generate at same instant): video packets that belong to the same frame
Timestamps of consecutive RTP packets may not increase monotonically if the data is not transmitted in the order in which it was sampled: MPEG interpolated video frames 8

18. RTP RTP header: Payload types Some examples (RFC 1890) 8 Payload type
Encoding name
Audio/Video
(A/V)
Clock rate
PCMU (mu-law G.711) A
8000 8
PCMA (A-law G.711) 26
JPEG V
90000 32
MPV (MPEG-I and MPEG II) 33
MP2T (MPEG- II transport stream) AV 8

19. RTP RTP-based networking application
RTP implementation is expected to be integrated into the application rather than as a separate module.
The use of RTP for a particular application requires other documents
Profile specification documents defines sets of payload type codes, and their mapping to payload formats
Payload format specification documents define how to carry a specific encoding
Example: MPEG2 video or ADPCM audio
RFC 1890: payload types; RFC 2250: MPEG 8

20. RTP RTP-based networking application Application RTP Socket UDP IP
RTP is part of the application and lies above the UDP socket
Application
RTP
Socket
UDP IP
Data Link
Physical 8

21. RTP RTP-based networking application Application RTP Transport UDP IP
RTP can be viewed as a sub-layer of the transport layer
Application
RTP
Transport
UDP IP
Data Link
Physical 8

22. RTCP Introduction – RTP Control Protocol Scenario
Receivers send reports
Report contains number of packets lost at receiver, inter-arrival jitter, etc.
This allows senders to adjust date rate
Jitter is an early indicator of congestion
Senders also send reports 8

23. RTCP Introduction - Goals
The control protocol, RTCP, provides for periodic reporting of reception quality, participant identification and other source description information, notification on changes in session membership, and the information needed synchronize media streams.
Identify and keep
track of participant
Canonical Name
QoS feedback
Minimal session
control information
RTCP 8

24. RTCP Packet Types Bye: End of session APP: Application specifics
SDES: Source Description
RR: Receive report
SR: Sender report
RTCP packet types 8

25. RTCP
Compound RTCP Packet 8

26. RTCP
Compound RTCP Packet 8

27. RTCP Sender report (SR) 8 SSRC: identifies source of data
Sender information blocks:
NTP timestamp: absolute time identifying when report was sent
RTP timestamp: time when packet is sent according to the clock used to send RTP data packet timestamps; used for synchronization
Sender’s packet count: Total number of packets sent since the start of session
Sender’s octet count: Total number of bytes sent since the start of session
Multiple receiver report blocks, one for each source from which this host receives packets 8

28. RTCP Receiver report (RR) 8
SSRC: identifies source whose data this block is about (who’s being reported on)
Loss fraction: fraction of packets lost since last report was sent
Cumulative number of packets lost: long-term loss since the beginning of reception
Highest sequence number received: compare losses, disconnect
Interarrival jitter: smoothed interpacket distortion
LSR: The NTP timestamp of the last sender report received from the source
DLSR: Delay between receiving the last SR from this source and sending this RR 8

29. RTCP
Round-trip delay estimation 8

30. RTCP
Intermedia synchronization 8

31. RTCP
SDES Packet Type
Source description (SDES): provide participant identification and supplementary details, such as location, emai address, etc.
The standard items are: CNAME, NAME, , PHONE, LOC, TOOL, NOTE, and PRIV.
Constant for a user, unique among all users
Providing binding across multiple medias sent by a user
Example: 8

32. RTCP Analyzing sender and receiver reports 8
Sender may modify its transmissions based on the feedback
Receivers can determine whether problems are local, regional or global
Network managers may use profile-independent monitors that receive only the RTCP packets and not the corresponding RTP data packets to evaluate the performance od their networks for multicast distribution. 8

33. RTP/RTCP Other issues 8 Collision detection and resolution
Two sources use the same SSRC
Loop detection
Security
Header compression – RFC 2508 8

34. RTP/RTCP Applications using RTP Program Capability Protocols
AOL instance messenger
Video, file transfer, PC to phone, phone to PC
SIP, RTP
iSoftPhone
Address Book Integration, Daylite CRM Integration, Call Recording, IM, Conferencing, Mulitple Providers, Simple Setup, Call transfer, 5 lines
SIP, STUN, RTP
Windows Live Messenger
Video, voice, chat, text messaging, PC to Phone
Yahoo! Messenger
SIP (using TLS) and RTP (media)
SightSpeed
video, voic , phone in, phone out, multiparty calling, conference recording, text messaging, NAT traversal, video mail
SIP,RTP,Proprietary P2P protocol 8

35. RTP/RTCP
Questions
감사합니다 & Question? 8