Transcript FAA Presentation - Columbia University

Advanced 2 – Developer’s Guide to FAA VoIP
Henning Schulzrinne, Supreeth Subramanya, Xiaotao Wu
Department of Computer Science
Columbia University
Date: Feb 21, 2008
1 / 51
Discussion Flow

The Bigger Picture

A VoIP Review

Classroom VoIP system

Lab VoIP system

Conclusion
2 / 51
Discussion 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?
3 / 51
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)
4 / 51
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
5 / 51
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)
Hardware-based
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
Software-based
6 / 51
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
7 / 51
Discussion Flow

The Bigger Picture

VoIP review

Classroom VoIP System

Lab VoIP System

Conclusion

VoIP – Protocol Perspective

The World of SIP
8 / 51
VoIP 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
http://www.ietf.org
http://www.ietf.org/rfc/rfcxxxx.txt
* AAA = Authentication, Authorization, Accounting
9 / 51
VoIP Review
PROTOCOL ZOO
10 / 51
VoIP Review (SIP)
Find me then call me
Registrar
Hey, this is Tony,
I am in cs.columbia.edu domain
I am at 128.59.19.251
Where is Tony?
He is at 128.59.19.251
Invite Tony for
a conversation
I want to talk to Tony
Proxy
11 / 51
VoIP Review (SIP)
SIP REQUESTS
Basic:
Extended:
Request purpose
Code
Request purpose
Code
Establish a session with
offer/answer
INVITE
Establish a session to receive future
information updates
SUBSCRIBE
Acknowledge a response to an
INVITE
ACK
Deliver information after
SUBSCRIBE
NOTIFY
Query the capabilities of a
server/UA
OPTIONS
Upload status information to server
PUBLISH
Cancel a pending request
CANCEL
Request another UA to act upon a
URI
REFER
Terminate an existing SIP
session
BYE
Transport an instant message
MESSAGE
Temporarily bind a device URI
REGISTER
Update session state information
UPDATE
12 / 51
VoIP Review (SIP)
SIP RESPONSES

Borrowed from HTTP

xyz explanatory text

Uses x80 and higher codes to
avoid conflicts with future HTTP
response codes
Class
Code
Examples
Informational
1xx
100 Trying
180 Ringing
Success
2xx
200 OK
Redirection
3xx
301 Moved Permanently
305 Use Proxy
Client Error
4xx
401 Unauthorized
404 Not Found
Server Error
5xx
503 Service Unavailable
Global Failure
6xx
600 Busy Everywhere
606 Not Acceptable
13 / 51
VoIP Review
SIP CALL FLOW
proxy.domain1.com
server.domain2.com
[email protected]
[email protected]
INVITE
100 TRYING
180 RINGING
INVITE
INVITE
100 TRYING
180 RINGING
180 RINGING
200 OK
200 OK
200 OK
ACK
MEDIA SESSION
BYE
200 OK
14 / 51
VoIP Review
Services/Features/Functions
SIP CGI, CPL, SIP Servlet
15 / 51
VoIP Review
SIP CGI
•
•
•
•
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
output from
the application
INVITE
server
process
env(REQUEST_METHOD) = INVITE
env(REQUEST_URI) = sip:[email protected]
……
invoke
puts …
application
16 / 51
VoIP Review
Media transmission
Please send audio to
192.168.1.101 port 10000
using RTP with G.711 codec
20 ms packetization period
INVITE with SDP
Ok, acknowledged
Ok, got it,
Please send audio to
192.168.1.102 port 20000
using RTP with G.711 codec
20 ms packetization period
200 Ok with SDP
ACK
RTP with packetized audio data
Discussion Flow

The Bigger Picture

A VoIP Primer

Classroom VoIP system

Lab VoIP system

Conclusion

Communication Requirements

Translation to SIP domain

Bundling things together
18 / 51
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 Sector
Scenario
19 / 51
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 Sector
Scenario
20 / 51
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
One ATC may talk to many entities simultaneously
SIP perspective

Signaling – Student UA, Instructor UA and SIP proxy

Voice communication – RTP stack, Audio/speech codec library

System information – Database (MySQL)
A conference call
a conference server,
full-mesh conference
multicast
cascaded conference
application layer multicast
21 / 51
We use multicast



Inside firewall and behind a NAT
Server performance and scalability
Easy implementation
22 / 51
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:[email protected])

There’s no destination for a radio call – the caller needs to join a multicast session

Generation and management of multicast address



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


Problem: each exercise uses the same SIP URI for a radio channel,
they should not talk to each other
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
23 / 51
The Classroom VoIP System (4/12)
Radio
Communication
Design
24 / 51
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:[email protected])

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
25 / 51
The Classroom VoIP System (6/12)
Landline Communication Design
26 / 51
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
27 / 51
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
28 / 51
The Classroom VoIP System (9/12)
Classroom Recording - SIP/RTSP Design
ATC 1
5) SETUP (multicast
address)
RTSP Server
6) 200 OK
7) RECORD
(multicast address)
8) 200 OK
Mix
streams
and store
9) TEARDOWN
(multicast address)
Instructor /
RTSP Client
1) SUBSCRIBE
ATC 2
2) 200 OK
3) NOTIFY with
multicast addresses
4) 200 OK
10) 200 OK
ATC n
File
System
29 / 51
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
SIGNAL
System UI
VoIP System UI
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
30 / 51
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
SIGNAL System UI
VoIP System UI
31 / 51
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
32 / 51
Discussion Flow

The Bigger Picture

A VoIP Primer

Classroom VoIP system

Lab VoIP system

Conclusion

Classroom vs. Lab

Communication/Hardware Requirements

Translation to SIP domain
33 / 51
The Lab VoIP System (1/7)
Classroom vs. Lab

Simulation of what goes on in the real world (of ATCs)



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


I/O devices and interfaces are many in number, and are quite complex
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!)
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
34 / 51
The Lab VoIP System (2/7)
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
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
35 / 51
The Lab VoIP System (3/7)
User Interfaces
1. Unified, configurable GUI for ATC and Position Instructors
36 / 51
The Lab VoIP System (4/7)
User Interfaces
2. Configurable shared GUI for Pilots
37 / 51
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
38 / 51
The Lab VoIP System (6/7)
Informing Transmissions
On Unselected Channels
ATC 2
1) SUBSCRIBE radio1
Presence
Server
ATC 1
2) UNSUBSCRIBE radio1
3) PUBLISH radio1
ATC 3
39 / 51
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
40 / 51
Discussion Flow

The Bigger Picture

A VoIP Primer

Classroom VoIP system

Lab VoIP system

Conclusion
41 / 51
Conclusion (1/1)
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
Progress so far

Classroom VoIP is operational in 5 training rooms

Lab VoIP prototype deployed by June ‘07
Thank you!
42 / 51
Let’s do it






What should I do?
Where are the files?
Which part of the file?
How?
Cross your fingers, oops, …
k, dne, …
43 / 51
What 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 files

Server side



sipcgi.tcl – SIP CGI implementation
mapua.tcl – providing multicast addresses
Client side

look into *.wrap file

GUI




Logic




student_ui.tcl
instrui_*.tcl
archieve_player.tcl
sipua.tcl
instructorua.tcl
rtspc.tcl
Database

iids_dbconnect.tcl
45 / 51
Which part of the file



check the API doc of the file
identify the procedure or add a new procedure
GUI


Control


create widget, bind it to an event-handling function,
implement the function
find the function for request/response handling, modify the
logic
Database

find the db function, and use ‘sql’ command
46 / 51
How?

Learn from the existing code



Separate GUI code from control code
create, bind, pack, callback




e.g., put image create in one place
little trick: tkwait visibility
AppDebug::perror
use of array, list, “…”, {…}
coding convension
47 / 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 tclsh
and wish to run it
48 / 51
Debug::init .
set Debug::enableDebug 1
Gui_Monitor::init
Gui_Monitor::main

Enable lower level debug


# Load database
E.g., in student_ui.tcl
sip.dbg file
Tue Feb 19 4:11:39 PM Eastern Standard Time 2008
Local::init: os is Windows
Tue Feb 19 4:11:39 PM Eastern Standard Time 2008
a_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 {}

Monitor window
49 / 51
k

check in your code, put check in notes
50 / 51
51 / 51