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

1. Advanced 2 – Developer’s Guide to FAA VoIP Henning Schulzrinne, Supreeth Subramanya, Xiaotao Wu Department of Computer Science Columbia University Date: Feb 21, 2008

2. Discussion Flow • The Bigger Picture • A VoIP Review • Classroom VoIP system • Lab VoIP system • Conclusion

3. 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?

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. 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. I’m in 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 Software-based

7. 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. Discussion Flow • The Bigger Picture • VoIP review • Classroom VoIP System • Lab VoIP System • Conclusion • VoIP – Protocol Perspective • The World of SIP

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

10. PROTOCOL ZOO VoIP Review

11. Find me then call me VoIP Review (SIP) 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

12. SIP REQUESTS VoIP Review (SIP) Basic: Extended:

13. VoIP Review (SIP) SIP RESPONSES • Borrowed from HTTP • xyz explanatory text • Uses x80 and higher codes to avoid conflicts with future HTTP response codes

14. proxy.domain1.com server.domain2.com A@domain1.com B@domain2.com INVITE INVITE INVITE 100 TRYING 100 TRYING 180 RINGING 180 RINGING 180 RINGING 200 OK 200 OK 200 OK ACK MEDIA SESSION BYE 200 OK SIP CALL FLOW VoIP Review

15. Services/Features/Functions VoIP Review SIP CGI, CPL, SIP Servlet

16. SIP CGI VoIP 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 output from the application INVITE server process env(REQUEST_METHOD) = INVITE env(REQUEST_URI) = sip:iids@domain.com …… invoke puts … application

17. Media transmission VoIP Review Please send audio to 192.168.1.101 port 10000using RTP with G.711 codec 20 ms packetization period Ok, got it, Please send audio to 192.168.1.102 port 20000using RTP with G.711 codec 20 ms packetization period INVITE with SDP 200 Ok with SDP Ok, acknowledged ACK RTP with packetized audio data

18. Discussion Flow • The Bigger Picture • A VoIP Primer • Classroom VoIP system • Lab VoIP system • Conclusion • Communication Requirements • Translation to SIP domain • Bundling things together

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

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

22. We use multicast • Inside firewall and behind a NAT • Server performance and scalability • Easy implementation

23. 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. The Classroom VoIP System (4/12) Radio Communication Design

25. 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. The Classroom VoIP System (6/12) Landline Communication Design

27. 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. 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. RTSP Server 5) SETUP (multicast address) ATC 2 ATC 1 ATC n Instructor / RTSP Client 6) 200 OK 1) SUBSCRIBE 7) RECORD (multicast address) 2) 200 OK Mix streams and store 8) 200 OK 3) NOTIFY with multicast addresses 9) TEARDOWN (multicast address) 4) 200 OK File System 10) 200 OK The Classroom VoIP System (9/12) Classroom Recording - SIP/RTSP Design

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

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

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

34. The Lab VoIP System (1/7) 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!) 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

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

36. The Lab VoIP System (3/7) User Interfaces 1. Unified, configurable GUI for ATC and Position Instructors

37. The Lab VoIP System (4/7) User Interfaces 2. Configurable shared GUI for Pilots

38. 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. 1) SUBSCRIBE radio1 ATC 1 ATC 3 ATC 2 Presence Server 1) SUBSCRIBE radio1 2) UNSUBSCRIBE radio1 4) NOTIFY radio1 3) PUBLISH radio1 1) SUBSCRIBE radio1 4) NOTIFY radio1 The Lab VoIP System (6/7) Informing Transmissions On Unselected Channels

40. 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. Discussion Flow • The Bigger Picture • A VoIP Primer • Classroom VoIP system • Lab VoIP system • Conclusion

42. 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!

43. 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, …

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

45. Where 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

46. Which 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

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

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

49. Debug::init . set Debug::enableDebug 1 Gui_Monitor::init Gui_Monitor::main # Load database • Enable lower level debug • E.g., in student_ui.tcl • sip.dbg file • Monitor window 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 {}

50. k • check in your code, put check in notes