Download Campus Services - University of Guelph

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
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
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
IP Phone Services
Includes XML browser and
a simple web server
Call facilitation,
Configuration,
Authentication, etc.
Cisco Call
Manager
Global device info, etc
IP Services
HTTP request&
response
IP phone user
Web /
Application server
External services,
e.g., LDAP, DBMS,
Web service providers
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
IP Services Request Flow
1. Client (User or Phone) initiated (pull)
User presses the
Directory button
Client
Server
(IP Phone)
(Web server)
HTTP Request for service listing
(URL configured on the phone)
1
HTTP Response, e.g., with
CiscoIPPhoneDirectory XML object
User selects a
specific service
2
Request to the specificdynamically generated URL
Response with the actual data
1
2
External service
LDAP, DBMS,...
IP Services Request Flow
2. Server initiated (push)
Client
(IP Phone)
Authentication
server
HTTP Post request
with CiscoIPPhoneExecute
and Basic Authentication data
Is user authorized?
(Un)Authorized
Request to the pushed URL
Response with the actual (pushed) data
Server
(Web server)
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…
<CiscoIPPhoneText>
<Title>My Directory</Title>
<Text>Good bye…..</Text>
<SoftKeyItem>
<Name>Exit</Name>
<URL>SoftKey:Exit</URL>
<Position>3</Position>
</SoftKeyItem>
</CiscoIPPhoneText>
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
Private VOIP network
Cisco Call Manager
Configuration
Search
request
over HTTP
J2EE Application server
IP phone user
Private network – public network boundary
LDAP Request
Campus Network
LDAP server
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
Private VOIP network
Cisco Call
Manager
Configuration
Authentication &
content
Application server
hosting the messaging &
management application
IP phone user
Private network – public network boundary
Internet
Database server
Admin
IP phone user
Administration
Web interface
Portal server
hosting the management portlet
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
Client
Server
(IP Phone)
(Web server)
1st HTTP Request
GET request for /DeviceInformationX
Response: MAC, Phone #,..
Returns user login form
POSTs the user credentials
Ask for device
identification if no user
object found in the
session (1st request)
Ask for user
authentication if the
device not found
among authenticated
phones
Returns requested page
2nd HTTP Request
Returns requested page
HTTP Request in a different session
GET request for /DeviceInformationX
Response: MAC, Phone #,..
Returns requested page
Same session – no
device ID or user
authentication required
Different session/
service – device ID
required but not the
user authentication
(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
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
Client
(IP Phone)
Authentication
server
Server
Default model – server
must know
the user’s credentials
(Web server)
HTTP Post request
with CiscoIPPhoneExecute
and Basic Authentication data
Is user authorized?
(Un)Authorized
Request to the pushed URL
Response with the actual (pushed) data
Modified model –
a proxy-authorization
module supports global
admin credentials
Proxy scans the
authorization request
for admin credentials
and if found then it will
authorize the request
Client
Proxy
(IP Phone)
Authentication
Authentication
Server (CCM)
Push request
Is authorized?
authorized?
(Un)Authorized
(Un)Authorized
Request to the pushed URL
Response with the actual (pushed) data
Server
(Web server)
System Architecture
Private VOIP network
Cisco Call
Manager
6
Configuration
authorization
4
5
authorization
response
7
IP phone user
Push
Execute
Proxy-authorization
3
Application server
& queue monitoring
agent
8
Queue polling
Private network – public network boundary
2
Campus
network
Push
requests
1
Administrator
Message Queue
(RDBMS)
Summary:
Problems & Solutions
• Challenges:
Summary
– 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
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.