1 Carol Davids © 2010

Real-Time Communications LabPrograms and Projects

SIPNOC

June 26, 2012

Herndon, VA

Carol Davids

davids@iit.edu

2

Outline

• Lab Mission and History• Lab Architecture• Programs and Projects • Future Directions

3

About the lab

• Mission

• The lab is an educational facility dedicated to teaching, research and development activities that further the goals of networked communications.

• Links

• RTC Lab: http://rtc-lab.itm.iit.edu/

• Recent Events: http://rtc-lab.itm.iit.edu/events_pages/events_recent.php

• RTC Conference: http://www.rtc-conference.com/

4

History

• Founded in the summer of 2004.

• Web presence attracts industry projects in the areas of performance testing and development.

• Projects attract donations of equipment and infrastructure, as well as engineers and technologists who are willing to mentor and lead them.

• A Wireless Extension to the lab was built in 2010.

• A Main Campus Extension, about 30 miles away from the original lab, was built in 2010.

5

Selection Criteria

Industry projects are selected based on:

•educational content

•significance to the industry and research communities

•availability of resources.

6

Architecture

• The lab is designed to support multiple simultaneous projects and multiple simultaneous users, including users who are performing weekly lab exercises as part of their course work.

• To meet this goal the following architecture was chosen:– Component switches, hubs, routers and application servers are

located on racks at the sides of the room. – Users work at benches that contain test jacks wired to the

racks. – The test jacks are permanently cabled to jacks that appear on

two control frames at the front of the room.– Users can create connections to any switch, hub, router, or

application server that is racked by simply plugging into a test jack on the bench.

7

Layout for multiple projects and users

8

Layout for multiple projects and users

9

Connections

• The lab backbone offers connections to: – PSTN analog access line– The public Internet via two different ISPs– Public or private subnets internet.

• It provides wired connections to all the frames and equipment in the lab.

• It includes a Network Management System, Open NMS.

Lab Backbone

VoIITESInet1 UCCS

VVoWVVoWi

To ISP1

To ISP2

10

11

Mode of Work

• Lab projects are classified into eight broad programs

• Work continues in these programs throughout the year

• Students work on semester-long projects within the programs

• Industry partners work with lab staff to develop statements of work and provide personnel and material resources as needed

12

Lab Programs

• The Current Lab Programs:– NG911- Emergency Services IP network (ESInet)– Performance – Real-Time Media– Real-Time Security– UCCS - Unified Communications Commercial Systems– Voice over IIT– VVoW - Voice and Video over Web– VVoWi - Voice and Video over Wireless

• Descriptions of these projects is available at a private Google site. Access to this site is available on request.

13

14

Lab Programs

• Three of these programs are:

– NG911 / ESInet

– SIP Performance Benchmarking Tool

– Web Conferencing service using WebRTC

15

Emergency Services

• The Emergency Services Program studies the functional elements, architectures, protocols and underlying networks carrying emergency services over IP infrastructure. Goals include:

• Characterize the performance of these networks under various conditions 

• Develop Failover methods for these networks

• Provide test services to standards bodies, integrators, vendors and implementers.

16

Current work

National Emergency Number Association (NENA) ICE-5:

•The lab is preparing to host NENA's ICE-5, a testing event focused on emergency services for individuals who are deaf, deaf-blind, hard of hearing or have a speech disability. 

•See the description of this Industry Collaboration Event at the NENA site http://www.nena.org/?page=NG911_ICE

17

Current work

Assure911 and the Counties of Southern Illinois:

•Recently the lab performed testing for Assure911, a consultancy working for the Counties of Southern Illinois (CSI).

•A description of the Assure911 work is available at http://rtc-lab.itm.iit.edu/events_pages/events_recent.php#ng911

18

ESInet Testbeds

•Three Emergency Services IP networks (ESInets) are currently available in the lab•Some key functional elements of the ESInets are implementations developed at Columbia University. These are: SIPc, the LoST servers, SIPd, the ESRP, PSAPd and the Call Takers •The media server, BCF, LNG, LPG, dispatch mapping software and LIS are donated by vendors including Dialogic, ACME Packet, RedSky, and Bullberry.

19

Logical Architecture

20

21

22

Failover Solutions

•Several failover solutions for the Functional Elements of the test beds have been developed. Two of them protect against loss of connectivity at layer 3 and below. •One uses looping pings to verify continuity, combined with a simple script that swaps IP addresses between a failed system and its backup. •Another uses UCARP, an implementation of the Common Address Redundancy Protocol (CARP).•We are developing a layer 5 failover function (L5FF) as well and currently plan to use an "OPTIONS ping" for this.

23

Failover Solution

•The first failover solution attempted was derived from the paper, “Failover and Load Sharing in SIP Telephony” by Kundan Singh and Henning Schulzrinne, Computer Science Department at Columbia University. It involves IP address takeover. •This solution it is not dependent on the application layer and is also transparent to it. The process used is illustrated below.

24

Virtual ESInet

•The 'Virtual ESInet' is a functional model of the ESInet using existing Columbia University ESInet components within a single virtual machine. •This non-production environment can be used as: 1) a platform for feature development, related project work, and testing; 2) a teaching tool.

25

SIP Performance

•The project addresses the need for a vendor-neutral benchmarking methodology to allow different SIP servers to be meaningfully compared one with the other. •The goal of this program is to develop such benchmarks and to design systems to collect the benchmarks we define.  •Students have built several versions of a test tool that collects the benchmarks and that is built in accordance with the terminology and methodology described in two IETF drafts currently in WGLC. 

26

SIP Performance

• Current versions of the benchmarking methodology and terminology documents are available at http://tools.ietf.org/html/draft-ietf-bmwg-sip-bench-meth-04 and http://tools.ietf.org/html/draft-ietf-bmwg-sip-bench-term-04.  

Testbed used to benchmark SIP session throughput. The DUT is an Asterisk server in this illustration.

27

SIP Performance

• This project has been implemented by three successive student teams. Below is a sample of comparative results of the first and second teams.

28

Voice and Video over Web (VVoW)

• The Voice and Video over Web Program studies systems that use the World-Wide-Web to support real-time streaming media applications. 

• Students developed a web conference system in 2011 that enabled up to 6 participants in an ad-hoc audio/video conference that used Flash to implement the video.

• In 2012, with the availability of the Canary browser and Google's WebRTC API the students revised the code, eliminating Flash and adding features to the GUI.

• The new VVoW-2012 project basically enhances the interface and changes from the currently flash based approach to HTML5 and RTC web functionality.

• The project can be tested at http://gardo1.rice.iit.edu/webconf/.

29

VVoW

• The WebConference architecture illustrated below shows the use of the Real Time Media Flow Protocol (RTMFP) over UDP for the media and shows the option to use the WebRTC method or Flash.

• The application is available at http://gardo1.rice.iit.edu/webconf/ .

30

VVoW

• The students compared the resource consumption of the the WebRTC implementation with the previous Flash implementation and that of Skype.

• As shown in the table, WebRTC performance is quite different from that of Flash. The WebRTC implementation's performance more closely resembles that of Skype. The average packet size is around 500 B and the video quality is higher than Flash.

Metrics: the amount of traffic in KB measured from the time the application was opened until the time it received a response; the performance over a 20 second interval after two-way communication is established, measured in KG, packets and packet size.

31

VVoW

• Message flow showing the establishment of a browser to browser session.

32

Next Steps

• Access to project materials:– Create a database for the projects with role-dependent access

permissions.– Create a code repository for the ongoing projects and share

versioned code with partner organizations. • Test and measurement:

– Host additional test events such as the NENA ICE.– Publish results of SIP Performance test and find commercial

servers to test. • Corporate relations:

– Develop a Corporate Sponsors program that provides year-round funds in exchange for various in-kind services including tutorials, on-site internships, testing and development.

– Expand our Internship program and develop other programs that provide funds to support students working on projects.

33

Web Sites

• RTC Lab: http://rtc-lab.itm.iit.edu/• RTC Conference and Expo: http://www.rtc-conference.com/• IIT SAT: http://www.iit.edu/cpd/• Projects Web Site: https://sites.google.com/a/iit.edu/real-time-

communications-lab/