Media Transport in Packet Networks
Anjali Agarwal
Why Not Use TCP?
Four problems
» No need for 100% reliability
» Slow start
» Retransmissiondelay
» Window backoff
» N participants -> N*N connections » So use UDP and IP multicast
Anjali Agarwal 2
Need for RTP
Loss, out of order: sequence number
Loss, jitter: timestamp
Source/payload identification
Rate control: QoS feedback
RTP provides functions to support these requirements for many real-time applications
Anjali Agarwal 3
RTP: de facto standard
End-to-end transport of real-time data, such as audio and video; and data for non-real-time applications
Does not guarantee QoS
Does not address resource reservation along the path of a connection
Requirestheuseofsignalingprotocoltosetuptheconnectionand
negotiate media format to be used
RTPisenhancedwithRTCPwhichispartoftheRTPspecification
» RTCP provides for end-to-end monitoring of data delivery and QoS
Independent of the underlying transport and network layers
» most commonly used on UDP
RTP assigned an even UDP port number RTCP assigned the next higher UDP port (odd)
Supportsmultipledestinationsifnetworksupportsmulticastdistribution Anjali Agarwal 4
Anjali Agarwal 5
Packet based delivery – basic issues
Store and forward handling in routers – delay
» IP switching (hardware technology) to reduce intermediate
packet delays
High protocol overhead (RTP over UDP over IP over ATM) – extra bandwidth requirement
To achieve bandwidth savings –
» Header compression often prescribed and used
» statistical multiplexing – mixing of voice and data packets
Problem – not backward compatible with existing routers » new router designs
Anjali Agarwal 6
Packet based delivery – basic issues
Uncompressed RTP/UDP/IP header = 12+8+20 = 40 bytes
Encapsulation overhead for ATM (RFC1483) = 8 bytes
Payload = N bytes per packet
» this represents an entire ATM cell of 48 bytes + an ATM header of 5 bytes before first byte of payload is transmitted
Minimum of 2 ATM cells is required for a single voice sample
Using header compression (RFC2809) 40 bytes is reduced to 2 bytes
Anjali Agarwal 7
Voice over RTP bandwidth calculations
Payload format
Nominal rate
Packet rate (ms)
Payload size (bytes)
Required BW (Kbps) uncompressed compressed
G.711
64 Kbps
20
160
80
64.8
G.711
10
80
96
65.6
G.729
8 Kbps
20
20
24
8.8
G.729
10
10
40
9.6
Packet rate is the frequency with which packets are formed and transmitted – either 10 ms or 20 ms for most applications
Bits per 20 ms packetization interval for G.711 over RTP/UDP/IP/Encaps/AAL5 = minimum 5 ATM cells = 53*5 bytes = 2120 bits
Anjali Agarwal 8
Compressed packet headers –
additional computational requirements in
intermediate routing nodes
major issue with user multiplexing and stream mixing at intermediate points
header expansion and interpretation at intermediate nodes can be lengthy process – adds to end-to-end delay
Anjali Agarwal 9
RTP packet
Anjali Agarwal 10
RTP packet header
Version (V, 2 bits)
Padding (P, 1 bit) – for encryption with fixed block sizes
if set, last byte of the padding contains a count of how many padding bytes should be ignored
Extension (X, 1 bit) –
if set, the fixed header is followed by exactly one header extension (2 bytes) to pass control information not to be interpreted by intermediate nodes
CSRC count (CC, 4 bits) – for mixers
number of contributing sources to this packet if only one SSRC in the stream, CC = 0
Anjali Agarwal 11
RTP packet header
Marker (M, 1 bit) – to mark frame boundaries
signifies the beginning/end of a talk spurt (to begin playout of
comfort noise), or end of a video frame.
Payload Type (PT, 7 bits) – format of RTP payload
(e.g. G723)
once a session is set up, a sender cannot use different RTP payloads during the session
Sequence Number (16 bits) – +1 for each packet
used by receiver to detect packet loss and to restore packet sequence packet reordering very hard to do – costs in voice/video quality
Anjali Agarwal 12
RTP packet header
Timestamp (32 bits) – random starting value
increments by one for each sampling period for fixed-rate audio
If an audio application reads blocks covering 160 sampling periods from the input device, the timestamp would be increased by 160 for each such block
SSRC (32 bits) – identifies synchronization source (sender) value chosen randomly – no two senders have same SSRC identifier collisions resolved by simple mechanisms in RTP
CSRC list (0 to 15 items, 32 bits each) –
identifies contributing sources for payload contained in this packet
used for correct source identification when payloads played out at endpoint
Anjali Agarwal 13
Mixers and Translators
Anjali Agarwal 14
Anjali Agarwal 15
Anjali Agarwal 16
IMPLEMENTATIONS OF RTP OVER THE INTERNET
“Internet telephones” (usually for PCs) available using proprietary audio coding and protocols, meant for point-to-point connections:
Speak Freely for Unix and Windows Vocaltec Internet Phone)
SoftFone by SilverSoft
Digiphone
Quarterdeck
InternetTelephoneCompany
Telescape Intercom by Telescape IBM Internet Connection Phone
CuSeeMe (for Windows PC and the Macintosh)
IRIS
Lucent 4111 Multifunctional DCP
Voice Terminal
Audio/video directly over ATM: Nemesys
FreeVue audio and video
NVAT
Ericsson LAN Phone
RealAudio (Microsoft Windows only) AudioSoft
VDO
Anjali Agarwal 17
Real Time Control Protocol (RTCP)
Based on periodic transmission of control packets to all
to convey end-to-end information about the quality of the session to each participant
» like packet delay, jitter, packets received and lost are valuable to access network health in real-time
participants
RTP and RTCP may or may not be routed on the same end- to-end path
Anjali Agarwal 18
RTCP packet format
SR: Sender Report
» for transmission and reception statistics from active sender
participants
RR: Receiver Report
» for reception statistics from not active senders
ietf-avt-rtp-new-03.txt (work in progress)
» suggests 5%of session bandwidth be allocated for RTCP packets
1.25% go to senders
3.75% be allocated to receivers
Anjali Agarwal 19
Anjali Agarwal 20
RTCP Sender Report
SSRC of sender: identifies sending source of SR
NTPtimestamp:whenreportwassend
RTPtimestamp:correspondingRTPtime
Sender’s packet count: total RTP packets sent
Sender’soctetcount:totaloctetssent
rc:numberofreceptionreportcounts(max32)forwhichstatisticsare
included in the packet
FL:fractionofpacketslostsincelastSRwassend
Cumulative packets lost: since beginning of session
HighestsequencenumberreceivedfromSSRCn
interarrival jitter as measured at the receiver
LSR:timelastSRheard
DLSR: delay since last SR
Anjali Agarwal 21
RTCP Receiver Report
Conveys identical information as SR except sender information
An endpoint can send RR or SR but SR contain overall packet and byte counts not reported in RR.
Anjali Agarwal 22
Anjali Agarwal 23
SDES: Source DEScription
» binds SSRC in RTP with actual user identification user’s name, email address, login ID
optional items as telephone #, user location
» send at beginning of the session to explicitly identify each participant
BYE: ends user participation in a call
» tells all participants that sending user is departing » should contain the reason for statistics
APP: application specific RTCP packet » none yet (work in progress)
RTCP packet format
Anjali Agarwal 24
RTCP SDES packets
binds an SSRC to sender’s real identification
up to 32 participants identified
SDES items contain item id, length of item, and item itself
Only 8 SDES items currently proposed
Anjali Agarwal 25
Anjali Agarwal 26
Anjali Agarwal 27
Bye packet
Anjali Agarwal 28
RTCP packet
Anjali Agarwal 29
Anjali Agarwal 30