1. 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 VoIP

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

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

4. 4 / 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)

5. 5 / 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

6. 6 / 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) 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. 7 / 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

8. 8 / 51 Discussion Flow The Bigger Picture VoIP review Classroom VoIP System Lab VoIP System Conclusion VoIP – Protocol Perspective The World of SIP

9. 9 / 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 * AAA = Authentication, Authorization, Accounting http://www.ietf.org http://www.ietf.org/rfc/rfcxxxx.txt

10. 10 / 51 PROTOCOL ZOO VoIP Review

11. 11 / 51 Find me then call me VoIP Review (SIP) Registrar Proxy Hey, this is Tony, I am in cs.columbia.edu domain I 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. 12 / 51 SIP REQUESTS Request purposeCode 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 requestCANCEL Terminate an existing SIP session BYE Temporarily bind a device URIREGISTER Request purposeCode Establish a session to receive future information updates SUBSCRIBE Deliver information after SUBSCRIBE NOTIFY Upload status information to serverPUBLISH Request another UA to act upon a URI REFER Transport an instant messageMESSAGE Update session state informationUPDATE Basic:Extended: VoIP Review (SIP)

13. 13 / 51 ClassCodeExamples Informational1xx100 Trying 180 Ringing Success2xx200 OK Redirection3xx301 Moved Permanently 305 Use Proxy Client Error4xx401 Unauthorized 404 Not Found Server Error5xx503 Service Unavailable Global Failure6xx600 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 RESPONSES VoIP Review (SIP)

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

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

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

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

18. 18 / 51 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. 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 Single Sector Scenario

20. 20 / 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

21. 21 / 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 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 conference multicast cascaded conference application layer multicast

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

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

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

27. 27 / 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

28. 28 / 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

29. 29 / 51 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 File System 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. 30 / 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 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. 31 / 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 VoIP System UI SIGNAL System UI

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

33. 33 / 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

34. 34 / 51 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. 35 / 51 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. 36 / 51 The Lab VoIP System (3/7) User Interfaces 1. Unified, configurable GUI for ATC and Position Instructors

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

38. 38 / 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

39. 39 / 51 The Lab VoIP System (6/7) Informing Transmissions On 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 radio1 4) NOTIFY radio1

40. 40 / 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

41. 41 / 51 Discussion Flow The Bigger Picture A VoIP Primer Classroom VoIP system Lab VoIP system Conclusion

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

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, … 43 / 51

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 44 / 51

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 45 / 51

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 46 / 51

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 47 / 51

48. 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 tclsh and wish to run it

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

51. 51 / 51