INRIA Rhône-Alpes - Planète project 1 RTP/RTCP and RTSP multimedia protocols for the Internet Projet Planète; INRIA Rhône-Alpes [email protected]August 29 th , 2001 INRIA Rhône-Alpes - V. Roca - 2 Outline of the presentation l 1- the context l 2- the RTP/RTCP protocols l 3- the RTSP protocol l 4- selected bibliography
26
Embed
RTP/RTCP and RTSP multimedia protocols for the Internet · RTP/RTCP and RTSP multimedia protocols for the Internet Projet Planète; INRIA Rhône-Alpes ... (P) marker (M) extension
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
l 1- the contextl 2- the RTP/RTCP protocolsl 3- the RTSP protocoll 4- selected bibliography
INRIA Rhône-Alpes - V. Roca - 3
PART 1:
The context
INRIA Rhône-Alpes - V. Roca - 4
A general view of the real-time protocols
l the protocols and their application field…❍stream description: SDP, SMIL...
describe the session and content
❍stream control: RTSPremote control the session
❍media transport: RTPsend data and metadata
❍resource reservation (if any!): RSVP, DiffServmake sure the communication path offersappropriate guaranties……otherwise Best-Effort transmissions!
INRIA Rhône-Alpes - V. Roca - 5
A general view… (cont’)
l and the result…
INRIA Rhône-Alpes - V. Roca - 6
PART 2:
The RTP/RTCP protocols
l 2.1 Overviewl 2.2 RTP generalitiesl 2.3 header formatl 2.4 mixers vs. translatorsl 2.5 RTCP generalitiesl 2.6 RTP profilesl 2.7 some implementations
INRIA Rhône-Alpes - V. Roca - 7
2.1- Overview
l IETF Audio/Video Transport WG❍RTPv1 RFC 1889 (January 1996)❍RTPv2 draft-ietf-avt-rtp-new-09.txt (March 2001)
l Real-Time Protocol (RTP)❍ understand: « a framing protocol for real-time applications »
❍ does not define any QoS mechanism for real-time delivery!
l Real-Time Control Protocol (RTCP)❍ its companion control protocol, just here to get some
feedback
❍ does not guaranty anything either!
INRIA Rhône-Alpes - V. Roca - 8
Overview… (cont’)
l Design goals:❍flexible provide mechanisms, do not
dictate algorithms!
⇒ instantiations for H261, MPEG1/2/...
❍protocol neutral UDP/IP, private ATMnetworks...
❍scalable unicast, multicast, from 2 to ∞
❍separate control/data some functions may betaken over by conferencecontrol protocol (e.g. RTSP)
INRIA Rhône-Alpes - V. Roca - 9
2.2- RTP generalities
l data functions (RTP)❍content labeling
❍source identification❍loss detection❍resequecing
❍timing❍intra-media synchronization: remove jitter with
playout buffers❍inter-media synchronization: lip-synchro between
audio-video
INRIA Rhône-Alpes - V. Roca - 10
Typical use
l Usually...❍uses UDP (TCP is not for real-time!!!)❍no fixed UDP port negociated out of band❍UDP port for RTCP = UDP port for RTP + 1❍usually one media per RTP session (i.e. port pair)
INRIA Rhône-Alpes - V. Roca - 11
Time managementTwo times…
l RTP time❍random initial offset (for each stream)❍RTP timestamp present in each data packet❍increases by the time « covered » by a packet
l NTP time (or wallclock time)❍absolute time (use Network Time Protocol format)❍NTP timestamp present in each RTCP Sender
l Sequence number field❍incremented for each RTP packet
l Synchronization SouRCe (SSRC) field❍uniquely identifies the source in the session
❍chosen randomly ⇒ detect and solve collisions
l Contributing SouRCe (CSRC) and CC fields❍used by a mixer to identify the contributing
sources❍size of the list given by the CSRC Count (CC) field
INRIA Rhône-Alpes - V. Roca - 14
2.4- Mixers versus Translators
l Mixers❍combines several flows in a single new one❍use new SSRC; original SSRCs in a CSRC list❍appears as a new source
❍e.g. bandwidth reduction for dial-up networks
l Translators❍passes through the various flows separately❍keep original SSRCs
❍e.g. protocol translation, firewall
INRIA Rhône-Alpes - V. Roca - 15
Mixer❍a mixer may change the data format (coding) and
combine the streams in any manner❍example: video mixer (~MCU)
end system 1
end system 2
mixer end system 3from ES1: SSRC=6
from ES2: SSRC=23from M: SSRC=52CSRC list={6, 23}
INRIA Rhône-Alpes - V. Roca - 16
Translator❍data may pass through the translator intact or may
be encoded differently❍the identity of individual flows remains intact!❍example: going through a firewall
end system 1
end system 2
transl.1from ES1: SSRC=6
from ES2: SSRC=23transl.2
from ES2: SSRC=23from ES1: SSRC=6
authorized tunnel
firewallfrom ES2: SSRC=23from ES1: SSRC=6
INRIA Rhône-Alpes - V. Roca - 17
2.5- RTCP generalities
l periodic transmission of control packetsl several functions
❍feedback on the quality of data distribution
❍let everybody evaluate the number of participants
❍persistant transport-level canonical name for asource, CNAME
❍usually: user@host❍will not change, even if SSRC does!❍provides binding across multiple media tools for a
single user
INRIA Rhône-Alpes - V. Roca - 18
RTCP generalities… (cont’)
l Five RTCP packets❍SR sender reports
tx and rx statistics from active senders
❍RR receiver reportsrx statistics from other participants, or fromactive senders if more than 31 sources
❍SDES source description, including CNAME
❍BYE explicit leave
❍APP application specific extensions
INRIA Rhône-Alpes - V. Roca - 19
RTCP generalities… (cont’)l distribution
❍use same distribution mechanisms as datapackets (n→m multicast)
❍multiple RTCP packets can be concatenated bytranslators/mixers
⇒ compound RTCP packet
l scalability with session size❍RTCP traffic should not exceed 5% of total
session bandwidthrequires an evaluation of number of participantsRTCP tx interval = f(number of participants)
❍at least 25% of RTCP bandwidth is for sourcereports
let new receivers quickly know CNAME of sources!
INRIA Rhône-Alpes - V. Roca - 20
SR RTCP packets
l includes❍SSRC of sender identify source of data❍NTP timestamp when report was sent❍RTP timestamp corresponding RTP time❍packet count total number sent❍octet count total number sent❍followed by zero or more receiver report…
❍example:source 1 reports, there are 2 other sources
SRsenderreport
receiverreport
receiverreportSS
RC
SSR
C
SSR
C
source 2 source 3
RTCP packet
INRIA Rhône-Alpes - V. Roca - 21
RR RTCP packets
l includes❍SSRC of source identify the source to which
this RR block pertains❍fraction lost since previous RR (SR) sent
(= int(256*lost/expected))❍cumul # of packets lost long term loss❍highest seq # received compare losses❍interarrival jitter smoothed interpacket
distortion❍LSR time when last SR heard❍DLSR delay since last SR
INRIA Rhône-Alpes - V. Roca - 22
SDES RTCP packet
l 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)
INRIA Rhône-Alpes - V. Roca - 23
Example of RTCP compound packet❍aggregation of two packets (e.g. by a mixer)
SRsenderreport
receiverreport
receiverreportSS
RC
SSR
C
SSR
C
source 2 source 3
RTCP packet 1
SDES CNAME PHONE
SSR
C
RTCP packet 2
compound packet(single UDP datagram)
INRIA Rhône-Alpes - V. Roca - 24
2.6- RTP profiles
l RTP is generic… define a profile for eachtarget media!❍Example: MPEG1/2 video packetization❍must follow general guidelines
❍RFC 2736, December 1999
❍Goal:❍« every packet received must be usefull !!! »
❍Potential problems❍over standard Internet packets may be
• lost
• reordered• fragmented by IP if size > MTU (max tx unit)
INRIA Rhône-Alpes - V. Roca - 25
RTP profiles… (cont’)
l Example of what must not be done!!!❍loss multiplication effect due to bad framing
application data unit
fragment 1 fragment 2 fragment 3
application
RTP
network tx
fragment 2fragment 1
LOST
RTP
uncomplete data!!!application useless!!!
Src
Rx
INRIA Rhône-Alpes - V. Roca - 26
RTP profiles… (cont’)
l Principles❍ALF (Application Level Framing)
❍unit of transmission == unit of control❍each unit is self-sufficient and can be processed as
soon as it is received
❍an RTP/UDP/IP packet should consist of one ormore complete codec frame
❍if a codec frame size is larger than MTU, theapplication must define its own fragmentationmechanism
INRIA Rhône-Alpes - V. Roca - 27
2.7- Some implementations (by Schulzrinne)Organization product name
�Bell Labs, Columbia Univ., Massachusetts Univ. RTP LibraryVersion: 3.0 Beta (4/1997)An RTP implementations by the standard authors, source code available.http://www.bell-labs.com/topic/swdist/
�Limburgs Universitair Centrum JVOIPLIBVersion: 1.0 (11/2000)JVOIPLIB is an object-oriented Voice over IP (VoIP) library written in C++.http://lumumba.luc.ac.be/jori/jvoiplib/jvoiplib.html
�JavaSoft/Sun Microsystems Java Media FrameworkRTP application and library for audio/video session playback over IP networks.http://java.sun.com/products/java-media
� Limburgs Universitair Centrum and Universiteit Maastricht JRTPLIBVersion: 2.4 (7/2000)JRTPLIB (Jori’s RTP library) is a C++ library.http://lumumba.luc.ac.be/jori/jrtplib/jrtplib.html
�Live.com LIVE.COM Streaming MediaVersion: 1.0 (October 2000)This C++ code, distributed under a LGPL licence, forms a set of libraries that can be used within RTP/RTCP streamingapplications, or can be extended to support additional media types and codecs (in addition to MP3 audio).http://live.sourceforge.net/
�UCL Common Multimedia LibraryVersion: 1.2.8 (May 2001)The UCL common multimedia library implements a number of algorithms and protocols (including RTP) needed by a number ofour applications.http://www-mice.cs.ucl.ac.uk/multimedia/software/common/index.html
INRIA Rhône-Alpes - V. Roca - 28
PART 3:
The RTSP protocol
l 3.1 generalitiesl 3.2 an examplel 3.3 a bit more in detailsl 3.4 some implementations
INRIA Rhône-Alpes - V. Roca - 29
3.1- RTSP generalities
l IETF standard❍RFC 2326
l Real-Time Streaming Protocol❍acts as a « network remote control »
l supports the following operations:❍retrieval of a media from a server❍invitation of a media server to a conference❍recording of a conference
INRIA Rhône-Alpes - V. Roca - 30
RTSP generalities… (cont’)
l Protocol design❍text-based protocol❍transport protocol independant❍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
INRIA Rhône-Alpes - V. Roca - 31
RTSP URL
l whole presentationrtsp://media.example.com:554/twister
l a track within the presentationrtsp://media.example.com:554/twister/audio
l name hierarchy ≠ media hierarchy ≠ filehierarchy
INRIA Rhône-Alpes - V. Roca - 32
RTSP messages
l a request (client → server or server → client)
PLAY rtsp://video.example.com/twister/video RTSP/1.0
C->M: PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 3 Session: 91389234234M->C: RTSP/1.0 200 OK CSeq: 3
INRIA Rhône-Alpes - V. Roca - 48
A bit more in details: Recording
l goal❍ask a server to record an active session
l client uses ANNOUNCE and RECORDmethods❍Announce method enables the client to give (e.g.
the sdp) presentation description❍Record method enables the client to record the
presentation for a given time interval
INRIA Rhône-Alpes - V. Roca - 49
A bit more in details: Cache control
l goal❍control the way the media stream may be cached
l example of directives❍no-cache never cache❍public stream cacheable by any cache❍private don’t cache unless by private cache❍no-transform never alter the stream content❍only-if-cached e.g. play a stream only if cached❍max-stale only if expired from less than that❍min-fresh only if won’t expire after that value❍must-revalidate
INRIA Rhône-Alpes - V. Roca - 50
3.4- Some implementations (by Schulzrinne)Organization product nametype OS session description remarks
�Apple Darwin QuickTime Streaming Serverserver MacOS, unix SDP open source, full RTP/RTSP server
�Apple QuickTime 4client MacOS, Windows SDP QuickTime 4 also supports importing SDP files that describe multicasts,
with standard decoders.�
Cern Wrtp�
Columbia University rtspdserver NT, Solaris SDP no container files