MET TC670 B1 Computer Science Concepts in Telecommunication Systems

1
MET TC670 B1Computer Science Concepts in
Telecommunication Systems

• Fall 2003

2
RTP/RTCP, RTSP, and RSVP

• The context
• The RTP/RTCP protocols
• The RTSP protocol
• The RSVP protocol

3
A General View of the Protocols

• Stream description SDP, SMIL...
• describe the session and content
• Stream control RTSP
• Remote control the session
• Media transport RTP
• Send data and metadata
• Resource reservation (if any!) RSVP, DiffServ
• make sure the communication path offers
  appropriate guaranties
• otherwise Best-Effort transmissions!

4
A General View of the Protocols
5
Applications

• Typically sensitive to delay, but can tolerate
  packet loss (would cause minor glitches that can
  be concealed)
• Data contains audio and video content
  (continuous media), three classes of
  applications
• Streaming
• Unidirectional Real-Time
• Interactive Real-Time

6
Applications (more)

• Streaming
• Clients request audio/video files from servers
  and pipeline reception over the network and
  display
• Interactive user can control operation (similar
  to VCR pause, resume, fast forward, rewind,
  etc.)
• Delay from client request until display start
  can be 1 to 10 seconds

7
Applications (more)

• Unidirectional Real-Time
• similar to existing TV and radio stations, but
  delivery on the network
• Non-interactive, just listen/view
• Interactive Real-Time
• Phone conversation or video conference
• More stringent delay requirement than Streaming
  and Unidirectional because of real-time nature
• Video lt 150 msec acceptable
• Audio lt 150 msec good, lt400 msec acceptable

8
Real-Time (Phone) Over IPs Best-Effort

• Internet phone applications generate packets
  during talk spurts
• Bit rate is 8 KBps, and every 20 msec, the sender
  forms a packet of 160 Bytes a header
• The coded voice information is encapsulated into
  a UDP packet and sent out some packets may be
  lost up to 20 loss is tolerable using TCP
  eliminates loss but at a considerable cost
  variance in delay FEC is sometimes used to fix
  errors and make up losses

9
Real-Time (Phone) Over IPs Best-Effort

• End-to-end delays above 400 msec cannot be
  tolerated packets that are that delayed are
  ignored at the receiver
• Delay jitter is handled by using timestamps,
  sequence numbers, and delaying playout at
  receivers either a fixed or a variable amount
• With fixed playout delay, the delay should be as
  small as possible without missing too many
  packets delay cannot exceed 400 msec

10
Internet Phone with Fixed Playout Delay
11
Adaptive Playout Delay

• Objective is to use a value for p-r that tracks
  the network delay performance as it varies during
  a phone call.
• The playout delay is computed for each talk spurt
  based on observed average delay and observed
  deviation from this average delay.
• Estimated average delay and deviation of average
  delay are computed in a manner similar to
  estimates of RTT and deviation in TCP.
• The beginning of a talk spurt is identified from
  examining the timestamps in successive and/or
  sequence numbers of chunks.

12
Recovery From Packet Loss

• Loss is in a broader sense packet never arrives
  or arrives later than its scheduled playout time.
• Since retransmission is inappropriate for Real
  Time applications, FEC or Interleaving are used
  to reduce loss impact.
• Simplest FEC scheme adds a redundant chunk made
  up of exclusive OR of a group of n chunks
  redundancy is 1/n can reconstruct if at most one
  lost chunk playout time schedule assumes a loss
  per group.

13
Recovery From Packet Loss

• Mixed quality streams are used to include
  redundant duplicates of chunks upon loss playout
  available redundant chunk, albeit a lower quality
  one.
• With one redundant chunk per chunk can recover
  from single losses.

14
What is RTP?

• Realtime Transport Protocol (RTP) is an IETF
  standard, RFC 1889.
• Primary objective stream continuous media over a
  best-effort packet-switched network in an
  interoperable way.
• Protocol requirements
• Payload Type Identification what kind of media
  are we streaming?
• Sequence Numbering to deal with lost and
  out-of-order packets.
• Timestamping to compensate for network jitter in
  packet delivery.
• Delivery Monitoring how well is the stream being
  received by the destinations?

15
What is RTP?

• RTP does not guarantee QoS (Quality of Service),
  i.e., reliable, on-time delivery of the packets
  (the underlying network is expected to do that).
• RTP typically runs on top of UDP, but the use of
  other protocols is not precluded

16
What is RTP?

• Data functions (RTP)
• Content labeling
• Source identification
• Loss detection
• Re-sequencing
• Timing
• Intra-media synchronization remove jitter with
  playout buffers
• Inter-media synchronization between audio-video

17
Typical Setup

• Uses UDP (TCP is not for real-time!!!)
• No fixed UDP port (negotiated out of band)
• UDP port for RTCP UDP port for RTP 1
• Often one media per RTP session (i.e. port pair)

18
RTP Header
0 1 2
3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
8 9 0 1 2 3 4 5 6 7 8 9 0 1 -----------
--------------------- V2P
X CC M PT sequence number
--------------------
------------
timestamp
------------------------
-------- synchronization
source (SSRC) identifier

contributing
source (CSRC) identifiers
....
----------------------
----------

• version (V) CSRC count (CC)
• padding (P) marker (M)
• extension (X) payload type (PT)

19
What is RTCP?

• Periodic transmission of control packets
• Several functions
• Feedback on the quality of data distribution
• Let everybody evaluate the number of participants
• Persistent transport-level canonical name for a
  source, CNAME
• usually user_at_host
• will not change, even if SSRC does!
• provides binding across multiple media tools for
  a single user

20
RTCP Packets

• Five RTCP packets
• SR sender reports
• tx and rx statistics from active senders
• RR receiver reports
• rx statistics from other participants, or from
• active senders if more than 31 sources
• SDES source description, including CNAME
• BYE explicit leave
• APP application specific extensions

21
What is RTSP?

• Real-Time Streaming Protocol (RTSP) is a standard
  defined in RFC 2326 by IETF
• Acts as a  network remote control 
• Supports the following operations
• Retrieval of a media from a server
• Invitation of a media server to a conference
• Recording of a conference

22
What is RTSP?

• Protocol design
• Text-based protocol, like HTTP
• Transport protocol independent
• Supports any session description (sdp, xml, etc.)
• Similar design as HTTP with differences yet!
• client ? server and server ? client requests
• server maintains a  session state 
• data carried out-of-band
• Works either with unicast or multicast

23
RTSP methods

• Major methods
• SETUP server allocates resources for a
• stream and starts an RTSP session
• PLAY starts data tx on a stream
• PAUSE temporarily halts a stream
• TEARDOWN free resources of the stream, no
• RTSP session on server any more
• Additional methods
• OPTIONS get available methods
• ANNOUNCE change description of media object
• DESCRIBE get low level descr. of media object
• RECORD server starts recording a stream
• REDIRECT redirect client to new server
• SET_PARAMETER device or encoding control

24
Example Media-on-demand, unicast
A
V
W
C
video server
audio server
media descr. web server
client
step 1 get description (in SDP format)
step 2 open streams with RTSP
step 3 play
step 4 teardown
25
Same Example, Another View
HTTP GET
presentation description (sdp)
SETUP
PLAY
RTP audio/video
RTCP
TEARDOWN
26
What is RSVP?

• RSVP (Reservation Protocol) is a network control
  protocol that will allow Internet applications to
  obtain special qualities-of-service for their
  data flows.
• This will generally require reserving resources
  along the data path(s).
• RSVP is a component of the future "integrated
  services" Internet, which will provide both
  best-effort and real-time qualities of service
• When an application in a host requests a specific
  QoS for its data stream, RSVP is used to deliver
  the request to each router along the path(s) of
  the data stream and to maintain router and host
  state to provide the requested service.
• Although RSVP was developed for setting up
  resource reservations, it is easily adaptable to
  transport other kinds of network control
  information along data flow paths.

27
Quality of Service

• Marking
• Different classes of traffic marked appropriately
  (DSCP marking)
• Queuing
• Different queues accordingly
• Policing
• per user, per interface, per flow (RSVP)
• Admission Control
• Is there over-subscription?
• of data (usually)
• of voice (maybe if yes need RSVP for
  admission control)

28
Admission Control RSVP

• RSVP is used to signal end-to-end (admission
  control based on bandwidth, QoS requirements)
• Per-Flow policing is rarely done in the
  core/backbone. Instead
• In the access Per flow reservation state is
  maintained Per flow policing
• At the edge of the backbone per flow policing,
  marking
• In the backbone Queuing based on marking (DSCP,
  MPLS i.e. reservation state is not maintained)

29
Quality of Service Use of RSVP
Per flow policing DSCP marking
Classify schedule based on DSCP
Diffserv Region
Backbone
Access
Access
RSVP signaling
Trust Boundary
30
RSVP Basic Functionalities

• RSVP handles heterogeneous receivers.
• Different hosts on the same multicast delivery
  tree may have different capabilities and
  therefore need different QoS.
• RSVP adapts to changing group membership as well
  as changing routes.
• For dynamic adaptability and robustness, RSVP
  maintains soft state in the routers. The only
  permanent state is in the end systems, which
  periodically send their RSVP control messages to
  refresh the router state. In the absence of
  refresh, RSVP state in routers will time out and
  be deleted.
• RSVP is not a routing protocol.
• The RSVP daemon consults the local routing
  protocol(s) to obtain routes. RSVP is designed to
  operate with existing and future unicast and
  multicast routing protocols. A host sends IGMP
  messages to join a multicast group, but it uses
  RSVP messages to reserve resources along the
  delivery path(s) from that group.

31
Summary of the Protocols

• RTP/RTCP
• RTSP
• RSVP

32
Reading (recommended)

• RTP/RTCP http//www.ietf.org/rfc/rfc1889.txt
• RTSP http//www.ietf.org/rfc/rfc2326.txt
• RSVP http//www.ietf.org/rfc/rfc2205.txt