Transcript Part I: Introduction - Computer Science and Engineering

CSE679: Lecture
“Voice and Video over IP (VVoIP)”
Prasad Calyam,
Sr. Systems Developer/Engineer,
Ohio Supercomputer Center
6th Nov 2007
Topics of Discussion
 Introduction
 Signaling Protocols Terminology
 Introduction to H.323 - ITU Standard
 Introduction to SIP – IETF Standard
 Comparison of H.323 and SIP
 Basics of RTP, RTCP
 Factors affecting VVoIP System Performance
 Measuring VVoIP System Performance
 OSC’s H.323 Beacon Tool
 OSC’s Vperf Tool
 Conclusion
Voice and Video over IP (VVoIP)
 Large-scale deployments of VVoIP are on the rise

VoIP
• Skype, Yahoo Messenger, Google Talk

Video streaming (one-way voice and video)
• MySpace, Google Video, YouTube, IPTV, …

Video conferencing (two-way voice and video)
• Polycom, WebEx, Acrobat Connect, …
 VVoIP popularity reasons
 Increased access to broadband
 Advances in standardization of H.323 and SIP protocols
 Today’s protocols allow a wide variety of
communication devices to talk to each other
VVoIP Deployment
VVoIP Deployment (2)
H.323
SIP
Gatekeeper
Corporate LAN
Gateway
Multipoint Control Unit
Switched
Circuit Network
(POTS and ISDN)
Router Internet
H.320
(over ISDN)
H.324
(over POTS)
Speech-Only
(telephones)
Desktop and Room Videoconferencing
Systems
3 Ways to Videoconference over the
Internet
1. Point-to-Point
3 Ways to Videoconference over the
Internet (Contd.)
2. Multi-Point Star Topology
3 Ways to Videoconference over the
Internet (Contd.)
3. Multi-Point Multi-Star Topology
Megaconferences – World’s largest
Annual Internet Videoconferences
MCU
Cascading
World sites
participation
Live/Archive
Streaming
Group Music, 3G
Video, Antartica,
Virtual Picnics, …
Signaling Protocols Terminology
 Call Establishment and Teardown
 Call Control and Supplementary Services
 Call waiting, Call hold, Call transfer
 Capability Exchange
 Admission Control
 Protocol Encoding (ASN1, HTTP)
H.323 – ITU Standard
 H.323 is an umbrella standard that defines how
real-time multimedia communications such as
Videoconferencing can be supported on packet
switched networks (Internet)
 Devices: Terminals, Gateways, Gatekeepers and
MCUs
 Codecs:


Video: H.261, H.263, H.264
Audio: G.711, G.722, G.723.1
 Signaling: H.225, H.245
 Transport Mechanisms: TCP, UDP, RTP and RTCP
 Data collaboration: T.120
 Many others…
H.323 Protocol Stack
APPLICATION
G.711
Video Signal
G.728
H.261
H.263
G.722
G.729
Audio Signal
G.723.1
Data
T.127
T.126
PRESENTATION
SESSION
T.124
RTCP
RAS
RTP
TRANSPORT
T.125/
T.122
Supplementary Services
H.450.3
H.235
H.450.2
H.450.1
X.224.0
Control
UDP
NETWORK
DATA LINK
PHYSICAL
H.245
H.225
TCP
H.323 Call setup and teardown
H.323 Call setup and teardown (Contd.)
RTP STREAM
MEDIA EXCHANGE
TCP CONNECTION
H.245 MESSAGES
CALL TEARDOWN
END SESSION COMMAND
CLOSE LOGICAL CHANNEL
END SESSION COMMAND
CLOSE LOGICAL CHANNEL
RELEASE COMPLETE
RELEASE COMPLETE
SIP - IETF Standard
 Session Initiation Protocol (SIP)
 SIP Elements: User Agent Client (UAC), User
Agent Server (UAS)

Easy to locate users due to the flexibility in SIP to
contact external location servers to determine user or
routing policies (url, email ID, e.g. [email protected])
 Server Types: Redirect Server, Proxy Server and
Registrar


SIP Proxy: perform application layer routing of SIP
requests and responses.
SIP Registrar: UAC sends a registration message and the
Registrar stores registration information in a location
service using a non-SIP protocol (E.g. LDAP)
SIP Deployment Architecture
OSU
You at Hawaii
Friend at San Jose
Comparison of H.323 and SIP
 Evolution


H.323 evolved from Telecommunications Community (ITU-T)
SIP evolved from Internet Community (IETF)
 Protocols


Differences in the signaling and control procedures
Off-the-record: SIP is equivalent to H.225 and RAS of H.323
 Feature sets







Functionality
Quality of Service
Manageability
Scalability
Flexibility
Interoperability
Ease of Implementation
Basics of RTP and RTCP
 RTP
 Provides end-to-end network transport functions suitable
for applications transmitting real-time data
• Audio, video or simulation data, over multicast or unicast
network services
 RTCP
 To allow monitoring of data delivery in a manner scalable to
large multicast networks
 To provide minimal control and identification functionality
 RTP and RTCP need best effort delivery
 UDP provides this
RTP Packet
RTCP Packet
Ethereal RTP Analysis – Try at Home!
 Use the OPENXTRA version of Ethereal!
http://resource.intel.com/telecom/support/appnotes/9008/9008an.pdf
 Steps for analyzing the Traces
 Load the packet trace into Ethereal
•
Trace will contain both forward and reverse direction streams (Check “Source”
and “Destination” IP addresses)
 Decode streams as RTP (default is UDP)
 This will mark all related packets as belonging to a specific audio and video
codec streams
 Analyze individual audio or video streams
 Import various information fields as .csv file (“Save as CSV” option)
 Also has wave file generation relating to an audio stream (“Save Payload”
option)
• Works only for G.711 Codec streams!
• Good for PESQ where you want to compare original and degraded wave files to
obtain Objective MOS information
Ethereal RTP Analysis (2)
General UDP Stream decoded
as an H.263 payload stream
Ethereal RTP Analysis (3)
Audio Stream
Video Stream
Ethereal RTP Analysis (4)
Loss
Re-ordering; 45413 45415 45414
(Observe Sequence #s; could also be 2
consecutive packet losses)
Pink-marked packets relate to either lost or re-ordered packets!
Ethereal RTP Analysis (5)
An Imported CSV File!
Ethereal RTP Analysis (6)
Create interesting visualizations to understand various RTP packet
characteristics; can do the same for both Voice and Video packets!!!
VVoIP System
 End-user Quality of Experience (QoE) is mainly dependent on
Network Quality of Service (QoS) metrics
QoS Metrics: bandwidth, delay, jitter, loss
 Device factors such as voice/video codecs, peak video bit rate (a.k.a.
256/384/768 dialing speed) also matter
Network QoS
End-user QoE

 Research underway to map the network QoS to end-user QoE
Understanding Delay…
SENDER SIDE
NETWORK
RECEIVER SIDE
Compression Delay
Propagation Delay
Resynchronization Delay
Transmission Delay
Processing Delay
Decompression Delay
Electronic Delay
Queuing Delay
Presentation Delay
 Delay is the amount of time that a packet takes to travel from
the sender’s application to reach the receiver’s destination
application
 Caused by codecs, router queuing delays, …
 One-way delay requirement is stringent for H.323
Videoconferencing to maintain good interaction between both
ends
Understanding Jitter…
 Jitter is the variation in delay of the packets arriving at the
receiving end

Caused by congestion, insufficient bandwidth, varying
packet sizes in the network, out of order packets, …
 Excessive jitter may cause packet loss in the receiver jitter
buffers thus affecting the playback of the audio and video
streams
Understanding Loss…
 Packet Loss is the packets discarded deliberately (RED,
TTL=0) or non-deliberately by intermediate links, nodes and
end-systems along a given transmission path
 Caused by line properties (Layer 1), full buffers (Layer 3)
or late arrivals (at the application)
Understanding Bandwidth bottleneck …
Voice and Video Packet Streams
 Total packet size (tps) – sum of payload (ps),
IP/UDP/RTP header (40 bytes), and Ethernet
header (14 bytes)
 Dialing speed is
;
= 64 Kbps
fixed for G.711 voice codec

Voice has fixed packet sizes (tpsvoice ≤ 534 bytes)

Video packet sizes are dependent on alev in the content
Video alev
 Low alev

Slow body movements and constant background; E.g. Claire video
sequence
 High alev

Rapid body movements and/or quick scene changes; E.g. Foreman video
sequence
 ‘Listening’ versus ‘Talking’
Talking video alev(i.e., High) consumes more bandwidth than Listening video alev
(i.e., Low)
Foreman
Claire

Factors affecting VVoIP System Performance
 Human Factors
 Video alev
 Individual perception of audio/video quality - qmos
 Device Factors
 MCUs, Routers, Firewalls, NATs, Modems, Operating
System, Processor, memory, …
 Network Factors
 Bandwidth, Delay, Jitter, Loss
Measuring VVoIP System Performance
 Challenges for monitoring large-scale VVoIP
deployments

Real-time or online monitoring of end-user Quality of
Experience (QoE)
• Traditional network Quality of Service (QoS) monitoring not
adequate

Need objective techniques for automated network-wide
monitoring
• Cannot rely on end-users to provide subjective rankings – expensive
and time consuming

Objective QoE measurements can be used for dynamic resource
management to optimize end-user QoE
Resource Management Example
Open
Port 2 U
MCU
 Multipoint Control Unit (MCU) bridges three or more
videoconference participants
 MCUs have limited ports; large videoconferences involve cascaded
MCUs
Resource Management Example
Open
Port 2 U
MCU
Cascade
MCU
Cascade
Site-A
Open 2 U
Port
Site-C
MCU
MCU
Open 2 U
Port
MCU
Site-B
Best performing path
from end-user site
Gatekeeper
Call Admission Controller
?
End-user QoE Types
 Streaming QoE

End-user QoE affected just by voice and video impairments
• Video frame freezing
• Voice drop-outs
• Lack of lip sync between voice and video
 Interaction QoE

End-user QoE also affected by additional interaction effort in a conversation
• “Can you repeat what you just said?”
• “This line is noisy, lets hang-up and reconnect…”
 QoE is measured using “Mean Opinion Score” (MOS) rankings
Existing Objective Techniques
 ITU-T E-Model is a success story for VoIP QoE estimation
 OSC’S H.323 Beacon tool has E-Model implementation
 It does not apply for VVoIP QoE estimation
• Designed for CBR voice traffic and handles only voice related impairments
• Does not address the VBR video traffic and impairments such as video frame freezing
 ITU-T J.144 developed for VVoIP QoE estimation
 “PSNR-based MOS” – PSNR calculation requires original and reconstructed
video frames for frame-by-frame comparisons
 Not suitable for online monitoring
• PSNR calculation is a time consuming and computationally intensive process

Does not consider joint degradation of voice and video i.e., lack of lip
synchronization
PSNR to MOS Mapping
Scenario: A Researcher and an Industry
professional want to Videoconference
GigaPOP
OC2
OC192
Internet2 Abilene Network
Case1:Researcher is unable to make a call!
GigaPOP
OC2
OC192
Internet2 Abilene Network
There was a mis-configured firewall blocking
necessary ports…
GigaPOP
OC2
OC192
Internet2 Abilene Network
Case2: Industry professional is unable to
make a call!
GigaPOP
OC2
OC192
Internet2 Abilene Network
His LAN’s Internet connectivity was nonfunctional at that time…
GigaPOP
OC2
OC192
Internet2 Abilene Network
Case3: They connected, but of them
experienced bad audio & video!
GigaPOP
OC2
OC192
Internet2 Abilene Network
There was congestion at one of the
intermediate routers along the path…
GigaPOP
OC2
OC192
Internet2 Abilene Network
There was congestion at one of the
intermediate routers along the path…
GigaPOP
OC2
OC192
Internet2 Abilene Network
There was congestion at one of the
intermediate routers along the path…
GigaPOP
OC2
OC192
Internet2 Abilene Network
The performance problem can be anywhere in
the E2E Path!!!
GigaPOP
OC2
OC192
Internet2 Abilene Network
An end-to-end troubleshooting tool can help!
3 Com
CISCO SYSTEMS
GigaPOP
OC2
OC192
3Com
Core Router
CISCO SYSTEMS
Switch
NMS
CDMA Device
Internet2 Abilene Network
Troubleshooting VVoIP System Performance
“OSC H.323 Beacon”
 An application-specific measurement tool

To monitor and qualify the performance of an H.323
sessions at the host and in the network (end-to-end)
 Useful to an end-user/conference operator/network
engineer
 Uses OpenH323 and J323Engine libraries
 Easy to install and use!
 Open source
http://www.itecohio.org/beacon
P. Calyam, W. Mandrawa, M. Sridharan, A. Khan, P. Schopis, “H.323 Beacon: An H.323 application related end-to-end
performance troubleshooting tool”, ACM SIGCOMM 2004 Workshop on Network Troubleshooting (NetTs), 2004.
Initial call setup failures and haphazard
disconnection detection…
Network Health Status…
 Delay, Jitter and Loss
 Real-time, offline raw data and test session summary
Network Health Plots…
 Watermarks for “Good”, “Acceptable” and “Poor” grade of quality as
experienced by end-user
 Delay: (0-150)ms, (150-300)ms, > 300ms
 Jitter: (0-20)ms, (20-50)ms, > 50ms
 Loss: (0-0.5)%, (0.5-1.5)%, > 1.5
Poor
Acceptable
Good
Audio and Video Quality Assessments
 Audio loopback feature
 E-Model-based objective MOS ranking
 Slider-based subjective MOS ranking
Customization of tests…
 Test results data folder, TCP/UDP/RTP port settings, H.225
and H.245 parameters, preferred codec, watermarks for
delay, jitter, loss, …
H.323 Beacon Server
Online VVoIP QoE Measurement Problem
 Given:
 Video-on-demand (streaming) or Videoconferencing (interactive)
 Voice/video codec
 Dialing speed
 Problem:
 An objective technique that can estimate both streaming and interactive
VVoIP QoE in terms of MOS rankings
 Estimation has to be real-time without involving actual end-users, video
sequences and VVoIP appliances
 An active measurement tool that can: (a) emulate VVoIP traffic on a network
path, and (b) uses the objective VVoIP estimation technique
Vperf Tool
GAP-Model

Earlier studies estimate QoE affected by QoS metrics in isolation

E.g. impact due to only bandwidth/delay/loss/jitter
We consider network health as a combination of different levels of bandwidth,
delay, jitter and loss – hence more realistic
 The levels are quantified by well-known “Good”, “Acceptable” and “Poor” (GAP)
performance levels for QoS metrics
 Our strategy



Derive “closed-form expressions” for modeling MOS using offline human subject
studies under different network health conditions
Leverage the GAP-Model in Vperf tool for online QoE estimation for a measured
set of statistically stable network QoS metrics
P. Calyam, M. Sridharan, W. Mandrawa, P. Schopis “Performance Measurement and Analysis of H.323 Traffic”,
Passive and Active Measurement Workshop (PAM), Proceedings in Springer-Verlag LNCS, 2004.
Test-cases Reduction Problem
 Modeling QoE as a function of 4 QoS metrics in 3 levels (GAP)
requires administering 81 test cases per human subject

Test-cases ordering using < bnet dnet lnet jnet > sequence: [<GGGG>,

81 test cases are burdensome to any human subject
<GGGA>, …, <APPP>, <PPPP>]
• They involve long hours of testing
• Results may be error-prone due to human subject exhaustion
 To overcome this problem, we developed novel “Test-cases
Reduction” strategies
P. Calyam, E. Ekici, C. -G. Lee, M. Haffner, N. Howes, “A ‘GAP-Model’ based Framework for Online VVoIP QoE
Measurement”, In Second-round Review - Journal of Communications and Networks (JCN), 2007.
Test-case Reduction Strategy-1
 Reduction based on network condition infeasibility

We conducted a network emulator (NISTnet) qualification study to
identify any practically infeasible network conditions
• E.g. there cannot be Good loss levels when there is Poor bandwidth level
provisioned in the network path

Reduces the test-cases number from 81 to 42
Test-case Reduction Strategy-2
 Reduction based on human-subjects’ ranking inference
 Eliminate more severe test cases during the testing based on the Poor
rankings for less severe test cases
• E.g. If human subject ranked test case <GPPP> with an extremely Poor MOS, it can
be inferred that more severe test cases <APPP> and <PPPP> will also receive
extremely Poor MOS

Reduces the 42 test-cases further depending on the human subjects’
rankings during the testing
NOTE: Our test-case reduction strategies resulted in atmost 90 minutes of testing
time per human subject (including training, administering and short-breaks)
Closed-network Testing



Test environment setup

Testing was automated as much as possible for repeatability

21 belonging to 3 categories: (i) Expert, (ii) General, and (iii) Novice
Human subjects selection
Double stimulus impairment scale method using Streaming-Kelly, Interactive-Kelly
video clips


Human subject compares baseline video sequence with impaired video sequence for MOS
ranking
In-band chat channel between human subject and test administrator
(a) Isolated LAN Testbed
(b) MOS Slider
Closed-form Expressions

Polynomial curve fitting on the Streaming and Interactive qmos training data
obtained from closed-network testing
 Average qmos – mean of the 21 human subject rankings for a particular network health


condition
Lower and Upper bound qmos – 25th and 75th percentile values
• To account for the possible qmos variation range influenced by the human subject categories
Hence, 6 sets of regression surface model parameters in GAP-Model
Vperf Tool Implementation of GAP-Model
 After test duration δt, a set of statistically stable network QoS
measurements are obtained
 When input to GAP-Model, online VVoIP QoE estimates are instantly
produced
GAP-Model Validation
 GAP-Model Validation with human subjects (V-MOS) and network
conditions not tested during model formulation
V-MOS within the lower
and upper bounds
GAP-Model Validation (2)
 GAP-Model validation with ITU-T J.144 estimates (P-MOS) and network
conditions not tested during model formulation
P-MOS within the lower
and upper bounds
MAPTs Methodology
 “Multi-Activity Packet Trains” (MAPTs)
measure Interaction QoE in an automated
manner



They mimic participant interaction patterns and video
activity levels as affected by network fault events
Given a session-agenda, excessive talking than normal due to
unwanted participant interaction patterns impacts
Interaction QoE
“Unwanted Agenda-bandwidth” measurement and compare
with baseline (consumption during normal conditions)
• Higher values indicate poor interaction QoE and caution about
potential increase in Internet traffic congestion levels
• Measurements serve as an input for ISPs to improve network
performance using suitable traffic engineering techniques
P. Calyam, M. Haffner, E. Ekici, C. -G. Lee, “Measuring Interaction QoE in Internet Videoconferencing”, IEEE/IFIP
Management of Multimedia and Mobile Networks and Services (MMNS), Proceedings in Springer-Verlag LNCS, 2007.
Proposed Solution Methodology (2)
‘repeat’
‘disconnect’
‘reconnect’
‘reorient’
Type-I and Type-II fault detection
MAPTs Emulation
 Emulation of Participant Interaction Patterns (PIPs) using MAPTs
for a given session agenda
Normal – PIP1
MAPTs Emulation (2)
 Emulation of Participant Interaction Patterns (PIPs) using MAPTs for a
“Type-I” network fault event

Type-I: Performance of any network factor changes from Good grade to
Acceptable grade over a 5 second duration
Repeat – PIP2
MAPTs Emulation (3)
 Emulation of Participant Interaction Patterns (PIPs) using MAPTs for a
“Type-II” network fault event

Type-II: Performance of any network factor changes from Good grade to
Poor grade over a 10 second duration
Disconnect/Reconnect/Reorient – PIP3
Vperf Tool Implementation of MAPTs


Per-second frequency of Interim Test Report generation
Interaction QoE reported by Vperf tool - based on the progress of the sessionagenda
MAPTs Performance
 Increased the number of Type-I and Type-II network fault events in a
controlled LAN testbed for a fixed session-agenda

NISTnet network emulator for network fault generation
 Recorded Unwanted Agenda-Bandwidth and Unwanted Agenda-Time
measured by Vperf tool
(a) Impact of Type-I Network Fault Events
on Unwanted Agenda-Bandwidth
(b) Impact of Type-I and Type-II Network
Fault Events on Unwanted Agenda-Time
Summary
 Signaling Protocols Terminology
 Introduction to H.323 and SIP
 Comparison of H.323 and SIP
 Basics of RTP, RTCP
 Factors affecting VVoIP System Performance
 Measuring VVoIP System Performance
 OSC’s H.323 Beacon Tool
 OSC’s Vperf Tool
Questions?