Transcript Chapter 29t

Instructor: Prof. Hall
Conducted by:
Wayde
Anwar
Vikas
Choong
Nathan
Nadia
29.1 Introduction
This chapter focuses on real-time
audio/video transfer over IP networks.
 It examines the question of how IP can be
used to provide commercial telephone
service.
 It examines the question of how routers in
an IP network can guarantee sufficient
service to provide HiQ A/V reproduction.

29.2 Audio Clips and Encoding
Standards

Simplest digitizing A/D (encoding) -> IP
network-> D/A (decoding)
– OK for audio clips, not for interactive b/c of
delay introduced
– HiQ codec are available (Amplitude overtime
to sequence of digits, reconstruct from the
digits to waveform).
– Standards: based on the tradeoffs b/w quality
and reproduction and size of digital
representation.
29.2 Audio Clips and Encoding
Standards(Continued)
– E.g. PCM for phone line (huge file production)
– Three ways to reduce the size
Produce
data at
2.2 kbps
» Fewer samples: Low quality
» Fewer bits: Low quality
» Compression: Delay(require fast CPU) good when
delay is not important.
29.3 Audio and Video
Transmission and Reproduction
AV application are real-time: timely
transmission (missing data is skipped).
 How can a network guarantee that the
stream is delivered at exactly the same rate
that the sender used?

– Telephone system way: the entire system is
engineered(digital circuits included) to deliver
output at the same rate of the input even for
multiple paths.
29.3 Audio and Video Transmission and
Reproduction(cont)
– IP network is not isochronous for the delay
introduced – vary delay is called jitter.
– Additional protocol is needed in addition to IP;
» Each packet must have timestamp to tell the sender
when to play back.
» This is important b/c it tells the receiver to pause
when a packet is lost or sender stops encoding.
29.4 Jitter and Playback Delay
 How
can a receiver recreate a signal
accurately if the network introduces a
jitter?
– Playback buffer (similar to queue)
– How does it work?
» The receiver introduces a delay until the buffer is filled with
incoming data (Threshold-playback point) – figure 29.1- (K) is
the unit of time of data to be played.
» The receiver plays K time units.
» If no jitter , datagrams continue to arrive at the same rate, so
the buffer is filled with K time units of un-played data
29.4 Jitter and Playback
Delay(Cont)
» If small delay, playback won’t be affected, the buffer
decreases as data are extracted, playback continues
for K units, once the delayed datagrams arrive
buffer will be refilled.
» If a datagram is lost, buffer will be empty, output
pauses for time corresponding for the missing data.


K is small – needed buffer will be used before delayed
data arrive.
K is too large – immunity to jitter with noticeable delay (in
addition to NW delay) to user.
» Playback is still used despite disadvantages.
29.5 Real-Time Transport
Protocol (RTP)
It does not provide timely transmission.
Timely manner depends on the underlying
system.
 It provides:

– Sequence Number
– Timestamp

For the receiver to
control playback.
RTP does not distinguish b/w types of data;
therefore, it does not enforce uniform
interpretation of semantics.
29.5 Real-Time Transport
Protocol (RTP) (Cont)
 RTP header
provides needed
information for interpretation by the
receiver:
– 2 bit version (current 2)
– 16 bit SEQUENCE NUM: first one is randomly
chosen.
– X-bit is used to identify if the application defines
optional header extension b/w RTP header and pay
load.
– 7 bit PTYPE: determines the interpretation of the most
remaining header field (Pay Load Type).
29.5 Real-Time Transport
Protocol (RTP) (Cont)
– P-bit specify whether padding is in effect to the
pay load. (Encryption: How data is allocated in
blocks).
– M-bit used by the application (Marking points –
e.g. beginning of video stream)
– 32-bit TIMESTAMP – affected by the type at
which first octet is digitized.
29.6 Streams, Mixing, and
Multicasting

Key Part to RTP is its support for
translation or mixing.
– Translation: changing the encoding of a stream
at an intermediate station.
– Mixing: receiving streams of data from
multiple sources, combining them into a single
stream, and sending the results.
» Mixers are important to service multiple streams in
conferencing.
29.6 Streams, Mixing, and
Multicasting(Cont.)
The field SYNCHRONIZATION SOURCE
IDENTIFIER specifies. Each source must
choose a unique identifier. If mixer is
enabled, the mixer will be the source of the
new stream.
 The original source is not lost b/c mixer
uses CONTRIBUTING SOURCE ID to
identify the actual stream source.
 CC-field gives the number of contributing
sources.

29.6 Streams, Mixing, and
Multicasting(Cont.)
RTP works with IP multicasting and mixing
especially in multicast environment.
 For example, in teleconference situation,
unicast is cumbersome; however,
multicasting will allow multi-users to
communicate both ways at the same time.
Mixers make this possible by reading
several inputs resulting in fewer datagrams.

29.7 RTP Encapsulation
RTP is a transport-level protocol working
on the top of UDP.
 This means that it needs to be encapsulated
in UDP before the final encapsulation in IP
datagram.
 RTP does not have a reserved port number.
Port is allocated for each session, and
remote app must inform about port number.
RTP prefer even numbers.

29.8 RTP Control Protocol
So far, Real-Time transmission has been
explained as a protocol allowing
reproduction of A/V data.
 Monitoring the underlying network is as
important as the protocol itself during each
session, and providing out of band com b/w
endpoints. (Adaptive applications).
 An application may adjust the buffer size, or
choose lower band width due to NW cong.

29.8 RTCP (Cont.)
Out of Band can be used to send
information in parallel with real time like
caption.
 RTP control protocol (RTCP) provides the
needed control functionality.
 RTCP: allows senders and receivers to
transmit a series of reports one to another
that contain additional info about data
transferred in addition to NW performance.
 RTCP is encapsulated in UDP using a port
number that is greater than RTP port
number.

29.9 RTCP Operation
Uses 5 basic message type:
 200 - Sender Report - provides absolute
timestamp
– Absolute timestamp is essential to synchronize
multiple streams
– Since RTP require separate stream for each media ,
transmission of video/audio require 2 streams

201 - Receiver Report - Inform source about
conditions of reception
– allow participating receivers & senders in a session to
learn about reception conditions of other receivers
29.9 RTCP Operation
– allow receivers to adapt their rate of reporting to
avoid using excessive bandwidth & overwhelming
the sender

202 - Source Desc. Message - general info
about user (owns/ control source)
– Each message contain 1 section for each outgoing
RTP stream
203 - Bye Message - Shutting down a stream
 204 - Application Specific Message - extend
basic facility to allow application to define
message type

29.10 IP telephony & Signaling
Real-time transmission: use of IP as the
foundation for telephone service
 Researches are investigation 3 components to
replace isochronous systems:

– RTP is needed to transfer a digitized signal across
an IP internet correctly
– Mechanism is needed to establish and terminate
telephone calls
– Researches are exploring ways an IP internet can
function like an isochronous network
29.10 IP telephony & Signaling
Telephone industry use Signaling : process of
establishing a telephone call
 Public Switched Telephone Network (PSTN)
uses Signaling System 7 (SS7)
– performs call routing before any audio is sent

– handles call forwarding and error conditions
29.10 IP telephony & Signaling
Signaling functionality must be available before
IP can be used to make calls
 IP telephony must be also compatible with extant
telephone standards
 Must be possible for IP telephony system to
interoperate with the conventional phone system
at all levels.

29.10 IP telephony & Signaling
The general approach to interoperability
uses a gateway between IP & conventional
phone system
 Standards for IP Telephony:

– ITU has defined a suite or protocol known as
H.323
– IETF has proposed a signaling protocols know
as SIP
29.10.1 H.323 Standards
Originally created to allow the transmission of
voice over local area
 Then it was extended to allow transmission of
voice over IP internets
 Specifies how multiple protocols can be
combined to form functional IP telephony
 Defines gateways & gatekeepers :

– provide a contact point for telephones using IP.
– Each IP Telephone must register with a gatekeeper
29.10.1 H.323 Standards

H.323 relies on 4 major protocols:
–
–
–
–

H.225.0 Signaling used to establish a call
H.224 Control and feedback during the call
RTP Real-time data transfer
T.120 Exchange of data associated with a call
Fig 29.5 illustrates relationship among the
H.323 protocols
29.10.2 Session Initiation
Protocol (SIP)
Covers only signaling, doesn't supply all of
H.323 functionality
 Uses client-server interaction, with servers
being divided into 2 types:

– user agent server runs in a SIP telephone
» assigned an identifier: user@site
– intermediate server ; between 2 SIP telephone
» handles call set up and call forwarding
29.10.2 Session Initiation
Protocol (SIP)
SIP relies on Session Description Protocols
SDP (companion protocol)
 SDP important in conference call

– participants join and leave dynamically

SDP specifies media encoding, protocols
number and multicast address
29.11 Resource
Reservation/Quality of Service

Quality of Service (QoS) refers to statistical
performance guarantees
– regarding loss, delay, jitter and throughput
An isochronous network that meet strict
perfomacnce bounds provide QoS
 Packet switched network doesn't provide
QoS
 Is QoS needed for real-time transfer of
voice & video over IP?

29.11 Resource
Reservation/Quality of Service
Internet send audio but operates without
QoS
 ATM, derived from telephone system
model, provide QoS guarantees
 IETF adopted a differentiated services
approach

– divide traffic into separate QoS classes
– sacrifice fine grain control for less complex
forwarding
29.12 QoS Utilization &
Capacity

Central issue is utilization
– a network with 1% utilization: doesn’t need
QoS
– a network with 1o1% utilization: will fail under
any QoS

Proponent who argue for QoS assert that
QoS mechanism is important because:
– by dividing the existing resources among more
users, system become more “fair”
29.12 QoS Utilization &
Capacity
– by shaping traffic, the network run at higher
utilization without danger of collapse
As long as rapid increases in capacity
continues, QoS represent cause unnecessary
overhead
 When demand rises more rapidly than
capacity, it becomes an economic issue

29.13 RSVP
How can IP network provide QoS?
 IETF produced 2 protocols: RSVP & COPS
 QoS cannot be added at the application layer to
IP; basic infrastructure must change
 Infrastructure must change: routers must agree
to reserve resources
 Endpoints must send a request to spefiicy
resources needed before data is sent
 As datagrams traverse the flow, routers need to
monitor (traffic policing) and control traffic
forwarding

29.13 RSVP

Control of queuing is needed:
– router must implement a queuing policy that meets
guaranteed bounds on delay
– router must smooth packet burst (traffic shaping)
RSVP is not a routing protocols; operates
before any data is sent and handles reservations
request and replies.
 RSVP is unidirectional (simplex); if application
needs QoS in two directions, each point must
use RSVP to request a separate flow

29.14 COPS

When an RSVP arrivers a router must evaluate:
– feasibility : a local decision
– policies: requires global cooperation
IETF architecture uses 2-level model:
» when router receiver RSVP request, it becomes a client
which consult server :Policy Decision Point (PDP) to
determine whether request meets policy constraints
» if PDP approves a request, router must operate as Policy
Point Point (PEP)to ensure traffic does not exceed the
approved policy

COPS protocol define the client-server
interaction between a router and a PDP
29.14 COPS
Although COPS defines it own message
header, the underlying format shares many
details with RSVP
 When a router receives an RSVP request:

– extract items related to policy
– place them in a COPS message
– send the result to PDP
Summary
Audio data can be encoded in digital form
(hardware:codec)
 Pulse Code Modulation (PCM) produce
digital values at 64 Kbps
 RTP is used to transfer real-time data across
an IP internet. Each message contain :

– sequence number
– a media timestamp
Summary
RTCP is used to supply information about sources
& allow mixer to combine several streams
 Debate continues where Q0S guarantees is
needed to provide real-time
 Endpoints use RSVP to request a flow with
specific QoS; intermediate routers either approve
or deny the request
 When RSVP request arrives, router use COPS to
contact PDP and verify that request meets policy
constraints
