An%20Introduction%20to%20the%20Real-time%20Transport%20Protocol%20(RTP)

1
An Introduction to the Real-time Transport
Protocol (RTP)

• Ye Xia
• WebTP Meeting
• 12/12/00

2
Transport Functions

• Application Support
• Reliability control loss recover, in-sequence
  delivery, etc.
• Network Control
• Congestion control, rate allocation, etc
• The distinction between the two is not sharp.
• Rate allocation and scheduling can be viewed as
  part of either one above.
• This dual view arises when we contemplate
  traditional transports TCP and UDP

3
Violation of the Old View Leads to New Ideas
Application-Specific Support
Network Adaptation By Application
User Space
Application Support
General Application Support
Kernel Space
Network Control
Network Control
Monolithic Transport
RTP-like Arrangement
4
Fine-grained Application Support

• In monolithic transport, application support
  function needs to be general. Why?
• Transport sits in the kernel. Hard to modify.
• API needs to be stable.
• The philosophy of some transport designers
  transport should have sufficient generality.
• How to accommodate specific applications needs?
• Build complex logic into the (monolithic)
  transport. But should not be overly ambitious.

5
WebTP - Current

• WebTP is still monolithic
• Some trade-off of programmability with
  efficiency, but may be justifiable.
• The key is to make the user-IP path fast.

Application Support
User Space
Network Control
Kernel Space
IP
6
Overview of RTP

• Provides end-to-end delivery services for
  real-time traffic interactive audio and video
• Payload identification, sequence numbering,
  timestamping and delivery monitoring
• Runs on top of UDP, and less often, TCP.
• RTP does not guarantee delivery or prevent
  out-of-order delivery.
• Primarily designed to support multiparty
  multimedia conferences, typically assumes IP
  multicast.

7
Overview Cont.

• The protocol has two parts.
• RTP carry real-time data
• RTP control protocol (RTCP) monitor the quality
  of service and to convey information about the
  participants.
• Principles of application level framing and
  integrated layer processing.
• Is malleable to provide application specific
  info.
• Is typically integrated into the application
  processing.
• Protocol is deliberately not complete. It only
  contains the common functions.
• A complete specification for an application also
  includes a profile and a payload format document.

8
Example- Multicast audio conference

• Need a multicast address and a pair of ports one
  for data and one for (RTCP) control.
• RTP header contains type of audio encoding (such
  as PCM). Senders can change encoding during the
  conference.
• RTP header contains timing information. Audio
  data can be played out as they are produced by
  the source.
• Senders and receivers multicast reports through
  RTCP. Packet loss ratio, delay jitter, and other
  status info can be monitored.

9
Example Audio and Video Conference

• Audio and video are transmitted using separate
  RTP sessions. (with different UDP ports and/or
  multicast addresses.)
• Each participant of both sessions can be
  identified by the same name in RTCP packets.
• The decoupling of the two sessions allows some
  participants to join only one session.

10
Example Mixers and Translators

• Mixers a RTP-level entity that receives streams
  of RTP data packets from one or more sources and
  combines them into a single stream.
• A translator forwards RTP packets from different
  sources separately.
• Mixer is like a new RTP-level source to the
  receivers.
• Translator is more transparent. Receivers can
  identify individual sources even though packets
  pass through the same translator and carry the
  translators network source address.
• Mixer can re-synchronize the incoming stream and
  generates its own timing info.

11
Translators and Mixers

• The real distinction between mixers and
  translators SSRC identifier is not changed at a
  translator, but is changed at a mixer.
• They both use a different transport address
  (network address port) at the output side.
• Multiple data packets can be combined into one.
• Uses of translators and mixers go-through
  firewalls transcoding for low-bandwidth links
  adding or removing encryption emulating
  multicast address with one or more unicast
  addresses.

12
Example Translator at Firewall
Note that UDP or TCP connections terminates at
Firewall.
On multicast Address a, port p, p1
On multicast Address b, port q, q1
Translator
Translator
Inside Firewall
Firewall
13
Some RTP Definitions

• Transport address network address port
• RTP session communications on a pair of
  transport addresses (data control)
• Synchronization source (SSRC) the source of a
  stream of RTP packets
• Identified by 32-bit SSRC identifier.
• All packets from the same SSRC form a single
  timing and sequencing space. Receivers group
  packets by SSRC for playback.
• Not dependent on network address.
• Examples all packets from a camera from a
  mixer for layered encoding transmitted on
  separate RTP sessions a single SSRC is used for
  all layers.
• A participant need not use the same SSRC for all
  RTP sessions in a multimedia session.

14
RTP Fixed Header
P Padding X Header Extension CC CSRC count M
Marker of record boundary
PT Payload type mapping can be
specified by profile of the application
Sequence number for each packet can be used
by the receiver to detect loss or restore
sequence.
15
RTP Fixed Header Cont.

• Timestamp
• Reflects sampling instant of the first byte of
  data
• Clock frequency can be specified by profile of
  payload format documents for the application.
• Example for fixed-rate audio, clock may
  increment by one for each sampling period.
• SSRC chosen randomly for each synchronization
  source with the intent that no two
  synchronization sources in the same session have
  the same SSRC.

16
Profile-Specific Modifications to the RTP Header

• Marker bit and payload type are interpreted
  according to the applications profile.
• Moreover, the byte containing them can be
  redefined by the profile.
• If a particular class of application needs
  additional functionality, the profile should
  define additional fixed fields following SSRC.
• If X bit is 1, exactly one header extension
  follows CSRC list (if present).
• Variable length
• Used to experimental purpose

17
RTCP

• Primary function is to provide feedback on the
  quality of data distribution.
• Through sender and receiver reports
• For adaptive encoding (adaptive to network
  congestion)
• Can be used to diagnose faults
• RTCP carries a persistent transport-level
  identifier for an RTP source, called canonical
  name, CNAME.
• Receivers use CNAME to keep track of each
  participant
• And to synchronize related media streams (with
  the help of NTP)
• Passes participants identification for display.

18
RTCP Packets

• SR sender reports sending and reception stat.
• RR receiver reports for reception statistics
  from multiple sources.
• SDES source description item, include CNAME
• BYE indicates end of participation
• APP application specific functions

19
Compound RTCP Packets

• A compound RTCP packet contains multiple RTCP
  packets of the previous types.
• Example

20
SR Packet
21
SR Packet Cont.

• RC receiver report count
• Length in 32-bit words 1
• NTP ts wallclock time, used to calculate RTT
• RTP ts in unit and offset of RTP ts in data
  packets. Can be used with NTP ts for inter-media
  synchronization.
• Fraction lost since the last RR or SR packet was
  sent. Short term loss ratio.
• LSR last SRT time stamp middle 32 bits of NTP
  timestamp.
• DLSR delay since last SR expressed in 1/65536
  seconds between receiving the last SR packet from
  SSRC_n and sending this report. Source SSRC_n can
  compute RTT using DLSR, LSR and the reception
  time of the report, A.
• RTT A LSR DLSR
• An applications profile can define extensions to
  SR or RR packets

22
SDES Packet
23
CNAME Item in SDES Packet

• Mandatory
• Provides a persistent identifier for a source.
• Provides a binding across multiple media used by
  one participant in a set of related RTP sessions.
  CNAME should be fixed for that participant.
• SSRC is bound to CNAME
• Example doe_at_sleepy.megacorp.com doe_at_192.0.2.89,
  etc.

24
Other Items in SDES Packet

• NAME user name
• EMAIL
• PHONE
• LOC location
• TOOL application or tool name
• NOTE notice/status

25
BYE Goodbye RTCP Packet

• Mixers should forward the BYE packet with
  SSRC/CSRC unchanged.
• Reason for leaving string field e.g., camera
  malfunction

26
APP RTCP Packet

• Subtype allows a set of APP packets to be
  defined under one unique name.
• Name unique name in the scope of one this
  application.

27
Conclusions - I

• RTP defines transport support for common
  functions of real-time applications.
• Timing information sampling period and NTP
• Synchronization source for playback
• Payload types (encoding)
• Quality reports short-term and long-term packet
  loss, and jitters.
• Participants indication CNAME, NAME, EMAIL, etc.
• Multicast distribution support
• Conversion mixers and translators
• Extensible protocol by profile payload format
  documents
• Customizable to application or application
  classes. Necessity of this feature is not clear.

28
Conclusion II

• Separation of control and data stream (analogous
  to out-band signaling)
• Data header overhead is small.
• Can accomplish complex control features.
• Complexity of the protocol/algorithm is not so
  bad, because there is little hard guarantee (It
  relies on TCP or application for hard guarantees).

29
Conclusions III

• Congestion control is not defined in baseline
  document, but may be defined by applications
  profile.
• Leads to application-specific congestion control
  or adaptation
• RTP can be considered user-space transport
  entities, but does not run as stand-alone
  process.
• Mixers and translators are stand-alone processes.
  They terminate TCP or UDP connections.

30
A View of Future Network
Layer 3 Systems
Transport System
End Systems
31
Inter-Domain Scenario
Domain C
Backbone
Domain A
Client
Edge Device
Domain B
Access Link
Fat Pipe
32
RTP Algorithms - I

• RTCP packets generation need to limit the
  control traffic
• Control traffic takes 5 of data traffic
  bandwidth (not defined)
• ¼ of the RTCP bandwidth is used by senders
• Interval between RTCP packets scales linearly
  with the number of members in the group.
• Each compound RTCP packet must include a report
  packet and a SDES packet for timely feedback.

33
RTP Algorithms - II

• SSRCs are chosen randomly and locally and can
  collide.
• Loops introduced by mixers and translators
• A translator may incorrectly forward a packet to
  the same multicast group from which it has
  received the packet.
• Parallel translators.
• Collision avoidance of SSRC and loop detection
  are entangled.

34
Example of A Profile Document
RFC1890 RTP Profile for Audio and Video
Conferences with Minimal Control.

• RTP data header
• use one marker bit
• No additional fixed fields
• No RTP header extensions are defined.
• RTCP
• No additional RTCP packet types.
• No SR/RR extensions are defined
• SDES use CNAME is sent every reporting interval,
  other items should be sent only every fifth
  reporting interval.

35
Payload Types