slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
RTP/RTCP/RTSP PowerPoint Presentation
Download Presentation
RTP/RTCP/RTSP

Loading in 2 Seconds...

play fullscreen
1 / 41

RTP/RTCP/RTSP - PowerPoint PPT Presentation


  • 125 Views
  • Uploaded on

Real-Time Protocols. RTP/RTCP/RTSP. Amit Hetawal University of Delaware CISC 856 -Fall 2005. Thanks to Professor Amer . Overview. History of streaming media Streaming performance requirements Protocol stack for multimedia services Real-time transport protocol (RTP)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'RTP/RTCP/RTSP' - omar


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Real-Time Protocols

RTP/RTCP/RTSP

Amit Hetawal

University of Delaware

CISC 856 -Fall 2005

Thanks to Professor Amer

slide2

Overview

History of streaming media

Streaming performance requirements

Protocol stack for multimedia services

Real-time transport protocol (RTP)

RTP control protocol (RTCP)

Real-time streaming protocol (RTSP)

slide4

Real-time multimedia streaming

  • Real-time multimedia applications
    • Video teleconferencing
    • Internet Telephony (VoIP)
    • Internet audio, video streaming

(A-PDUs)

slide5

Streaming performance requirements

  • Sequencing

– to report PDU loss

    • to report PDU reordering
    • to perform out-of-order decoding
  • Time stamping and Buffering
    • for play out
    • for jitterand delay calculation
  • Payload type identification
    • for media interpretation
  • Error concealment –covers up errors from lost PDU by using redundancy in most-adjacent-frame
  • Quality of Service (QoS) feedback – from receiver to sender for operation adjustment
  • Rate control –sender reduces sending rate adaptively to network congestion
slide6

Ideal Timing – no jitter

30 seconds

00.00.00

00.00.10

First RTP-PDU

application

00.00.11

00.00.20

Second RTP-PDU

00.00.21

00.00.30

Third RTP-PDU

00.00.31

Send time

Play time

slide7

Reality – jitter

delay

00.00.00

00.00.10

First RTP-PDU

00.00.11

00.00.20

Second RTP-PDU

00.00.21

00.00.30

00.00.25

Third RTP-PDU

00.00.40

00.00.35

00.00.37

Fourth RTP-PDU

00.00.41

00.00.47

Send time

00.00.51

Play time

slide8

Jitter (contd.)

00.00.00

00.00.10

First RTP-PDU(0)

00.00.11

00.00.20

Second RTP-PDU(10)

00.00.21

00.00.30

00.00.18

00.00.25

00.00.28

Third RTP-PDU(20)

00.00.40

00.00.35

00.00.37

00.00.38

Fourth RTP-PDU (30)

00.00.41

00.00.47

Send time

00.00.48

00.00.51

Play time

00.00.58

slide9

Jitter (contd.)

Playback buffer

At time 00:00:18

At time 00:00:28

At time 00:00:38

slide10

Seq no.1, Tmpst 100

Seq no.2, Tmpst 200

Seq no.3, Tmpst 300

sender

receiver

silence

Seq no.4, Tmpst 600

Seq no.5, Tmpst 700

How does Sequence number and Timestamp help ?

Audio silenceexample:

  • Consider audio data
    • What should the sender do during silence?

Not send anything

  • Why might this cause problems?
  • Receiver cannot distinguish between loss and silence

Solution:

  • After receiving no PDUs for a while, next PDU received at the receiver will reflect a big jump in timestamp, but have the correct next seq. no. Thus, receiver knows what happened.
slide11

Streaming performance requirements

  • Sequencing

– to report PDU loss

    • to report PDU reordering
    • to perform out-of-order decoding
  • Time stamping and Buffering
    • for play out
    • for jitterand delay calculation
  • Payload type identification
    • for media interpretation
  • Error concealment –covers up errors from lost PDU by using redundancy in most-adjacent-frame
  • Quality of Service (QoS) feedback – from receiver to sender for operation adjustment
  • Rate control –sender reduces sending rate adaptively to network congestion
slide12

Support from transport layers

  • TCP is not used because:

TCP does retransmissions  unbounded delays

No provision for time stamping

TCP does not support multicast

TCP congestion control (slow-start) unsuitable for real-time transport

RTP + UDP usually used for multimedia services

slide14

RTP: Introduction

  • Provides end-to-end transport functions for real-time applications
    • Supports different payload types
  • All RTP and RTCP PDUs are sent to same multicast group (by all participants)
    • All RTP PDUs sent to an even-numbered UDP port, 2p
    • All RTCP PDUs sent to UDP port 2p+1
  • Does NOT provide timely delivery or other QoS guarantees
    • Relies on other protocols like RTCP and lower layers
  • Does NOT assume the underlying network is reliable and delivers PDUs in sequence
    • Uses sequence number

Application

RTP RTCP

Transport

layer

UDP

IP

Data Link

Physical

slide15

RTP Session

  • RTP sessionis sending and receiving of RTP data by a group of participants
    • Foreach participant, a session is a pair of transport addresses used to communicate with the group
  • If multiple media types are communicated by the group, the transmission of each medium constitutes a session.
slide16

RTP Synchronization Source

  • synchronization source - each source of RTP PDUs
  • Identified by a unique,randomly chosen 32-bit ID (theSSRC)
  • A host generating multiple streams within a single RTP must use a different SSRC per stream
slide18

RTP PDU Header

Sampling instant of first data octet

  • multiple PDUs can have same timestamp
  • not necessarily monotonic
  • used to synchronize different

media streams

Incremented by one for each RTP PDU:

  • PDU loss detection
  • Restore PDU sequence

Payload type

Identifies synchronization source

Identifies contributing sources

(used by mixers)

slide19

Mixer

RTP mixer - an intermediate system that receives & combines RTP PDUs of one or more RTP sessions into a new RTP PDU

  • Stream may be transcoded, special effects may be performed.
  • A mixer will typically have to define synchronization relationships between streams.Thus…
    • Sources that are mixed together become contributing sources (CSRC)
    • Mixer itself appears as a new source having a new SSRC
slide20

end system 1

from ES1: SSRC=6

from ES2: SSRC=23

from ES1: SSRC=6

transl.1

transl.2

authorized tunnel

from ES2: SSRC=23

end system 2

from ES1: SSRC=6

from ES2: SSRC=23

firewall

Translator

  • An intermediate system that…
    • Connects two or more networks
      • Multicasting through a firewall
      • Modifies stream encoding, changing the stream’s timing
      • Transparent to participants
      • SSRC’s remain intact
slide21

RTP Control Protocol (RTCP)

  • RTCP specifies report PDUs exchanged between sources and destinations of multimedia information
    • receiver reception report
    • sender report
    • source description report
  • Reports contain statistics such as the number of RTP-PDUs sent, number of RTP-PDUslost, inter-arrival jitter
  • Used by application to modify sender transmission rates and for diagnostics purposes
slide22

RTCP message types

Typically, several RTCP PDUs of different types are transmitted in a single UDP PDU

slide23

NTP Timestamp, most significant word

NTP Timestamp, least significant word

RTP Timestamp

Sender’s PDU Count

Sender’s Octet Count

Sender/Receiver report PDUs

V

P

RC

Length (16 bits)

PT=200/201  SR/RR

Header

SSRC of Sender

Sender Info

SSRC_1 (SSRC of the 1st Source)

Fraction Lost

Cumulative Number of PDU Lost

Extended Highest sequence Number Received

Report Block 1

Interarrival Jitter

Last SR (LSR)

Delay Since Last SR (DLSR)

Report Block 2

SSRC_2 (SSRC of the 2nd Source)

……

Profile-Specific Extensions

slide24

Basic header

Ethereal capture for RTP-PDU

slide25

header of SR report

sender info

receiverreport block

SDES items

Ethereal capture for RTCP-PDU

slide26

Synchronization of streams using RTCP

RTP audio

RTCP audio

RTP video

RTP video

Internetwork

  • Timestamps in RTP PDUs are tied to the individual video and audio sampling clocks
    • timestamps are not tied to the wall-clock time, or each other!
  • Each RTCP sender-report PDU contains (for most recently generated PDU in associated RTP stream):
    • The timestamp of RTP PDU
    • The wall-clock time for when PDU was created
  • Receivers can use this association to synchronize the playout of audio and video
slide27

RTCP bandwidth scaling

Problem

  • What happens when there is one sender and many receivers?
  • RTCP reports scale linearly with the number of participants and would match or exceed the amount of RTP data! More overhead than useful data!

Example

  • Suppose one sender, sending video at a rate of 2 Mbps. Then RTCP attempts to limit its traffic to 100 Kbps.
  • The 75 kbps is equally shared among receivers:
    • With R receivers, each receiver gets to send RTCP traffic at 75/R kbps.
  • Sender gets to send RTCP traffic at 25 kbps.

Solution

  • RTCP attempts to limit its traffic to 5% of the session bandwidth to ensure it can scale!
  • RTCP gives 75% of this rate to the receivers; and the remaining 25% to the sender.
slide28

Real-Time Streaming Protocol (RTSP)

  • Application layer protocol (default port 554)
  • Usually runs on RTP for stream & TCP for control
  • Provides the control channel
  • Uses out-of-band signaling
  • Usable for Live broadcasts / multicast

Also known as “Network remote control” for multi-media servers.

slide29

Web Server

web browser

HTTP

presentation descriptor

Presentation

descriptor

Web Server/Media server

RTSP

media player

pres. desc,streaming commands

RTP/RTCP

audio/video content

RTSP Overview

slide31

RTSP

server

TCP

get UDP port

data

source

UDP

RTCP

media server

media player

RTSP Session

Default port 554

RTSP SETUP

RTSP OK

RTSP PLAY

RTSP

client

RTSP OK

RTSP TEARDOWN

RTSP OK

choose

UDP port

RTP VIDEO

AV

subsystem

RTP AUDIO

slide32

Media server A

audio.example.com

Media server V

video.example.com

Client C

Web server W

-holds the media descriptors

Example:Media on demand (Unicast)

slide33

C -> W : GET/Twister.sdp HTTP/1.1

Host: www.example.com

Accept: application/sdp

W-> C : HTTP/1.0 200 OK

Content-Type: application/sdp

W

V

C-> A : SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0

Cseq:1

Transport : RTP/AVP/UDP;unicast;client_port=3056-3057

A-> C : RTSP/1.0 200 OK

Cseq:1

Session: 12345678

Transport : RTP/AVP/UDP;unicast;client_port=3056-3057

server_port=5000-5001

C

A

C->V: SETUP rtsp://video.example.com/twister/video.en RTSP/1.0

Cseq:1

Transport : RTP/AVP/UDP;unicast;client_port=3058-3059

A-> C : RTSP/1.0 200 OK

Cseq:1

Session: 23456789

Transport : RTP/AVP/UDP;unicast;client_port=3058-3059

server_port=5002-5003

RTSP Message sequence

slide34

C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0

Cseq: 2

Session: 23456789

V->C: RTSP/1.0 200 OK

Cseq: 2

Session: 23456789

RTP-Info: url=rtsp://video.example.com/twister/video;

seq=12312232;

W

V

C

A

C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0

Cseq: 2

Session: 12345678

A->C: RTSP/1.0 200 OK

Cseq: 2

Session: 12345678

RTP-Info: url=rtsp://audio.example.com/twister/audio.en;

seq=876655;

RTSP Message sequence (contd.)

slide35

C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0

Cseq: 3

Session: 12345678

A->C: RTSP/1.0 200 OK

Cseq: 3

W

V

C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0

Cseq: 3

Session: 23456789

V->C: RTSP/1.0 200 OK

Cseq: 3

C

A

RTSP Message sequence (contd.)

slide36

References

[1] B. A. Forouzan, “TCP/IP Protocol Suite”,

Third edition,

[2] H. Schulzrinne, S. Casner, R. Frederick and V.

Jacobson, "RTP: a transport protocol for real-time

applications", RFC 3550, July 2003.

[3] H. Schulzrinne, A. Rao and R. Lanphier, "Real Time

Streaming Protocol (RTSP)", RFC 2326, April 1998.

slide37

RTCP PDU 1

RTCP PDU 2

sender

report

receiver

report

receiver

report

SR

SDES

SSRC

SSRC

SSRC

SSRC

CNAME PHONE

source 2

source 3

compound PDU

(single UDP datagram)

RTCP compound PDU

slide38

RTCP PDU

sender

report

receiver

report

receiver

report

SR

SSRC

SSRC

SSRC

source 2

source 3

Example

source 1 reports, there are 2 other sources

slide39

RTCP processing in Translators

  • SR sender information : Does not generate their own sender information(most of the times), but forwards the SR PDUs received from one side to other
  • RR reception report blocks : Does not generate their own RR reports (most of the times), but forwards RR reports received from one side to another. SSRC are left intact
  • SDES : Forwards without changing the SDES info. but may filter non CNAME SDES, if bandwidth is limited
  • BYE : Forwards BYE PDU unchanged. A translator about to cease forwarding, send a BYE PDU to each connected nodes
slide40

RTCP processing in Mixers

  • SR sender information : Generates its own SR info. Because the characteristics of source stream is lost in the mix. The SR info is sent in same direction as the mixed stream
  • RR reception report blocks : Generates its own reports for sources in each cloud and sends them only to same cloud
  • SDES : Forwards without changing the SDES info. but may filter non CNAME SDES, if bandwidth is limited
  • BYE : Forwards BYE PDU unchanged. A mixer about to cease forwarding, send a BYE PDU to each connected nodes
slide41

CNAME=1

length

user and domain name

Source description PDUs

May contain:

  • a CNAME item (canonical identifier/name)
  • a NAME item (real user name)
  • an EMAIL item
  • a PHONE item
  • a LOC item (geographic location)
  • a TOOL item (application name)
  • a NOTE item (transient msg, e.g. for status)
  • a PRIV item (private extension)

Value

1

2

3

4

5

6

7

8