Computer Networks:
Multimedia Applications
Ivan Marsic
Rutgers University
Chapter 3 – Multimedia & Real-time Applications
Multimedia & Real-time
Applications
Chapter 3
Topic:
Traffic Sources & Models
 Source Coding
 Traffic Types
 Traffic Models
 Birth and Death Processes
Source Coding vs. Channel Coding
Beans
(Redundancy = pods)
Beans
(No redundancy)
Source Coding
Beans
(Redundancy = can)
Channel Coding
Erroneous
Communication Channel
Beans
(No redundancy)
Decoding
Signal Digitalization
Source Coding – a simple example
Speech Signal Digitalization
Analog speech waveform
Sampled signal
Sampled & quantized signal
Amplitude
0.4
Time (sec)
0.007
0
0.4
Source Coding – also involves data compression (may be lossy)
What is a Traffic Source
Network
Arriving traffic
(packets)
signals
includes signal-processing
hardware and software
from another source
Traffic Source
Traffic Model for Voice Source
Idle
Call
Talk
Cumulative
Number of arrivals, A(t)
Number of departures, B(t)
Birth and Death Processes
A(t)
T2
N(t)
B(t)
T1
Time
N(t)

Time
Topic:
Delayed Playout for Jitter
Control
 Delay
 Delay Variation (Jitter)
 Jitter Buffer
How Delay Jitter Arises
(capture)
(transport)
(playout)
Network
8 7 6 5 4 3 2 1
Packet number
Source
8 6
Packets departing source
8
8
7
7
7
6
6
6
5
5
5
4
4
4
3
3
3
2
2
2
1
1
1
Time when packet departed (ms)
5
3 4
2 1
Packets arriving at receiver
8
0 20 40 60 80 100 120 140 160
7
Receiver
0 20 40 60 80 100 120
0 20 40 60 80 100 120 140 160 180 200 220 240 260
Transit delay experienced (ms)
Time when packet arrived (ms)
Solution: Delayed Playout
Playout
schedule
1
Packets
arrived
at receiver
8
Packet number
Packet arrives at receiver
7
5
4
Time
3
q = 100 ms
1
0
Talk starts
20
40
60
5
7
6 8
Packet removed from
buffer for playout
1 2 3 4 5
Missed
playout
2
4 3
Time spent
in buffer
Packets
created
at source
6
2
80
r1 = 58
0
0
0
0
0
0
0
10 12 14 16 18 20 22
p1 = 120
First packet sent: t1 = 20 ms
0
0
24 26
Time [ms]
7 8
Missed
playout
Problem & Tradeoff to Make
• How to set the playout delay value?
– Problem: Network delays change over time even
for the same endpoints
• Tradeoff:
– Prefer to set the playout delay as small as
possible for real-time applications (telephony)
because of human psychological characteristics
– But, small playout delay may cause too many
packets to miss their playout deadline
• Solution: Adaptive playout delay
Occurrence frequency
of measured RTT values
Recall from Chapter 2:
TCP Retransmission Timer Calculation
RTT distribution measured
during quiet periods
(a)
(b)
1

RTT distribution measured
during peak usage periods
2
0

0
2
1
Measured RTT value
TimeoutInterval
Cases for which the
RTO timer will expire
too early
(c)
0
Measured RTT value
Adaptive Playout
Problem: Cannot change playout delay during the speech
Solution: Change playout delay during the silence periods
… speech … silence … speech … silence … speech …
i+1
change playout delay qi+1
Play w/ playout delay qi
i
estimate playout delay qi+1
Topic:
Multicast Routing
 Reverse Path Forwarding (RPF)
Algorithm
 Spanning Tree Algorithms
Multicast Routing
(a)
Unicast
2
Source
3  1.5 Mbps

1.
5
M
bp
s
(b)
Multicast
1
Source 1  1.5 Mbps

1.
5
M
bp
s
Superimposed Shortest Paths =
Tree
Option (a)
Shortest path (Source Receiver i)
Receiver i
Source
Router m
Router n
Router m
Router n
Option (b)
Source
Shortest path (Source  Receiver j)
Receiver j
Multicast Example 3.1
A
B
R1
C
R2
R3
D
R4
E
R5
G
R7
R6
F
Multicast – Solution
R1
R2
(a)
R3
The shortest path multicast tree
R4
R5
C
R7
B
R1
D
p1
R3
Key:
Packet will be forwarded
p1
(b)
R6
E
Packet not forwarded
beyond receiving router
Packet forwarded to end host
p1
R2
R4
p2
F
G
p2
p3
R5
R7
p3
R6
p3
Multicast Example
B
D
C
E
R3
R1
R8
(a)
R4
A
R6
R2
G
Source
R5
R7
R1
(b)
R2
R3
R4
R5
F
The shortest path
multicast tree
R6
R7
R8
Multicast: CBT Spanning Tree
B
C
Core
JOIN
R1
D
R3
JO
IN
JO
IN
E
B
A
R2
R4
R6
R8
ACK
D
K
R3
AC
IN
G
R7
JOIN
R5
Core
R1
JO
(a)
C
A
F
R2
E
R4
R6
R8
G
B
C
R5
Core
R3
AC
K
ACK
E
B
R2
(b)
F
D
R1
A
R7
IN
JO
R4
R6
C
Core
D
R8
R1
R3
G
R7
F
A
R2
R4
AC
R6
R8
K
G
IN
JO
(c)
R5
E
R5
R7
F
(d)
Data Packet Forwarding in CBT
C
B
Core
R1
C
D
R1 G
Core
R3
D
G
B
R1
R3
E
G
E
R2
R4
R6
G
A
R5
R7
(a)
R2
R8
R4
R6
R8
G
A
R5
R7
F
(b)
F
Multicast: Spanning Tree Teardown
OLD Core
R4
R6
R2
R4
NEW Core
R6
R2
R5
R5
R7
Next hop
(to Core) = R7
(a)
Teardo
R7
wn msg
Next hop
(to Core) = R7
(b)
Topic:
Differentiated Services
 DiffServ Architecture
DiffServ Architecture
Network Layer Protocol (IP)
pre-marked or
unmarked packet
Based on Source-Address
and Destination-Address to
get corresponding Policy
Classifier
Check if packet is out of
source’s declared profile
Discard bursts
Meter
Policer and Shaper
Mark according to policy
Classify based on code point from
PHB Table to get the corresponding
physical and virtual queue
Marker
Classifier
Class 1 queue
Scheduler
Class n queue
Random Early Detection (RED) Queues
Link Layer Protocol
Topic:
Multimedia Protocols
 Real-time Transport Protocol (RTP)
 RTP Control Protocol (RTCP)
 SIP, SDP, …
RTP: Real-time Transport Protocol
Layer 3:
Endto-End
TCP/IP protocol suite:
RTP (Real-time
Transport Protocol)
Layer 3:
Layer 2:
Transport
Network
Layer 1:
Layer 2:
Link
Internet
Layer 1:
Link
RTP
UDP
IP
RTP Header
0
2 3 4
7 8
15 16
2-bit
4-bit
ver. P X contrib. M 7-bit payload type
num
src count
31
16-bit sequence number
12
bytes
32-bit timestamp
32-bit synchronization source (SSRC) identifier
contributing source (CSRC) identifiers (if any)
32-bit extension header (if any)
data
padding (if any)
8-bit pad count
(in bytes)
RTP Header (2)
• P = padding bit indicates if packet is padded
•
•
•
•
to a required size (e.g., for encryption)
X = extension bit indicates an extension
header; rarely used b/c appl. defines own hdr
CSRC count = # contributing source IDs in
the header, if any
M = marks packets w/ significant events
Payload type = payload format indicates
encoding scheme used for audio, video, etc.
RTP Header (3)
•
•
•
•
Sequence number = used by receiver for delay jitter removal
Timestamp = used with seq. num. to detect pkt loss. Also to
synchronize packets from different sources. Represents the
sampling (creation) time of the 1st byte. Possible that
successive packets have the same timestamp. E.g., a single
video frame is transmitted in multiple RTP packets.
SSRC identifier = unique synchronization source ID
randomly chosen. Same for all packets from the same
src/device. Enables receiver to group packets for playback.
CSRC identifiers = list of contributing sources for the packet
payload. Used when a mixer combines several streams of
packets. Allows the receiver to identify the original senders.
RTCP Header Format
Common sender/receiver REPORT message header:
All report messages have the same 8 byte header
» version number (same as RTP)
» padding indicator
» reception report count (5 bits)
» RTCP message type (8 bits)
» RTCP message length (16 bits)
» SSRC for the sender of this report (32 bits)
Compound RTCP Packet Format
0 1 2 3
7 8
15 16
31
IP header
UDP header
First
RTCP
packet
RTCP packet type-specific information
ver. P reports count RTCP packet type
Second
RTCP
packet
RTCP packet length (in 32-bit words)
RTCP packet length (in 32-bit words)
RTCP packet type-specific information
…
Compound RTCP packet
ver. P reports count RTCP packet type
Reception Report Blocks
• Each sender and receiver report should contain a
reception report block for each synchronization
source heard from since the last RTCP report
• Contents:
– source identifier for the block (SSRC)
– fraction of RTP packets from this source lost since the
last report
– cumulative number of lost packets
– extended highest sequence number received
– estimated average RTP packet interarrival time jitter
– last SR timestamp received from this source
– delay since receiving the last SR report from this source
RTCP Receiver Report Format
0 1 2 3
header
7 8
15 16
ver. P reports count packet type = ‘201’
31
packet length (in 32-bit words)
SSRC of this reporter
SSRC_1 (SSRC of first source)
fraction lost
report
block
1
cumulative number of packets lost
extended highest sequence number received
interarrival jitter
last SR (LSR)
delay since last SR (DLSR)
report block 2
...
profile-specific extensions
RTCP Sender Report Format
0 1 2 3
header
7 8
15 16
ver. P reports count packet type = ‘200’
31
packet length (in 32-bit words)
SSRC of this reporter
NTP timestamp, most significant word (seconds)
NTP timestamp, least significant word (seconds fraction)
sender
info
RTP timestamp
sender’s packet count
sender’s byte count
SSRC_1 (SSRC of first source)
fraction lost
report
block
1
cumulative number of packets lost
extended highest sequence number received
interarrival jitter
last SR (LSR)
delay since last SR (DLSR)
report block 2
...
profile-specific extensions
Inter-arrival Time Jitter
senti  senti1
Sender
Perfect delivery
Receiver
recvi  recvi1
Delay jitter
Example for RTT computation
Algorithm for RTCP Reporting Interval
[true]
(number of senders > 0) AND
(# senders < (25% of total # participants))
[false]
?
[sender]
This participant
sender or receiver
[receiver]
?
Interval of
(average RTCP packet size)  (# senders)
Sender Reports =
0.25  (RTCP bandwidth)
Interval of
(avg. RTCP pkt. size)  (# participants)
Reports =
RTCP bandwidth
Interval of
(average RTCP packet size)  (# receivers)
Receiver Reports =
0.75  (RTCP bandwidth)
RTCP Bandwidth Allocation
VoIP Phone Call Session
Forward SIP signaling
Forward RTP media
Forward RTCP monitoring
Caller
Reverse SIP signaling
Callee
Reverse RTP media
Reverse RTCP monitoring
Logical channels between the caller and callee during a VoIP call