Henning Schulzrinne, Supreeth Subramanya, Xiaotao Wu Department of Computer Science

1 / 51

Henning Schulzrinne, Supreeth Subramanya, Xiaotao Wu

Department of Computer Science

Columbia University

Date: Feb 21, 2008

Advanced 2 – Developer’s Guide to FAA VoIPAdvanced 2 – Developer’s Guide to FAA VoIP

2 / 51

Discussion FlowDiscussion Flow

The Bigger Picture A VoIP Review Classroom VoIP system Lab VoIP system Conclusion

3 / 51

Discussion FlowDiscussion Flow

The Bigger Picture VoIP review Classroom VoIP system Lab VoIP system Conclusion

FAA… what’s that? What is IRT doing there? How are the ATCs Trained?

4 / 51

The Bigger Picture (1/4)The Bigger Picture (1/4)

Federal Aviation Administration (FAA) An agency of the U.S. Department of Transportation with authority to regulate

and oversee all aspects of civil aviation in the U.S.

FAA Academy The education and training division of FAA

Provides training to all personnel of aviation community

We’re working with a group responsible for training the Air Traffic Controllers (ATC)

5 / 51

The Bigger Picture (2/4)The Bigger Picture (2/4)

ATC Training levels Low fidelity – instructional games, individual training

Medium fidelity – real time interactive training

Full fidelity – complex interactions, real hardware

Photos - http://www.cba.uri.edu/classrooms/pictures/computerlab.jpg & http://www.lockheedmartin.com/data/assets/10307.jpg

6 / 51

The Bigger Picture (3/4)The Bigger Picture (3/4)

FAA Academy Communication System

Three parallel networks in every classroom and lab

Data Network (Fast or Gigabit Ethernet)

Voice Network (Analog, hardwired point-to-point connections)

Video Network (Graphical simulations)

Disadvantages Difficult to add new training scenarios

Uses obsolete equipments, no longer available without custom manufacture

Solution – convergence of Data and Voice networks Digital vs. analog

Better utilization of bandwidth

Reconfigurability in connections

I’m in

Hardware-based

Software-based

7 / 51

The Bigger Picture (4/4)The Bigger Picture (4/4)

What are the ATCs trained on? Learning to use air traffic control devices & displays Communicating and coordinating with Pilots / ATCs Many more aspects

Learning the air traffic rules Developing a mental picture of

air-space and air-timing

Why should we care? We are designing the communication system We’ll have to use air traffic control devices and displays for input/output

Photo - http://www.aeroport.public.lu/pictures/en/administration/atc/atc_003.jpg

8 / 51

Discussion FlowDiscussion Flow

The Bigger Picture VoIP review Classroom VoIP System Lab VoIP System Conclusion

VoIP – Protocol Perspective The World of SIP

9 / 51

VoIP ReviewVoIP Review

What protocols are needed? Signaling – protocols to establish presence, locate users, set up, modify and tear

down sessions

Media Transport – protocols for transmission of packetized audio/video

Support – protocols for Gateway Location, QoS, inter-domain AAA*, address translation, NAT traversal, resolution of phone numbers etc.

What protocols are there? Signaling: SIP, RTSP (IETF), H.323 (ITU-T) Media transport: RTP Transport: UDP, TCP Supporting protocols: DNS, RSVP, ICE, ENUM

* AAA = Authentication, Authorization, Accounting* AAA = Authentication, Authorization, Accounting

http://www.ietf.orghttp://www.ietf.org/rfc/rfcxxxx.txt

10 / 51

PROTOCOL ZOOPROTOCOL ZOO

VoIP ReviewVoIP Review

11 / 51

Find me then call meFind me then call me

VoIP Review (SIP)VoIP Review (SIP)

Registrar

Proxy

Hey, this is Tony,I am in cs.columbia.edu domainI am at 128.59.19.251

I want to talk to Tony

Where is Tony?He is at 128.59.19.251

Invite Tony for a conversation

12 / 51

SIP REQUESTSSIP REQUESTS

Request purpose Code

Establish a session with offer/answer

INVITE

Acknowledge a response to an INVITE

ACK

Query the capabilities of a server/UA

OPTIONS

Cancel a pending request CANCEL

Terminate an existing SIP session

BYE

Temporarily bind a device URI REGISTER

Request purpose Code

Establish a session to receive future information updates

SUBSCRIBE

Deliver information after SUBSCRIBE

NOTIFY

Upload status information to server PUBLISH

Request another UA to act upon a URI

REFER

Transport an instant message MESSAGE

Update session state information UPDATE

Basic: Extended:

VoIP Review (SIP)VoIP Review (SIP)

13 / 51

Class Code Examples

Informational 1xx 100 Trying180 Ringing

Success 2xx 200 OK

Redirection 3xx 301 Moved Permanently305 Use Proxy

Client Error 4xx 401 Unauthorized404 Not Found

Server Error 5xx 503 Service Unavailable

Global Failure 6xx 600 Busy Everywhere606 Not Acceptable

Borrowed from HTTP xyz explanatory text Uses x80 and higher codes to

avoid conflicts with future HTTP response codes

SIP RESPONSESSIP RESPONSES

VoIP Review (SIP)VoIP Review (SIP)

14 / 51

SIP CALL FLOWSIP CALL FLOW

A@domain1.com B@domain2.com

INVITEINVITE

INVITE

180 RINGING

200 OK

100 TRYING100 TRYING

180 RINGING180 RINGING

200 OK200 OK

200 OK

ACK

BYE

MEDIA SESSION

proxy.domain1.com server.domain2.com

VoIP ReviewVoIP Review

15 / 51

Services/Features/FunctionsServices/Features/Functions

VoIP ReviewVoIP Review

SIP CGI, CPL, SIP Servlet

16 / 51

SIP CGISIP CGI

VoIP ReviewVoIP Review

• Similar to HTTP CGI, an interface for service programming on SIP servers

• Invoke a service application as another process• Expose SIP messages (method, headers, and content) through

environment variables and stdin to the service application• The application then generate user wanted responses to stdout,

pipe to SIP server

server process

env(REQUEST_METHOD) = INVITEenv(REQUEST_URI) = sip:iids@domain.com……

application

invoke puts …

INVITE output from the application

Media transmissionMedia transmission

VoIP ReviewVoIP Review

Please send audio to 192.168.1.101 port 10000using RTP with G.711 codec20 ms packetization period

Ok, got it, Please send audio to 192.168.1.102 port 20000using RTP with G.711 codec20 ms packetization period

Ok, acknowledged

INVITE with SDP

200 Ok with SDP

ACK

RTP with packetized audio data

18 / 51

Discussion FlowDiscussion Flow

The Bigger Picture A VoIP Primer Classroom VoIP system Lab VoIP system Conclusion

Communication Requirements Translation to SIP domain Bundling things together

19 / 51

The Classroom VoIP System (1/12)The Classroom VoIP System (1/12)

Overview Consists of up to 26 Students (ATC, Pilot) and 1 instructor Students and instructor use computer and push-to-talk (PTT) device Instructor loads a flight scenario and teaches/tests the students

Single SectorScenario

20 / 51

The Classroom VoIP System (1/12)The Classroom VoIP System (1/12)

Overview Consists of up to 26 Students (ATC, Pilot) and 1 instructor Students and instructor use computer and push-to-talk (PTT) device Instructor loads a flight scenario and teaches/tests the students

Dual SectorScenario

21 / 51

The Classroom VoIP System (2/12)The Classroom VoIP System (2/12)

Four Communication scenarios ATC communicates with the pilots in his sector (radio broadcast) ATC communicates with neighboring ATCs during pilot handoff (point-to-point) Instructor may monitor students (i.e. listen to what they hear/talk) Instructor may record the training sessions

SIP perspective Signaling – Student UA, Instructor UA and SIP proxy Voice communication – RTP stack, Audio/speech codec library System information – Database (MySQL)

One ATC may talk to many entities simultaneously

A conference call

a conference server,full-mesh conferencemulticastcascaded conferenceapplication layer multicast

We use multicastWe use multicast

Inside firewall and behind a NAT Server performance and scalability Easy implementation

22 / 51

23 / 51

The Classroom VoIP System (3/12)The Classroom VoIP System (3/12)

1. Radio (or Frequency) Communication, similar to multicast Communication amongst ATC and all the pilots in his sector Multicast The flight scenario loaded by the instructor defines the communication rules

SIP perspective Every radio channel is given a permanent SIP address (sip:freq_120@faa.gov) There’s no destination for a radio call – the caller needs to join a multicast session Generation and management of multicast address

Problem: each exercise uses the same SIP URI for a radio channel, they should not talk to each other

Multicast Address Provider UA (MAP UA) – providing multicast addresses for different exercises

Define the rules for allowing a student to participate in a radio channel communication Configurations and roles defined in database (by the Instructor)

Call routing logic: routed to MAP UA, or the other party in the exercise? SIP-CGI

24 / 51

The Classroom VoIP System (4/12)The Classroom VoIP System (4/12)

RadioCommunicationDesign

25 / 51

The Classroom VoIP System (5/12)The Classroom VoIP System (5/12)

2. Landline (or Facility) Communication Directed communication between ATC-ATC or Pilot-ATC Unicast Not really unicast (if the instructor wants to monitor this conversation)

SIP perspective Every landline channel is given a permanent SIP address (sip:fac_aactwr@faa.gov) Call destination dependents on the caller and the called landline

If (caller == Pilot) then (destination = ATC) If (caller == ATC & channel 1) then (destination = the first pilot who picks the call) If (caller == ATC & channel 2) then (destination = neighboring ATC)

Generation and management of multicast address Communication rules Configurations/roles defined in the Database Logic for processing the communication request SIP-CGI

26 / 51

The Classroom VoIP System (6/12)The Classroom VoIP System (6/12)

Landline Communication Design

27 / 51

The Classroom VoIP System (7/12)The Classroom VoIP System (7/12)

3. Instructor Monitoring Instructor monitoring – to hear an ATC communicate during practice/test Instructor interjection – to give directions to the monitored student

SIP perspective The basic insight

We’ve setup every communication in the multicast mode So, make the instructor join all those sessions that has the selected student Keep the instructor updated about the status of the student

Ideal case for SIP Subscribe/Notify mechanism The SIP flow

Instructor UA sends a SUBSCRIBE request to Student UA Student UA sends NOTIFY with multicast addresses of all the sessions that it is part of Student UA sends NOTIFY to Instructor UA, whenever a session is added/removed Instructor accordingly joins/unjoins the corresponding multicast group

28 / 51

The Classroom VoIP System (8/12)The Classroom VoIP System (8/12)

4. Classroom Recording Record all the voice communications pertaining to an exercise (i.e. flight scenario) Ability to record more than one exercise simultaneously Options to start, stop and pause the recording anytime during the training Ability to select and replay the recorded streams later

SIP perspective Real time control of record and playback RTSP Setup and updation of student communication status SIP Subscribe/Notify Storage and retrieval of recorded files Fileserver Playback of recorded streams Archive Player

29 / 51

The Classroom VoIP System (9/12)The Classroom VoIP System (9/12)

Classroom Recording - SIP/RTSP Design

Instructor / RTSP Client

5) SETUP (multicast address)

7) RECORD (multicast address)

6) 200 OK

8) 200 OK

9) TEARDOWN (multicast address)

10) 200 OK

FileSystem

RTSP Server

Mix streams and store

ATC 2

ATC 1

ATC n

1) SUBSCRIBE

3) NOTIFY with multicast addresses

2) 200 OK

4) 200 OK

30 / 51

The Classroom VoIP System (10/12)The Classroom VoIP System (10/12)

User Interfaces and I/O Devices

Student UI Buttons for each radio and landline channels Audio visual cues to describe the state – Unselected, Selected, Active or Ringing Dynamic creation of the UI based on a configuration file

Push-To-Talk (PTT) A USB device with a headphone, a microphone and a binary switch Used as a selector for the voice transmission channel

Reception on radio and landline can be simultaneous, but transmission is mutually exclusive

SIGNAL System UI

VoIP System UI

31 / 51

The Classroom VoIP System (11/12)The Classroom VoIP System (11/12)User Interfaces and I/O Devices

Instructor UI Create configurations/rules and load/unload exercises Monitor students and record/replay voice communications Visual representation of the classroom

VoIP System UISIGNAL System UI

32 / 51

The Classroom VoIP System (12/12)The Classroom VoIP System (12/12)

Implementation and Packaging Client applications, MAP UA, and SIP CGI implementation are in Tcl/Tk server implementation and RTP and audio/speech library is in C++ Student, instructor machines are Windows and VoIP server is Linux

Freewrap - to package all the Tcl/Tk files into a single windows executable Installshield - to put the executables, configuration files Linux RPM - sipd, rtspd, sip-cgi, mapua, MySQL

Demonstration

Use-cases Instructor loads configuration and students start radio communication Student simultaneously starts a landline communication Instructor monitors a student, also does a status query

33 / 51

Discussion FlowDiscussion Flow

The Bigger Picture A VoIP Primer Classroom VoIP system Lab VoIP system Conclusion

Classroom vs. Lab Communication/Hardware Requirements Translation to SIP domain

34 / 51

The Lab VoIP System (1/7)The Lab VoIP System (1/7)

How does it translate for us? Lots of I/O processing and UI design Separate user agents for ATC, Pilot, Position Instructor More SIP flows

Classroom vs. Lab Simulation of what goes on in the real world (of ATCs)

I/O devices and interfaces are many in number, and are quite complex

There are two types of instructors Master Instructor, responsible for the whole class Position Instructor, responsible for one student

All the students are no longer identical ATCs and Pilots use different devices/interfaces and are seated in different rooms

Communication mechanisms exist between every two entities in the lab (well, almost!)

35 / 51

The Lab VoIP System (2/7)The Lab VoIP System (2/7)

Communication scenarios Four communication scenarios of the classroom VoIP system Generate notification, if there’s a transmission on an unselected radio channel Complex landline and Inter-position communication scenarios Few others (made trivial by the extensible design of the classroom system)

Separation of Transmission and Reception on radio channels Simultaneous monitoring of more than one student by the instructor

User Interfaces and I/O Devices Four rich graphical interfaces

Pilots, ATCs, Position Instructors Master Instructor (upgrade over the existing instructor UI)

Five I/O devices Push -To -Talk, Touch-screens, Foot-pedals, Headsets, Speakers

36 / 51

The Lab VoIP System (3/7)The Lab VoIP System (3/7)

User Interfaces

1. Unified, configurable GUI for ATC and Position Instructors

37 / 51

The Lab VoIP System (4/7)The Lab VoIP System (4/7)

User Interfaces

2. Configurable shared GUI for Pilots

38 / 51

The Lab VoIP System (5/7)The Lab VoIP System (5/7)

Transmission on an Unselected Radio Channel ATC needs a visual cue, if someone is transmitting on an unselected channel

SIP perspective Need a mechanism to –

Collect information about transmissions on every radio channel Manage a list of students, who need to be informed for every channel Send out notifications to everyone in the list for a given channel

Ideal for SIP Subscribe-Publish-Notify mechanism Central management subscribe, publish and notify Presence server Modifications in all the UA/UIs to coordinate with the presence server

39 / 51

The Lab VoIP System (6/7)The Lab VoIP System (6/7)

Informing TransmissionsOn Unselected Channels

Presence Server

ATC 2

ATC 1

ATC 3

1) SUBSCRIBE radio1

2) UNSUBSCRIBE radio1

3) PUBLISH radio1

1) SUBSCRIBE radio1

4) NOTIFY radio1

1) SUBSCRIBE radio14) NOTIFY radio1

40 / 51

The Lab VoIP System (7/7)The Lab VoIP System (7/7)

Landline and Inter-position communications Landline communication channels could be

Ring lines: caller dials, phone rings, callee picks up bidirectional media exchange Shout lines: caller dials transmits the media, callee picks up bidirectional media exchange Override lines: caller dials bidirectional media exchange

Need for Inter-position communications Not all the trainers and trainees are in the same room; Labs have very limited lighting

SIP perspective All these are to be covered during instructor monitoring and recording Multicast Logic for processing the calls SIP-CGI, Call handling at UA/UI Generation and management of multicast address MAP UA Communication rules Configurations/roles defined in the Database

41 / 51

Discussion FlowDiscussion Flow

The Bigger Picture A VoIP Primer Classroom VoIP system Lab VoIP system Conclusion

42 / 51

Conclusion (1/1)Conclusion (1/1)

Progress so far Classroom VoIP is operational in 5 training rooms Lab VoIP prototype deployed by June ‘07

Key learning Map real-world communication scenarios to SIP/RTP/RTSP flows Put together SIP components, leading to a VoIP architecture Importance of an extensible design with well-defined interfaces

VoIP system migration from classrooms to the labs

Need for robust error/warning handling

Thank you!

Let’s do itLet’s do it

What should I do? Where are the files? Which part of the file? How? Cross your fingers, oops, … k, dne, …

43 / 51

What should I doWhat should I do

Configuration or logic Client side or server side

address assignment, call routing – server appearance, user interactions – client

GUI, control, or database new buttons, different layout, … perform different functions need to access persistent data

44 / 51

Where are the filesWhere are the files Server side

sipcgi.tcl – SIP CGI implementation mapua.tcl – providing multicast addresses

Client side look into *.wrap file GUI

student_ui.tcl instrui_*.tcl archieve_player.tcl

Logic sipua.tcl instructorua.tcl rtspc.tcl

Database iids_dbconnect.tcl

45 / 51

Which part of the fileWhich part of the file

check the API doc of the file identify the procedure or add a new procedure GUI

create widget, bind it to an event-handling function, implement the function

Control find the function for request/response handling, modify the

logic Database

find the db function, and use ‘sql’ command

46 / 51

How?How?

Learn from the existing code e.g., put image create in one place

Separate GUI code from control code create, bind, pack, callback

little trick: tkwait visibility AppDebug::perror use of array, list, “…”, {…}

coding convension

47 / 51

48 / 51

No usable IDE for Tcl Use AppDebug::perror and check

*debug*.txt files Use tk_messageBox –type ok –

message “…” Tk’s error dialog box separate your new

code, use tclshand wish to run it

Enable lower level debug E.g., in student_ui.tcl sip.dbg file

Monitor window

49 / 51

Debug::init .set Debug::enableDebug 1Gui_Monitor::initGui_Monitor::main

# Load database

Tue Feb 19 4:11:39 PM Eastern Standard Time 2008Local::init: os is Windows

Tue Feb 19 4:11:39 PM Eastern Standard Time 2008a_wintcpip: 135.8.6.136,gateway 135.8.6.1 135.148.233.92,gateway {} 135.8.6.136,domain usae.avaya.com 135.8.6.136,nameserver 135.8.19.100 135.148.233.92,domain {} 135.148.233.92,nameserver {}

kk

check in your code, put check in notes

50 / 51

51 / 51