Chapter 7

Multimedia Networking

A note on the use of these ppt slides:

Were making these slides freely available to all (faculty, students, readers).
Theyre in PowerPoint form so you can add, modify, and delete slides
(including this one) and slide content to suit your needs. They obviously
represent a lot of work on our part. In return for use, we only ask the Computer Networking: A Top
following: Down Approach

If you use these slides (e.g., in a class) in substantially unaltered form, 5th edition.
that you mention their source (after all, wed like people to use our book!)

If you post any slides in substantially unaltered form on a www site, that
Jim Kurose, Keith Ross
you note that they are adapted from (or perhaps identical to) our slides, and Addison-Wesley, April 2009.
note our copyright of this material.

Thanks and enjoy! JFK / KWR

All material copyright 1996-2009

J.F Kurose and K.W. Ross, All Rights Reserved
7: Multimedia Networking 7-1
Multimedia and Quality of Service: What is it?

multimedia applications:
network audio and video
(continuous media)

QoS
network provides
application with level of
performance needed for
application to function.
7: Multimedia Networking 7-2
Chapter 7: goals

Principles
 classify multimedia applications
 identify network services applications need
 making the best of best effort service
Protocols and Architectures
 specific protocols for best-effort
 mechanisms for providing QoS
 architectures for QoS

7: Multimedia Networking 7-3

Chapter 7 outline
7.1 multimedia networking 7.5 providing multiple
applications classes of service
7.2 streaming stored audio 7.6 providing QoS
and video guarantees
7.3 making the best out of
best effort service
7.4 protocols for real-time
interactive applications
RTP,RTCP,SIP

7: Multimedia Networking 7-4

MM Networking Applications

Classes of MM applications: Fundamental

characteristics:
1) stored streaming
 typically delay sensitive
2) live streaming
 end-to-end delay
3) interactive, real-time  delay jitter
 loss tolerant: infrequent
losses cause minor
glitches
 antithesis of data, which
are loss intolerant but
Jitter is the variability delay tolerant.
of packet delays within
the same packet stream
7: Multimedia Networking 7-5
Streaming Stored Multimedia

Stored streaming:
 media stored at source
 transmitted to client
 streaming: client playout begins
before all data has arrived
 timing constraint for still-to-be
transmitted data: in time for playout

7: Multimedia Networking 7-6

Streaming Stored Multimedia:
What is it?

2. video
sent
1. video 3. video received,
recorded network played out at client
delay
time
streaming: at this time, client
playing out early part of video,
while server still sending later
part of video

7: Multimedia Networking 7-7

Streaming Stored Multimedia: Interactivity

 VCR-like functionality: client can

pause, rewind, FF, push slider bar
 10 sec initial delay OK
 1-2 sec until command effect OK

 timing constraint for still-to-be

transmitted data: in time for playout

7: Multimedia Networking 7-8

Streaming Live Multimedia

Examples:
 Internet radio talk show
 live sporting event
Streaming (as with streaming stored multimedia)
 playback buffer
 playback can lag tens of seconds after
transmission
 still have timing constraint
Interactivity
 fast forward impossible
 rewind, pause possible!

7: Multimedia Networking 7-9

 Real-Time Interactive Multimedia

 applications: IP telephony,
video conference, distributed
interactive worlds
 end-end delay requirements:
 audio: < 150 msec good, < 400 msec OK
includes application-level (packetization) and network
delays
higher delays noticeable, impair interactivity
 session initialization
 how does callee advertise its IP address, port
number, encoding algorithms? 7: Multimedia Networking 7-10
Multimedia Over Todays Internet
TCP/UDP/IP: best-effort service
 no guarantees on delay, loss
? ? ?
? ? ?
But you said multimedia apps requires ?
QoS and level of performance to be
? ? effective! ? ?

Todays Internet multimedia applications

use application-level techniques to mitigate
(as best possible) effects of delay, loss

7: Multimedia Networking 7-11

 How should the Internet evolve to better
support multimedia?
Integrated services philosophy: Differentiated services
 fundamental changes in philosophy:
Internet so that apps can  fewer changes to Internet
reserve end-to-end infrastructure, yet provide
bandwidth 1st and 2nd class service
 requires new, complex
software in hosts & routers
Laissez-faire
 no major changes
 more bandwidth when
needed
 content distribution,
application-layer multicast
Whats your opinion?
 application layer

7: Multimedia Networking 7-12

A few words about audio compression

 analog signal sampled  example: 8,000

at constant rate samples/sec, 256
 telephone: 8,000 quantized values -->
samples/sec 64,000 bps
 CD music: 44,100  receiver converts bits
samples/sec
back to analog signal:
 each sample quantized,
 some quality reduction
i.e., rounded
Example rates
 e.g., 28=256 possible
quantized values  CD: 1.411 Mbps
 each quantized value  MP3: 96, 128, 160 kbps
represented by bits  Internet telephony:
 8 bits for 256 values 5.3 kbps and up
7: Multimedia Networking 7-13
 A few words about video compression

 video: sequence of Examples:

images displayed at  MPEG 1 (CD-ROM) 1.5
constant rate Mbps
 e.g. 24 images/sec
 MPEG2 (DVD) 3-6 Mbps
 digital image: array of
 MPEG4 (often used in
pixels Internet, < 1 Mbps)
 each pixel represented
by bits Research:
 redundancy  layered (scalable) video
 spatial (within image)  adapt layers to available
bandwidth
 temporal (from one image
to next)

7: Multimedia Networking 7-14

Chapter 7 outline
7.1 multimedia networking 7.5 providing multiple
applications classes of service
7.2 streaming stored audio 7.6 providing QoS
and video guarantees
7.3 making the best out of
best effort service
7.4 protocols for real-time
interactive applications
RTP,RTCP,SIP

7: Multimedia Networking 7-15

 Streaming Stored Multimedia
application-level streaming
techniques for making the
best out of best effort Media Player
service:
 jitter removal
 client-side buffering
 decompression
 use of UDP versus TCP  error concealment
 multiple encodings of  graphical user interface
multimedia w/ controls for
interactivity

7: Multimedia Networking 7-16

Internet multimedia: simplest approach

 audio or video stored in file

 files transferred as HTTP object
 received in entirety at client
 then passed to player

audio, video not streamed:

 no, pipelining, long delays until playout!

7: Multimedia Networking 7-17

Internet multimedia: streaming approach

 browser GETs metafile

 browser launches player, passing metafile
 player contacts server
 server streams audio/video to player
7: Multimedia Networking 7-18
Streaming from a streaming server

 allows for non-HTTP protocol between server, media

player
 UDP or TCP for step (3), more shortly

7: Multimedia Networking 7-19

Streaming Multimedia: Client Buffering

constant bit
rate video client video constant bit
transmission reception rate video
playout at client
variable

buffered
network

video
delay

client playout time

delay

 client-side buffering, playout delay compensate

for network-added delay, delay jitter

7: Multimedia Networking 7-20

Streaming Multimedia: Client Buffering

constant
variable fill drain
rate, x(t) rate, d

buffered
video

 client-side buffering, playout delay compensate

for network-added delay, delay jitter

7: Multimedia Networking 7-21

Streaming Multimedia: UDP or TCP?
UDP
 server sends at rate appropriate for client (oblivious to
network congestion !)
 often send rate = encoding rate = constant rate
 then, fill rate = constant rate - packet loss
 short playout delay (2-5 seconds) to remove network jitter
 error recover: time permitting
TCP
 send at maximum possible rate under TCP
 fill rate fluctuates due to TCP congestion control
 larger playout delay: smooth TCP delivery rate
 HTTP/TCP passes more easily through firewalls

7: Multimedia Networking 7-22

Streaming Multimedia: client rate(s)
1.5 Mbps encoding

28.8 Kbps encoding

Q: how to handle different client receive rate

capabilities?
 28.8 Kbps dialup
 100 Mbps Ethernet
A: server stores, transmits multiple copies
of video, encoded at different rates
7: Multimedia Networking 7-23
User Control of Streaming Media: RTSP

HTTP What it doesnt do:

 does not target  doesnt define how
multimedia content audio/video is
 no commands for fast encapsulated for
forward, etc. streaming over network
RTSP: RFC 2326  doesnt restrict how
 client-server
streamed media is
application layer transported (UDP or
protocol TCP possible)
 doesnt specify how
 user control: rewind,
fast forward, pause, media player buffers
resume, repositioning, audio/video
etc
7: Multimedia Networking 7-24
RTSP: out of band control
FTP uses an out-of- RTSP messages also sent
band control channel: out-of-band:
 file transferred over  RTSP control
one TCP connection. messages use
 control info (directory different port
changes, file deletion, numbers than media
rename) sent over stream: out-of-band.
separate TCP  port 554
connection  media stream is
 out-of-band, in- considered in-band.
band channels use
different port
numbers
7: Multimedia Networking 7-25
RTSP Example

Scenario:
 metafile communicated to web browser
 browser launches player
 player sets up an RTSP control connection, data
connection to streaming server

7: Multimedia Networking 7-26

Metafile Example
<title>Twister</title>
<session>
<group language=en lipsync>
<switch>
<track type=audio
e="PCMU/8000/1"
src = "rtsp://audio.example.com/twister/audio.en/lofi">
<track type=audio
e="DVI4/16000/2" pt="90 DVI4/8000/1"
src="rtsp://audio.example.com/twister/audio.en/hifi">
</switch>
<track type="video/jpeg"
src="rtsp://video.example.com/twister/video">
</group>
</session>

7: Multimedia Networking 7-27

RTSP Operation

7: Multimedia Networking 7-28

RTSP Exchange Example
C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0
Transport: rtp/udp; compression; port=3056; mode=PLAY

S: RTSP/1.0 200 1 OK
Session 4231

C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Session: 4231
Range: npt=0-

C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Session: 4231
Range: npt=37

C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0

Session: 4231

S: 200 3 OK
7: Multimedia Networking 7-29
Chapter 7 outline
7.1 multimedia networking 7.5 providing multiple
applications classes of service
7.2 streaming stored audio 7.6 providing QoS
and video guarantees
7.3 making the best out of
best effort service
7.4 protocols for real-time
interactive applications
RTP,RTCP,SIP

7: Multimedia Networking 7-30

Real-time interactive applications
 PC-2-PC phone
 Skype Going to now look at
 PC-2-phone a PC-2-PC Internet
 Dialpad
phone example in
detail
 Net2phone
 Skype
 videoconference with
webcams
 Skype
 Polycom

7: Multimedia Networking 7-31

Interactive Multimedia: Internet Phone
Introduce Internet Phone by way of an example
 speakers audio: alternating talk spurts, silent
periods.
 64 kbps during talk spurt
 pkts generated only during talk spurts
 20 msec chunks at 8 Kbytes/sec: 160 bytes
data
 application-layer header added to each chunk.
 chunk+header encapsulated into UDP segment.
 application sends UDP segment into socket every
20 msec during talkspurt
7: Multimedia Networking 7-32
Internet Phone: Packet Loss and Delay

 network loss: IP datagram lost due to network

congestion (router buffer overflow)
 delay loss: IP datagram arrives too late for
playout at receiver
 delays: processing, queueing in network; end-
system (sender, receiver) delays
 typical maximum tolerable delay: 400 ms
 loss tolerance: depending on voice encoding, losses
concealed, packet loss rates between 1% and 10%
can be tolerated.

7: Multimedia Networking 7-33

Delay Jitter

constant bit
rate client constant bit
transmission reception rate playout
at client
variable

buffered
network

data
delay
(jitter)

client playout time

delay

 consider end-to-end delays of two consecutive

packets: difference can be more or less than 20
msec (transmission time difference)
7: Multimedia Networking 7-34
Internet Phone: Fixed Playout Delay

 receiver attempts to playout each chunk exactly q

msecs after chunk was generated.
 chunk has time stamp t: play out chunk at t+q .
 chunk arrives after t+q: data arrives too late
for playout, data lost
 tradeoff in choosing q:
 large q: less packet loss
 small q: better interactive experience

7: Multimedia Networking 7-35

Fixed Playout Delay
sender generates packets every 20 msec during talk spurt.
first packet received at time r
first playout schedule: begins at p
second playout schedule: begins at p
packets

packets loss
generated
packets
playout schedule
received
p' - r

playout schedule
p-r

time

r
p p' 7: Multimedia Networking 7-36
 Adaptive Playout Delay (1)
 Goal: minimize playout delay, keeping late loss rate low
 Approach: adaptive playout delay adjustment:
 estimate network delay, adjust playout delay at beginning of
each talk spurt.
 silent periods compressed and elongated.
 chunks still played out every 20 msec during talk spurt.

t i = timestamp of the ith packet

ri = the time packet i is received by receiver
p i = the time packet i is played at receiver
ri t i = network delay for ith packet
d i = estimate of average network delay after receiving ith packet

dynamic estimate of average delay at receiver:

d i = (1 u )d i 1 + u( ri ti )
where u is a fixed constant (e.g., u = .01).
7: Multimedia Networking 7-37
Adaptive playout delay (2)

also useful to estimate average deviation of delay, vi :

vi = (1 u )vi 1 + u | ri ti d i |

estimates di , vi calculated for every received packet

(but used only at start of talk spurt

for first packet in talk spurt, playout time is:

pi = ti + d i + Kvi
where K is positive constant

remaining packets in talkspurt are played out periodically

7: Multimedia Networking 7-38

 Adaptive Playout (3)

Q: How does receiver determine whether packet is

first in a talkspurt?
 if no loss, receiver looks at successive timestamps.
 difference of successive stamps > 20 msec -->talk spurt
begins.
 with loss possible, receiver must look at both time
stamps and sequence numbers.
 difference of successive stamps > 20 msec and sequence
numbers without gaps --> talk spurt begins.

7: Multimedia Networking 7-39

 Recovery from packet loss (1)
Forward Error Correction  playout delay: enough
(FEC): simple scheme time to receive all n+1
 for every group of n packets
chunks create redundant  tradeoff:
chunk by exclusive OR-ing
 increase n, less
n original chunks
bandwidth waste
 send out n+1 chunks,
 increase n, longer
increasing bandwidth by
playout delay
factor 1/n.
 increase n, higher
 can reconstruct original n
probability that 2 or
chunks if at most one lost
more chunks will be
chunk from n+1 chunks
lost

7: Multimedia Networking 7-40

Recovery from packet loss (2)
2nd FEC scheme

piggyback lower
quality stream

send lower resolution
audio stream as
redundant information

e.g., nominal
stream PCM at 64 kbps
and redundant stream
GSM at 13 kbps.

whenever there is non-consecutive loss,

receiver can conceal the loss.

can also append (n-1)st and (n-2)nd low-bit rate
chunk

7: Multimedia Networking 7-41

 Recovery from packet loss (3)

Interleaving
 chunks divided into smaller  if packet lost, still have most
units of every chunk
 for example, four 5 msec  no redundancy overhead, but
units per chunk increases playout delay
 packet contains small units
from different chunks
7: Multimedia Networking 7-42
Content distribution networks (CDNs)
Content replication origin server
in North America
 challenging to stream large
files (e.g., video) from single
origin server in real time
 solution: replicate content at
CDN distribution node
hundreds of servers
throughout Internet
 content downloaded to CDN
servers ahead of time
 placing content close to
user avoids impairments
(loss, delay) of sending CDN server
CDN server
content over long paths in S. America CDN server
in Asia
 CDN server typically in in Europe
edge/access network
7: Multimedia Networking 7-43
Content distribution networks (CDNs)
origin server
Content replication in North America
 CDN (e.g., Akamai)
customer is the content
provider (e.g., CNN)
CDN distribution node
 CDN replicates
customers content in
CDN servers.
 when provider updates
content, CDN updates
servers CDN server
CDN server
in S. America CDN server
in Asia
in Europe

7: Multimedia Networking 7-44

 CDN example HTTP request for
www.foo.com/sports/sports.html
origin server
1

2 DNS query for www.cdn.com

client CDNs authoritative
DNS server
3

HTTP request for

www.cdn.com/www.foo.com/sports/ruth.gif
CDN server near client

origin server (www.foo.com) CDN company (cdn.com)

 distributes HTML  distributes gif files
 replaces:  uses its authoritative
http://www.foo.com/sports.ruth.gif
DNS server to route
with
http://www.cdn.com/www.foo.com/sports/ruth.gif redirect requests
7: Multimedia Networking 7-45
More about CDNs

routing requests
 CDN creates a map, indicating distances from
leaf ISPs and CDN nodes
 when query arrives at authoritative DNS server:
 server determines ISP from which query originates
 uses map to determine best CDN server
 CDN nodes create application-layer overlay
network

7: Multimedia Networking 7-46

Summary: Internet Multimedia: bag of tricks
 use UDP to avoid TCP congestion control (delays)
for time-sensitive traffic
 client-side adaptive playout delay: to compensate
for delay
 server side matches stream bandwidth to available
client-to-server path bandwidth
 chose among pre-encoded stream rates
 dynamic server encoding rate
 error recovery (on top of UDP)
 FEC, interleaving, error concealment
 retransmissions, time permitting

 CDN: bring content closer to clients

7: Multimedia Networking 7-47

Chapter 7 outline
7.1 multimedia networking 7.5 providing multiple
applications classes of service
7.2 streaming stored audio 7.6 providing QoS
and video guarantees
7.3 making the best out of
best effort service
7.4 protocols for real-time
interactive applications
RTP, RTCP, SIP

7: Multimedia Networking 7-48

Real-Time Protocol (RTP)
 RTP specifies packet  RTP runs in end systems
structure for packets  RTP packets
carrying audio, video encapsulated in UDP
data segments
 RFC 3550  interoperability: if two
 RTP packet provides Internet phone
 payload type applications run RTP,
identification then they may be able
 packet sequence
to work together
numbering
 time stamping

7: Multimedia Networking 7-49

RTP runs on top of UDP
RTP libraries provide transport-layer interface
that extends UDP:
port numbers, IP addresses
payload type identification
packet sequence numbering
time-stamping

7: Multimedia Networking 7-50

RTP Example
 consider sending 64
 RTP header indicates
kbps PCM-encoded
type of audio encoding
voice over RTP.
in each packet
 application collects  sender can change
encoded data in encoding during
chunks, e.g., every 20 conference.
msec = 160 bytes in a  RTP header also
chunk. contains sequence
 audio chunk + RTP numbers, timestamps.
header form RTP
packet, which is
encapsulated in UDP
segment
7: Multimedia Networking 7-51
RTP and QoS

 RTP does not provide any mechanism to ensure

timely data delivery or other QoS guarantees.
 RTP encapsulation is only seen at end systems
(not) by intermediate routers.
 routers providing best-effort service, making
no special effort to ensure that RTP packets
arrive at destination in timely matter.

7: Multimedia Networking 7-52

 RTP Header

Payload Type (7 bits): Indicates type of encoding currently being

used. If sender changes encoding in middle of conference, sender
informs receiver via payload type field.

Payload type 0: PCM mu-law, 64 kbps

Payload type 3, GSM, 13 kbps
Payload type 7, LPC, 2.4 kbps
Payload type 26, Motion JPEG
Payload type 31. H.261
Payload type 33, MPEG2 video

Sequence Number (16 bits): Increments by one for each RTP packet
sent, and may be used to detect packet loss and to restore packet
sequence.
7: Multimedia Networking 7-53
RTP Header (2)

 Timestamp field (32 bits long): sampling instant of

first byte in this RTP data packet
 for audio, timestamp clock typically increments by one
for each sampling period (for example, each 125 usecs
for 8 KHz sampling clock)
 if application generates chunks of 160 encoded samples,
then timestamp increases by 160 for each RTP packet
when source is active. Timestamp clock continues to
increase at constant rate when source is inactive.

 SSRC field (32 bits long): identifies source of t RTP

stream. Each stream in RTP session should have distinct
SSRC.

7: Multimedia Networking 7-54

RTSP/RTP Programming Assignment

 build a server that encapsulates stored video

frames into RTP packets
 grab video frame, add RTP headers, create UDP
segments, send segments to UDP socket
 include seq numbers and time stamps
 client RTP provided for you
 also write client side of RTSP
 issue play/pause commands
 server RTSP provided for you

7: Multimedia Networking 7-55

Real-Time Control Protocol (RTCP)

 works in conjunction  feedback can be used

with RTP. to control
 each participant in RTP performance
session periodically  sender may modify its
transmissions based on
transmits RTCP control feedback
packets to all other
participants.
 each RTCP packet
contains sender and/or
receiver reports
 report statistics useful to
application: # packets
sent, # packets lost,
interarrival jitter, etc.
7: Multimedia Networking 7-56
 RTCP - Continued

each RTP session: typically a single multicast address; all RTP /RTCP packets
belonging to session use multicast address.

RTP, RTCP packets distinguished from each other via distinct port numbers.

to limit traffic, each participant reduces RTCP traffic as number of

conference participants increases

7: Multimedia Networking 7-57

RTCP Packets

Receiver report packets: Source description

 fraction of packets packets:
lost, last sequence  e-mail address of
number, average sender, sender's name,
interarrival jitter SSRC of associated
Sender report packets: RTP stream
 SSRC of RTP stream,  provide mapping
current time, number of between the SSRC and
packets sent, number of the user/host name
bytes sent

7: Multimedia Networking 7-58

Synchronization of Streams

 RTCP can synchronize  each RTCP sender-report

different media streams packet contains (for most
within a RTP session recently generated packet
 consider videoconferencing in associated RTP stream):
app for which each sender  timestamp of RTP packet
generates one RTP stream  wall-clock time for when
for video, one for audio. packet was created.
 timestamps in RTP packets  receivers uses association
tied to the video, audio to synchronize playout of
sampling clocks audio, video
 not tied to wall-clock
time

7: Multimedia Networking 7-59

RTCP Bandwidth Scaling

 RTCP attempts to limit its

 75 kbps is equally shared
traffic to 5% of session among receivers:
bandwidth.
 with R receivers, each
Example receiver gets to send RTCP
 Suppose one sender, traffic at 75/R kbps.
sending video at 2 Mbps.  sender gets to send RTCP
Then RTCP attempts to traffic at 25 kbps.
limit its traffic to 100
 participant determines RTCP
Kbps.
packet transmission period by
 RTCP gives 75% of rate to calculating avg RTCP packet
receivers; remaining 25% size (across entire session)
to sender and dividing by allocated rate

7: Multimedia Networking 7-60

SIP: Session Initiation Protocol [RFC 3261]

SIP long-term vision:

 all telephone calls, video conference calls take

place over Internet
 people are identified by names or e-mail
addresses, rather than by phone numbers
 you can reach callee, no matter where callee
roams, no matter what IP device callee is currently
using

7: Multimedia Networking 7-61

 SIP Services

 Setting up a call, SIP  determine current IP

provides mechanisms .. address of callee:
 for caller to let  maps mnemonic
callee know she identifier to current IP
address
wants to establish a
call  call management:
 add new media streams
 so caller, callee can
during call
agree on media type,  change encoding during
encoding call
 to end call  invite others
 transfer, hold calls

7: Multimedia Networking 7-62

 Setting up a call to known IP address
Bob
Alices SIP invite
Alice
message indicates her
port number, IP address,
167.180.112.24 193.64.210.89
encoding she prefers to
INVITE bob
c=IN IP4 16
@193.64.21
0.89
receive (PCM ulaw)
7.180.112.2
m=audio 38 4
060 RTP/AV
P0
port 5060 Bob's
terminal rings

Bobs 200 OK message
200 OK
10.89
indicates his port number,
c=IN IP4 193.64.2
m=audio 48 75 3 RT P/AVP 3 IP address, preferred
port 5060
encoding (GSM)
ACK
port 5060

SIP messages can be

Law audio
port 38060 sent over TCP or UDP;
here sent over RTP/UDP.
GSM

default SIP port number
port 48753

is 5060.
time time
7: Multimedia Networking 7-63
Setting up a call (more)
 codec negotiation:
 rejecting a call
 suppose Bob doesnt
 Bob can reject with
have PCM ulaw
replies busy,
encoder.
gone, payment
 Bob will instead reply required,
with 606 Not forbidden
Acceptable Reply,
 media can be sent over
listing his encoders
RTP or some other
Alice can then send
protocol
new INVITE
message, advertising
different encoder

7: Multimedia Networking 7-64

Example of SIP message

INVITE sip:bob@domain.com SIP/2.0

Via: SIP/2.0/UDP 167.180.112.24
Here we dont know
From: sip:alice@hereway.com Bobs IP address.
Intermediate SIP
To: sip:bob@domain.com
servers needed.
Call-ID: a2e3a@pigeon.hereway.com
Content-Type: application/sdp
Alice sends, receives
Content-Length: 885 SIP messages using
SIP default port 506

c=IN IP4 167.180.112.24
Alice specifies in

m=audio 38060 RTP/AVP 0 Via:
Notes: header that SIP client
sends, receives SIP
 HTTP message syntax
messages over UDP
 sdp = session description protocol
 Call-ID is unique for every call.
7: Multimedia Networking 7-65
Name translation and user locataion

 caller wants to call  result can be based on:

callee, but only has  time of day (work, home)
callees name or e-mail  caller (dont want boss to
address. call you at home)
 status of callee (calls sent
 need to get IP address
to voicemail when callee is
of callees current already talking to
host: someone)
 user moves around Service provided by SIP
 DHCP protocol servers:
 user has different IP
devices (PC, PDA, car  SIP registrar server
device)  SIP proxy server

7: Multimedia Networking 7-66

SIP Registrar
 when Bob starts SIP client, client sends SIP
REGISTER message to Bobs registrar server
(similar function needed by Instant Messaging)

Register Message:

REGISTER sip:domain.com SIP/2.0

Via: SIP/2.0/UDP 193.64.210.89
From: sip:bob@domain.com
To: sip:bob@domain.com
Expires: 3600

7: Multimedia Networking 7-67

SIP Proxy

 Alice sends invite message to her proxy server

 contains address sip:bob@domain.com

 proxy responsible for routing SIP messages to

callee
 possibly through multiple proxies.
 callee sends response back through the same set
of proxies.
 proxy returns SIP response message to Alice
 contains Bobs IP address
 proxy analogous to local DNS server

7: Multimedia Networking 7-68

 Example
Caller jim@umass.edu SIP registrar
upenn.edu
with places a
call to keith@upenn.edu SIP
2 registrar
SIP proxy eurecom.fr
(1) Jim sends INVITE umass.edu 3
4
message to umass SIP
proxy. (2) Proxy forwards 1 7 5
request to upenn 8
6
registrar server.
(3) upenn server returns 9

redirect response, SIP client

SIP client
197.87.54.21
indicating that it should 217.123.56.89

try keith@eurecom.fr
(4) umass proxy sends INVITE to eurecom registrar. (5) eurecom
registrar forwards INVITE to 197.87.54.21, which is running keiths SIP
client. (6-8) SIP response sent back (9) media sent directly
between clients.
Note: also a SIP ack message, which is not shown.
7: Multimedia Networking 7-69
Comparison with H.323

 H.323 is another signaling  H.323 comes from the ITU

protocol for real-time, (telephony).
interactive  SIP comes from IETF:
 H.323 is a complete, Borrows much of its
vertically integrated suite concepts from HTTP
of protocols for multimedia  SIP has Web flavor,
conferencing: signaling, whereas H.323 has
registration, admission telephony flavor.
control, transport, codecs  SIP uses the KISS
 SIP is a single component. principle: Keep it simple
Works with RTP, but does stupid.
not mandate it. Can be
combined with other
protocols, services

7: Multimedia Networking 7-70

Multimedia and Quality of Service: What is it?

multimedia applications:
network audio and video
(continuous media)

QoS
network provides
application with level of
performance needed for
application to function.
7: Multimedia Networking 7-71
Chapter 7 outline
7.1 multimedia networking 7.5 providing multiple
applications classes of service
7.2 streaming stored audio 7.6 providing QoS
and video guarantees
7.3 making the best out of
best effort service
7.4 protocols for real-time
interactive applications
RTP, RTCP, SIP

7: Multimedia Networking 7-72

Providing Multiple Classes of Service
 thus far: making the best of best effort service
 one-size fits all service model
 alternative: multiple classes of service
 partition traffic into classes
 network treats different classes of traffic
differently (analogy: VIP service vs regular service)
 granularity:
differential service
among multiple 0111

classes, not among

individual
connections
 history: ToS bits
7: Multimedia Networking 7-73
Multiple classes of service: scenario

H3
H1
R1 R2

H4
H2 R1 output 1.5 Mbps link
interface
queue

7: Multimedia Networking 7-74

Scenario 1: mixed FTP and audio
 Example: 1Mbps IP phone, FTP share 1.5 Mbps link.
 bursts of FTP can congest router, cause audio loss
 want to give priority to audio over FTP

R1 R2

Principle 1
packet marking needed for router to distinguish
between different classes; and new router policy
to treat packets accordingly
7: Multimedia Networking 7-75
Principles for QOS Guarantees (more)
 what if applications misbehave (audio sends higher
than declared rate)
 policing: force source adherence to bandwidth allocations
 marking and policing at network edge:
 similar to ATM UNI (User Network Interface)
1 Mbps
phone
R1 R2

1.5 Mbps link

packet marking and policing

Principle 2
provide protection (isolation) for one class from others
7: Multimedia Networking 7-76
 Principles for QOS Guarantees (more)

 Allocating fixed (non-sharable) bandwidth to flow:

inefficient use of bandwidth if flows doesnt use
its allocation

1 Mbps 1 Mbps logical link

phone R1
R2

1.5 Mbps link

0.5 Mbps logical link

Principle 3
While providing isolation, it is desirable to use
resources as efficiently as possible
7: Multimedia Networking 7-77
Scheduling And Policing Mechanisms

 scheduling: choose next packet to send on link

 FIFO (first in first out) scheduling: send in order of
arrival to queue
 real-world example?
 discard policy: if packet arrives to full queue: who to discard?
Tail drop: drop arriving packet
priority: drop/remove on priority basis
random: drop/remove randomly

7: Multimedia Networking 7-78

Scheduling Policies: more

Priority scheduling: transmit highest priority queued

packet
 multiple classes, with different priorities
 class may depend on marking or other header info, e.g. IP
source/dest, port numbers, etc..
 Real world example?

7: Multimedia Networking 7-79

Scheduling Policies: still more
round robin scheduling:
 multiple classes
 cyclically scan class queues, serving one from each
class (if available)
 real world example?

7: Multimedia Networking 7-80

Scheduling Policies: still more
Weighted Fair Queuing:
 generalized Round Robin
 each class gets weighted amount of service in each
cycle
 real-world example?

7: Multimedia Networking 7-81

Policing Mechanisms

Goal: limit traffic to not exceed declared parameters

Three common-used criteria:
 (Long term) Average Rate: how many pkts can be sent
per unit time (in the long run)
 crucial question: what is the interval length: 100 packets per
sec or 6000 packets per min have same average!
 Peak Rate: e.g., 6000 pkts per min. (ppm) avg.; 1500
pps peak rate
 (Max.) Burst Size: max. number of pkts sent
consecutively (with no intervening idle)

7: Multimedia Networking 7-82

Policing Mechanisms

Token Bucket: limit input to specified Burst Size

and Average Rate.

 bucket can hold b tokens

 tokens generated at rate r token/sec unless bucket
full
 over interval of length t: number of packets
admitted less than or equal to (r t + b).
7: Multimedia Networking 7-83
Policing Mechanisms (more)

 token bucket, WFQ combine to provide guaranteed

upper bound on delay, i.e., QoS guarantee!

arriving token rate, r

traffic
bucket size, b
per-flow
rate, R
WFQ

D = b/R
max

7: Multimedia Networking 7-84

IETF Differentiated Services
 want qualitative service classes
 behaves like a wire
 relative service distinction: Platinum, Gold, Silver

 scalability: simple functions in network core,

relatively complex functions at edge routers (or
hosts)
 signaling, maintaining per-flow router state
difficult with large number of flows
 flexibility: dont define service classes, provide
functional components to build service classes

7: Multimedia Networking 7-85

 Diffserv Architecture

Edge router:

per-flow traffic management r marking
scheduling

marks packets as in-profile
and out-profile b ..
.

Core router:

per class traffic management

buffering and scheduling based
on marking at edge

preference given to in-profile
packets

7: Multimedia Networking 7-86

Edge-router Packet Marking
 profile: pre-negotiated rate A, bucket size B
 packet marking at edge based on per-flow profile

Rate A

User packets

Possible usage of marking:

 class-based marking: packets of different classes marked
differently
 intra-class marking: conforming portion of flow marked
differently than non-conforming one

7: Multimedia Networking 7-87

Classification and Conditioning

 Packet is marked in the Type of Service (TOS) in

IPv4, and Traffic Class in IPv6
 6 bits used for Differentiated Service Code Point
(DSCP) and determine PHB that the packet will
receive
 2 bits are currently unused

7: Multimedia Networking 7-88

Classification and Conditioning

may be desirable to limit traffic injection rate of

some class:
 user declares traffic profile (e.g., rate, burst size)
 traffic metered, shaped if non-conforming

7: Multimedia Networking 7-89

Forwarding (PHB)

 PHB result in a different observable (measurable)

forwarding performance behavior
 PHB does not specify what mechanisms to use to
ensure required PHB performance behavior
 Examples:
 Class A gets x% of outgoing link bandwidth over time
intervals of a specified length
 Class A packets leave first before packets from class B

7: Multimedia Networking 7-90

Forwarding (PHB)

PHBs being developed:

 Expedited Forwarding: pkt departure rate of a
class equals or exceeds specified rate
 logical link with a minimum guaranteed rate
 Assured Forwarding: 4 classes of traffic
 each guaranteed minimum amount of bandwidth
 each with three drop preference partitions

7: Multimedia Networking 7-91

Chapter 7 outline
7.1 multimedia networking 7.5 providing multiple
applications classes of service
7.2 streaming stored audio 7.6 providing QoS
and video guarantees
7.3 making the best out of
best effort service
7.4 protocols for real-time
interactive applications
RTP, RTCP, SIP

7: Multimedia Networking 7-92

Principles for QOS Guarantees (more)

 Basic fact of life: can not support traffic demands

beyond link capacity

1 Mbps
phone R1
R2

1 Mbps 1.5 Mbps link

phone

Principle 4
Call Admission: flow declares its needs, network may
block call (e.g., busy signal) if it cannot meet needs
7: Multimedia Networking 7-93
QoS guarantee scenario
 Resource reservation
 call setup, signaling (RSVP)
 traffic, QoS declaration
 per-element admission control

request/
reply

 QoS-sensitive
scheduling (e.g.,
WFQ)

7: Multimedia Networking 7-94

IETF Integrated Services

 architecture for providing QOS guarantees in IP

networks for individual application sessions
 resource reservation: routers maintain state info
(a la VC) of allocated resources, QoS reqs
 admit/deny new call setup requests:

Question: can newly arriving flow be admitted

with performance guarantees while not violated
QoS guarantees made to already admitted flows?

7: Multimedia Networking 7-95

Call Admission

Arriving session must :

 declare its QOS requirement
 R-spec: defines the QOS being requested
 characterize traffic it will send into network
 T-spec: defines traffic characteristics
 signaling protocol: needed to carry R-spec and T-
spec to routers (where reservation is required)
 RSVP

7: Multimedia Networking 7-96

Intserv QoS: Service models [rfc2211, rfc 2212]

Guaranteed service: Controlled load service:

 worst case traffic arrival:  "a quality of service closely
leaky-bucket-policed source approximating the QoS that
 simple (mathematically same flow would receive
provable) bound on delay from an unloaded network
[Parekh 1992, Cruz 1988] element."

arriving token rate, r

traffic
bucket size, b
per-flow
rate, R
WFQ

D = b/R
max
7: Multimedia Networking 7-97
Signaling in the Internet

connectionless no network
(stateless) best effort signaling protocols
forwarding by IP
+ service = in initial IP
routers design

 New requirement: reserve resources along end-to-end

path (end system, routers) for QoS for multimedia
applications
 RSVP: Resource Reservation Protocol [RFC 2205]
 allow users to communicate requirements to network in
robust and efficient way. i.e., signaling !
 earlier Internet Signaling protocol: ST-II [RFC 1819]

7: Multimedia Networking 7-98

RSVP Design Goals

1. accommodate heterogeneous receivers (different

bandwidth along paths)
2. accommodate different applications with different
resource requirements
3. make multicast a first class service, with adaptation
to multicast group membership
4. leverage existing multicast/unicast routing, with
adaptation to changes in underlying unicast,
multicast routes
5. control protocol overhead to grow (at worst) linear
in # receivers
6. modular design for heterogeneous underlying
technologies

7: Multimedia Networking 7-99

RSVP: does not

 specify how resources are to be reserved

 rather: a mechanism for communicating needs
 determine routes packets will take
 thats the job of routing protocols
 signaling decoupled from routing
 interact with forwarding of packets
 separation of control (signaling) and data
(forwarding) planes

7: Multimedia Networking 7-100

RSVP: overview of operation
 senders, receiver join a multicast group
 done outside of RSVP
 senders need not join group

 sender-to-network signaling
 path message: make sender presence known to routers
 path teardown: delete senders path state from routers

 receiver-to-network signaling
 reservation message: reserve resources from sender(s) to
receiver
 reservation teardown: remove receiver reservations

 network-to-end-system signaling
 path error
 reservation error

7: Multimedia Networking 7-101

Chapter 7: Summary

Principles
 classify multimedia applications
 identify network services applications need
 making the best of best effort service
Protocols and Architectures
 specific protocols for best-effort
 mechanisms for providing QoS
 architectures for QoS
 multiple classes of service
 QoS guarantees, admission control

7: Multimedia Networking 7-102