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

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

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

IP Phone Services: Principles, technologies, devices

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

Includes XML browser and a simple web server

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

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

2. Server initiated (push)

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

XML Object Examples CiscoIPPhoneText, CiscoIPPhoneMenu, CiscoIPPhoneInput, CiscoIPPhoneDirectory, CiscoIPPhoneImage, CiscoIPPhoneExecute, CiscoIPPhoneResponse, CiscoIPPhoneError, and more… My Directory Good bye….. Exit SoftKey:Exit 3

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

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

Campus Directory

Demonstration …

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.

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

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)

My Directory

Demonstration of speed dial, contact management (add new, edit existing, delete)

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

Device ID & Single Sign On

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

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

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!

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

System Architecture

Summary: Problems & Solutions

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 –

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.