1 / 51 Henning Schulzrinne, Supreeth Subramanya, Xiaotao Wu Department of Computer Science Columbia University Date: Feb 21, 2008 Advanced 2 – Developer’s

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


The Bigger Picture

VoIP review


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


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


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


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


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


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:


13 / 51

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

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

avoid conflicts with future HTTP response codes

SIP RESPONSESSIP RESPONSES


14 / 51

SIP CALL FLOWSIP CALL FLOW

[email protected] [email protected]

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


15 / 51

Services/Features/FunctionsServices/Features/Functions


SIP CGI, CPL, SIP Servlet

16 / 51

SIP CGISIP 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

server process

env(REQUEST_METHOD) = INVITEenv(REQUEST_URI) = sip:[email protected]……

application

invoke puts …

INVITE output from the application

Media transmissionMedia transmission


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


The Bigger Picture

A VoIP Primer


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 Sector

Scenario

20 / 51


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

21 / 51


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


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


Radio

Communication

Design

25 / 51


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

26 / 51


Landline Communication Design

27 / 51


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


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


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


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



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


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


The Bigger Picture

A VoIP Primer


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


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


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


User Interfaces

1. Unified, configurable GUI for ATC and Position Instructors

37 / 51


User Interfaces

2. Configurable shared GUI for Pilots

38 / 51


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


Informing Transmissions

On Unselected Channels

Presence Server

ATC 2

ATC 1

ATC 3

1) SUBSCRIBE radio1

2) UNSUBSCRIBE radio1

3) PUBLISH radio1

1) SUBSCRIBE ra

dio1

4) NOTIFY radio1

1) SUBSCRIBE radio14) NOTIFY radio1

40 / 51


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


The Bigger Picture

A VoIP Primer


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

Documents

1 / 51 Henning Schulzrinne, Supreeth Subramanya, Xiaotao Wu Department of Computer Science Columbia University Date: Feb 21, 2008 Advanced 2 – Developer’s