Zdenek Nejedly, Campus Services

1. IP Phone Services: Integration of Campus IT Services with IP Phones at the University of Guelph Zdenek Nejedly, Campus Services Rasim Duric, Lelio Fulgenzi, Deborah MacDougall, Networking Services Computing & Communications Services University of Guelph

2. IP Phone Services • IP Phone Services : Principles & technologies • Case studies/sample apps: challenges & solutions • J2EE framework: XML object generation, identification & authentication modules

3. VOIP deployment at UG • 2002: CCS tests • 2003: Active deployment to business and residence clients starts • 2003 Fall: development of first IP services starts • 2004 September: deployment of about 7200 units completed • More details in "VOIP at Guelph: 4 years on..." talk by Lelio and Drew

4. IP Phone Services:Principles, technologies, devices

5. IP Phone Services • Based on web technologies • XML messages sent over HTTP • Any server-side platforms (J2EE, ASP/.NET, php) • Other APIs: Java Telephony API

6. IP Phone Services Includes XML browser and a simple web server

7. IP Services Request Flow Two kinds of requests: • Client (User or Phone) initiated (pull) • User via the Directories/Services button • Phone via Idle URL settings • Server initiated (push) • requires Basic Authentication of the pushing server

8. IP Services Request Flow • Client (User or Phone) initiated (pull) 1 2 1 2

9. IP Services Request Flow 2. Server initiated (push)

10. Messages: XML Objects • All data (text to be displayed, button actions, links/URLs) packaged in Cisco pre-defined XML objects • Phone’s browser interprets the XML and displays lists, menus, soft keys • No client-side scripting

11. XML Object Examples • CiscoIPPhoneText, CiscoIPPhoneMenu, CiscoIPPhoneInput, CiscoIPPhoneDirectory, CiscoIPPhoneImage, CiscoIPPhoneExecute, CiscoIPPhoneResponse, CiscoIPPhoneError, and more… <CiscoIPPhoneText> <Title>My Directory</Title> <Text>Good bye…..</Text> <SoftKeyItem> <Name>Exit</Name> <URL>SoftKey:Exit</URL> <Position>3</Position> </SoftKeyItem> </CiscoIPPhoneText>

12. Implementation Examples:1. Campus Directory(integration with LDAP)

13. Campus Directory • Phone directory based on the campus LDAP • Client dependent search scope and presentation (staff vs. students in residences) • Packaged solution (ASP/COM) not fully extensible -> need for a custom solution • Development goals: • Extensible framework • Complete control over the LDAP interface • OS independent – suitable for mixed environment • Interoperability with other/future company applications • Solution: J2EE servlet-based framework

14. Campus Directory

15. Campus Directory • Demonstration …

16. Campus Directory – lessons learned • Scarce UI resources, e.g., Soft Keys – additional functionality makes existing features less accessible -> Requirements management and usability testing important. • The phone often fails silently and errors are difficult to debug -> Regression testing essential. • Implementation differences between firmware versions and different IP Phone models -> phone model aware applications.

17. Implementation Examples:2. My Directory(client authentication, RDBMS, cooperation with portals)

18. My Directory • User-editable directory a.k.a. speed dial • Customization & Privacy -> user authentication • Authentication via phone keypad tedious - -> minimize the login/logout frequency • Security -> do not expose the Call Manager (packaged solution is based on the web access to the CCM)

19. My Directory

20. My Directory • Demonstration of speed dial, contact management (add new, edit existing, delete)

21. Lessons learned & solutions • Persistent cookies not supported and the phone runs on DHCP -> client management on the server by MAC • Phone identification -> query the phone’s web server to get MAC or Phone Number

22. Device ID & Single Sign On

23. Phone or Browser? • Use IP Phone services where appropriate – phone is always on but provides only limited User Interface resources. • Infrequently used options waste UI resources • Use web browser for UI-intensive tasks – input facilitated via portlet designed under uPortal portlet

24. Implementation Examples:3. Push2Phone(Push technology, Device account/CCM authentication)

25. Push2Phone • Push text and audio to the IP Phones as needed • Emergency notifications, system management alerts, user support • Message delivery independent of user settings • Problem: Server pushing content to the phone must provide credentials of the user assigned to the phone – these are not known!

26. Push2phone Authorization Default model – server must know the user’s credentials Modified model – a proxy-authorization module supports global admin credentials

27. System Architecture 6 4 5 7 3 8 2 1

28. Summary:Problems & Solutions

29. Summary • Challenges: • Limited screen capabilities and controls (software and hardware) • Additional features may complicate existing options • Intensive data input – use web apps • No persistent cookies – manage the persistence on the server, e.g. by MAC address • Minimize user authentication – implement a flavour of SSO • To avoid having to manage user credentials implement authentication proxy • Troubleshooting: • difficult debugging of invalid XML • For protocol debug use for example JMeter (in place of a packet monitor) • Implementation: • J2EE servlets & JSPs, MVC for portlet • Case studies: Campus Dir, My Dir, Push2Phone • http://www.uoguelph.ca/~znejedly/oucc

30. Dream IP Phone Service • Write down a brief description of your dream IP Phone Service and submit it along with your name. • You can win a prize – popular vote or random draw.