1. CSE679: Lecture “Voice and Video over IP (VVoIP)” Prasad Calyam, Sr. Systems Developer/Engineer, Ohio Supercomputer Center 6 th Nov 2007

2. Topics of Discussion r Introduction r Signaling Protocols Terminology r Introduction to H.323 - ITU Standard r Introduction to SIP – IETF Standard r Comparison of H.323 and SIP r Basics of RTP, RTCP r Factors affecting VVoIP System Performance r Measuring VVoIP System Performance m OSC’s H.323 Beacon Tool m OSC’s Vperf Tool r Conclusion

3. Voice and Video over IP (VVoIP) r Large-scale deployments of VVoIP are on the rise m VoIP Skype, Yahoo Messenger, Google Talk m Video streaming (one-way voice and video) MySpace, Google Video, YouTube, IPTV, … m Video conferencing (two-way voice and video) Polycom, WebEx, Acrobat Connect, … r VVoIP popularity reasons m Increased access to broadband m Advances in standardization of H.323 and SIP protocols r Today’s protocols allow a wide variety of communication devices to talk to each other

4. VVoIP Deployment

5. 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 Internet Router Multipoint Control Unit

6. Desktop and Room Videoconferencing Systems

7. 3 Ways to Videoconference over the Internet 1. Point-to-Point

8. 3 Ways to Videoconference over the Internet (Contd.) 2. Multi-Point Star Topology

9. 3 Ways to Videoconference over the Internet (Contd.) 3. Multi-Point Multi-Star Topology

10. Megaconferences – World’s largest Annual Internet Videoconferences MCU Cascading Live/Archive Streaming World sites participation Group Music, 3G Video, Antartica, Virtual Picnics, …

11. Signaling Protocols Terminology r Call Establishment and Teardown r Call Control and Supplementary Services m Call waiting, Call hold, Call transfer r Capability Exchange r Admission Control r Protocol Encoding (ASN1, HTTP)

12. H.323 – ITU Standard r H.323 is an umbrella standard that defines how real-time multimedia communications such as Videoconferencing can be supported on packet switched networks (Internet) r Devices: Terminals, Gateways, Gatekeepers and MCUs r Codecs: m Video: H.261, H.263, H.264 m Audio: G.711, G.722, G.723.1 r Signaling: H.225, H.245 r Transport Mechanisms: TCP, UDP, RTP and RTCP r Data collaboration: T.120 r Many others…

13. H.323 Protocol Stack

14. H.323 Call setup and teardown

15. H.323 Call setup and teardown (Contd.)

16. SIP - IETF Standard r Session Initiation Protocol (SIP) r SIP Elements: User Agent Client (UAC), User Agent Server (UAS) m 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) r Server Types: Redirect Server, Proxy Server and Registrar m SIP Proxy: perform application layer routing of SIP requests and responses. m 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)

17. SIP Deployment Architecture Friend at San Jose OSU You at Hawaii

18. Comparison of H.323 and SIP r Evolution m H.323 evolved from Telecommunications Community (ITU-T) m SIP evolved from Internet Community (IETF) r Protocols m Differences in the signaling and control procedures m Off-the-record: SIP is equivalent to H.225 and RAS of H.323 r Feature sets m Functionality m Quality of Service m Manageability m Scalability m Flexibility m Interoperability m Ease of Implementation

20. Basics of RTP and RTCP r RTP m 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 r RTCP m To allow monitoring of data delivery in a manner scalable to large multicast networks m To provide minimal control and identification functionality r RTP and RTCP need best effort delivery m UDP provides this

21. RTP Packet

22. RTCP Packet

23. Ethereal RTP Analysis – Try at Home! r Use the OPENXTRA version of Ethereal! http://resource.intel.com/telecom/support/appnotes/9008/9008an.pdf r Steps for analyzing the Traces m Load the packet trace into Ethereal Trace will contain both forward and reverse direction streams (Check “Source” and “Destination” IP addresses) r Decode streams as RTP (default is UDP) m This will mark all related packets as belonging to a specific audio and video codec streams r Analyze individual audio or video streams m Import various information fields as.csv file (“Save as CSV” option) m 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

24. Ethereal RTP Analysis (2) General UDP Stream decoded as an H.263 payload stream

25. Ethereal RTP Analysis (3) Audio Stream Video Stream

26. 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

27. Ethereal RTP Analysis (5) An Imported CSV File!

28. Ethereal RTP Analysis (6) Create interesting visualizations to understand various RTP packet characteristics; can do the same for both Voice and Video packets!!!

29. VVoIP System r End-user Quality of Experience (QoE) is mainly dependent on Network Quality of Service (QoS) metrics m QoS Metrics: bandwidth, delay, jitter, loss m Device factors such as voice/video codecs, peak video bit rate (a.k.a. 256/384/768 dialing speed) also matter r Research underway to map the network QoS to end-user QoE End-user QoE Network QoS

30. Understanding Delay… Compression Delay Transmission Delay Electronic Delay Propagation Delay Processing Delay Queuing Delay Resynchronization Delay Decompression Delay Presentation Delay SENDER SIDENETWORKRECEIVER SIDE r Delay is the amount of time that a packet takes to travel from the sender’s application to reach the receiver’s destination application m Caused by codecs, router queuing delays, … r One-way delay requirement is stringent for H.323 Videoconferencing to maintain good interaction between both ends

31. Understanding Jitter… r Jitter is the variation in delay of the packets arriving at the receiving end m Caused by congestion, insufficient bandwidth, varying packet sizes in the network, out of order packets, … r Excessive jitter may cause packet loss in the receiver jitter buffers thus affecting the playback of the audio and video streams

32. Understanding Loss… r 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 m Caused by line properties (Layer 1), full buffers (Layer 3) or late arrivals (at the application)

33. Understanding Bandwidth bottleneck …

34. Voice and Video Packet Streams  Total packet size ( tps ) – sum of payload ( ps ), IP/UDP/RTP header (40 bytes), and Ethernet header (14 bytes) r Dialing speed is ; = 64 Kbps fixed for G.711 voice codec  Voice has fixed packet sizes ( tps voice ≤ 534 bytes)  Video packet sizes are dependent on a lev in the content

35. Video a lev  Low a lev  Slow body movements and constant background; E.g. Claire video sequence  High a lev  Rapid body movements and/or quick scene changes; E.g. Foreman video sequence r ‘Listening’ versus ‘Talking’  Talking video a lev (i.e., High) consumes more bandwidth than Listening video a lev (i.e., Low) Claire Foreman

36. Factors affecting VVoIP System Performance r Human Factors  Video a lev  Individual perception of audio/video quality - q mos r Device Factors m MCUs, Routers, Firewalls, NATs, Modems, Operating System, Processor, memory, … r Network Factors m Bandwidth, Delay, Jitter, Loss

37. Measuring VVoIP System Performance r Challenges for monitoring large-scale VVoIP deployments m Real-time or online monitoring of end-user Quality of Experience (QoE) Traditional network Quality of Service (QoS) monitoring not adequate m Need objective techniques for automated network-wide monitoring Cannot rely on end-users to provide subjective rankings – expensive and time consuming m Objective QoE measurements can be used for dynamic resource management to optimize end-user QoE

38. Resource Management Example r Multipoint Control Unit (MCU) bridges three or more videoconference participants r MCUs have limited ports; large videoconferences involve cascaded MCUs

39. Resource Management Example Site-B Site-C Site-A Call Admission Controller ? Best performing path from end-user site

40. End-user QoE Types r Streaming QoE m End-user QoE affected just by voice and video impairments Video frame freezing Voice drop-outs Lack of lip sync between voice and video r Interaction QoE m 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 …” r QoE is measured using “Mean Opinion Score” (MOS) rankings

41. Existing Objective Techniques r ITU-T E-Model is a success story for VoIP QoE estimation m OSC’S H.323 Beacon tool has E-Model implementation m 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 r ITU-T J.144 developed for VVoIP QoE estimation m “PSNR-based MOS” – PSNR calculation requires original and reconstructed video frames for frame-by-frame comparisons m Not suitable for online monitoring PSNR calculation is a time consuming and computationally intensive process m Does not consider joint degradation of voice and video i.e., lack of lip synchronization

42. PSNR to MOS Mapping

43. Scenario: A Researcher and an Industry professional want to Videoconference

44. Case1:Researcher is unable to make a call!

45. There was a mis-configured firewall blocking necessary ports…

46. Case2: Industry professional is unable to make a call!

47. His LAN’s Internet connectivity was non- functional at that time…

48. Case3: They connected, but of them experienced bad audio & video!

49. There was congestion at one of the intermediate routers along the path…

52. The performance problem can be anywhere in the E2E Path!!!

53. An end-to-end troubleshooting tool can help!

54. Troubleshooting VVoIP System Performance “OSC H.323 Beacon” r An application-specific measurement tool m To monitor and qualify the performance of an H.323 sessions at the host and in the network (end-to-end) r Useful to an end-user/conference operator/network engineer r Uses OpenH323 and J323Engine libraries r Easy to install and use! r 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.

55. Initial call setup failures and haphazard disconnection detection…

56. Network Health Status… r Delay, Jitter and Loss m Real-time, offline raw data and test session summary

57. Network Health Plots… r Watermarks for “Good”, “Acceptable” and “Poor” grade of quality as experienced by end-user r Delay: (0-150)ms, (150-300)ms, > 300ms r Jitter: (0-20)ms, (20-50)ms, > 50ms r Loss: (0-0.5)%, (0.5-1.5)%, > 1.5 Poor Acceptable Good

58. Audio and Video Quality Assessments r Audio loopback feature r E-Model-based objective MOS ranking r Slider-based subjective MOS ranking

59. Customization of tests… r Test results data folder, TCP/UDP/RTP port settings, H.225 and H.245 parameters, preferred codec, watermarks for delay, jitter, loss, …

60. H.323 Beacon Server

61. Online VVoIP QoE Measurement Problem r Given: m Video-on-demand (streaming) or Videoconferencing (interactive) m Voice/video codec m Dialing speed r Problem: m An objective technique that can estimate both streaming and interactive VVoIP QoE in terms of MOS rankings m Estimation has to be real-time without involving actual end-users, video sequences and VVoIP appliances m An active measurement tool that can: (a) emulate VVoIP traffic on a network path, and (b) uses the objective VVoIP estimation technique Vperf Tool

62. GAP-Model r Earlier studies estimate QoE affected by QoS metrics in isolation m E.g. impact due to only bandwidth/delay/loss/jitter r We consider network health as a combination of different levels of bandwidth, delay, jitter and loss – hence more realistic r The levels are quantified by well-known “Good”, “Acceptable” and “Poor” (GAP) performance levels for QoS metrics r Our strategy m Derive “closed-form expressions” for modeling MOS using offline human subject studies under different network health conditions m 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.

63. Test-cases Reduction Problem r 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 sequence: [,, …,, ] m 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 r 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.

64. Test-case Reduction Strategy-1 r Reduction based on network condition infeasibility m 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 m Reduces the test-cases number from 81 to 42

65. Test-case Reduction Strategy-2 r Reduction based on human-subjects’ ranking inference m 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 with an extremely Poor MOS, it can be inferred that more severe test cases and will also receive extremely Poor MOS m 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)

66. Closed-network Testing r Test environment setup m Testing was automated as much as possible for repeatability r Human subjects selection m 21 belonging to 3 categories: (i) Expert, (ii) General, and (iii) Novice r Double stimulus impairment scale method using Streaming-Kelly, Interactive-Kelly video clips m Human subject compares baseline video sequence with impaired video sequence for MOS ranking m In-band chat channel between human subject and test administrator (a) Isolated LAN Testbed(b) MOS Slider

67. Closed-form Expressions  Polynomial curve fitting on the Streaming and Interactive q mos training data obtained from closed-network testing  Average q mos – mean of the 21 human subject rankings for a particular network health condition  Lower and Upper bound q mos – 25 th and 75 th percentile values To account for the possible q mos variation range influenced by the human subject categories r Hence, 6 sets of regression surface model parameters in GAP-Model

68. Vperf Tool Implementation of GAP-Model  After test duration δt, a set of statistically stable network QoS measurements are obtained r When input to GAP-Model, online VVoIP QoE estimates are instantly produced

69. GAP-Model Validation r GAP-Model Validation with human subjects (V-MOS) and network conditions not tested during model formulation V-MOS within the lower and upper bounds

70. GAP-Model Validation (2) r 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

71. MAPTs Methodology r “Multi-Activity Packet Trains” (MAPTs) measure Interaction QoE in an automated manner m They mimic participant interaction patterns and video activity levels as affected by network fault events m 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.

72. Proposed Solution Methodology (2) ‘repeat’ ‘disconnect’ ‘reconnect’ ‘reorient’ Type-I and Type-II fault detection

73. MAPTs Emulation r Emulation of Participant Interaction Patterns (PIPs) using MAPTs for a given session agenda Normal – PIP 1

74. MAPTs Emulation (2) r Emulation of Participant Interaction Patterns (PIPs) using MAPTs for a “Type-I” network fault event m Type-I: Performance of any network factor changes from Good grade to Acceptable grade over a 5 second duration Repeat – PIP 2

75. MAPTs Emulation (3) r Emulation of Participant Interaction Patterns (PIPs) using MAPTs for a “Type-II” network fault event m Type-II: Performance of any network factor changes from Good grade to Poor grade over a 10 second duration Disconnect/Reconnect/Reorient – PIP 3

76. Vperf Tool Implementation of MAPTs r Per-second frequency of Interim Test Report generation r Interaction QoE reported by Vperf tool - based on the progress of the session- agenda

77. MAPTs Performance r Increased the number of Type-I and Type-II network fault events in a controlled LAN testbed for a fixed session-agenda m NISTnet network emulator for network fault generation r 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

78. Summary r Signaling Protocols Terminology r Introduction to H.323 and SIP r Comparison of H.323 and SIP r Basics of RTP, RTCP r Factors affecting VVoIP System Performance r Measuring VVoIP System Performance m OSC’s H.323 Beacon Tool m OSC’s Vperf Tool

79. Questions?