CSE679: Lecture
description
Transcript of CSE679: Lecture
CSE679: Lecture
“Voice and Video over IP (VVoIP)”
Prasad Calyam,Sr. Systems Developer/Engineer,
Ohio Supercomputer Center6th 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)
Switched Circuit Network(POTS and ISDN)
Gatekeeper
H.323
H.320(over ISDN)
H.324(over POTS)
Speech-Only(telephones)
Corporate LAN
Gateway
SIP
InternetRouter
Multipoint Control Unit
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
Live/Archive Streaming
World sites participation
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
NETWORK
DATA LINK
PHYSICAL
TRANSPORT
SESSION
PRESENTATION
APPLICATION
Supplementary Services
Audio Signal
Video Signal Data
Control
G.711 G.728
H.261 H.263 T.127
T.126
T.124
T.125/T.122
G.722 G.729
G.723.1
RTCP RAS RTP
H.450.3 H.450.2
H.450.1H.235
H.245 H.225UDP TCP
X.224.0
H.323 Call setup and teardown
H.323 Call setup and teardown (Contd.)
TCP CONNECTION
H.245 MESSAGES
RTP STREAM
MEDIA EXCHANGE
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
Friend at San Jose
OSU
You at Hawaii
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)
Pink-marked packets relate to either lost or re-ordered packets!
Re-ordering; 45413 45415 45414(Observe Sequence #s; could also be 2
consecutive packet losses)
Loss
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
Research underway to map the network QoS to end-user QoE
End-user QoENetwork QoS
Understanding Delay…
Compression Delay
Transmission Delay
Electronic Delay
Propagation Delay
Processing Delay
Queuing Delay
Resynchronization Delay
Decompression Delay
Presentation Delay
SENDER SIDE NETWORK RECEIVER SIDE
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)
Claire Foreman
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
Multipoint Control Unit (MCU) bridges three or more videoconference participants
MCUs have limited ports; large videoconferences involve cascaded MCUs
2 U
MCUOpen Port
Resource Management Example
2 U
2 U 2 U
MCU
MCU Cascade
MCU Cascade
MCUMCUOpen Port
Open Port
Open Port
Gatekeeper
Site-B
Site-C
Site-A
Call Admission Controller
?
Best performing path from end-user site
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
Internet2 Abilene Network
GigaPOP
OC2
OC192
Case1:Researcher is unable to make a call!
Internet2 Abilene Network
GigaPOP
OC2
OC192
There was a mis-configured firewall blocking necessary ports…
Internet2 Abilene Network
GigaPOP
OC2
OC192
Case2: Industry professional is unable to make a call!
Internet2 Abilene Network
GigaPOP
OC2
OC192
His LAN’s Internet connectivity was non-functional at that time…
Internet2 Abilene Network
GigaPOP
OC2
OC192
Case3: They connected, but of them experienced bad audio & video!
Internet2 Abilene Network
GigaPOP
OC2
OC192
There was congestion at one of the intermediate routers along the path…
Internet2 Abilene Network
GigaPOP
OC2
OC192
There was congestion at one of the intermediate routers along the path…
Internet2 Abilene Network
GigaPOP
OC2
OC192
There was congestion at one of the intermediate routers along the path…
Internet2 Abilene Network
GigaPOP
OC2
OC192
The performance problem can be anywhere in the E2E Path!!!
Internet2 Abilene Network
GigaPOP
OC2
OC192
An end-to-end troubleshooting tool can help!
Internet2 Abilene Network
GigaPOP
OC2
OC192
3Com
CISCOSYSTEMS
3Com
CISCOSYSTEMS
Core Router
Switch
NMS
CDMA Device
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>, <GGGA>, …, <APPP>, <PPPP>] 81 test cases are burdensome to any human subject
• 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
Human subjects selection 21 belonging to 3 categories: (i) Expert, (ii) General, and (iii) Novice
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
session-agenda
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?