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. pcalyam@osc.edu)

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?