zdenek nejedly, campus services
Post on 14-Jan-2016
47 Views
Preview:
DESCRIPTION
TRANSCRIPT
Zdenek Nejedly, Zdenek Nejedly, Campus ServicesCampus ServicesRasim Duric, Lelio Fulgenzi, Deborah MacDougall, Rasim Duric, Lelio Fulgenzi, Deborah MacDougall, Networking Networking
ServicesServices
Computing & Communications ServicesComputing & Communications ServicesUniversity of GuelphUniversity 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
Web /Application server
Cisco Call Manager
IP phone user
IP ServicesHTTP request&
response
Call facilitation, Configuration,
Authentication, etc.
External services, e.g., LDAP, DBMS, Web service providers
Global device info, etc
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
Client(IP Phone)
Server(Web server)
HTTP Request for service listing (URL configured on the phone)
HTTP Response, e.g., with CiscoIPPhoneDirectory XML object
Request to the specific-dynamically generated URL
Response with the actual data
User presses the Directory button
User selects a specific service
External serviceLDAP, DBMS,...
1
2
1
2
IP Services Request Flow
2. Server initiated (push)
Client(IP Phone)
Server(Web server)
Is user authorized?
Authenticationserver
HTTP Post request with CiscoIPPhoneExecute
and Basic Authentication data
(Un)Authorized
Request to the pushed URL
Response with the actual (pushed) data
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
J2EE Application server
Cisco Call Manager
IP phone user
Search request
over HTTP
Configuration
LDAP Request
Private network – public network boundary
Private VOIP network
Campus Network
LDAP server
Campus Directory
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
Database server
Application server hosting the messaging & management application
Portal server hosting the management portlet
Cisco Call Manager
AdministrationWeb interface
IP phone user
IP phone user
Authentication & content
Configuration
Admin
Private network – public network boundary
Private VOIP network
Internet
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 OnClient(IP Phone)
Server(Web server)
1st HTTP Request
GET request for /DeviceInformationXResponse: MAC, Phone #,..
Returns user login formPOSTs the user credentials
Returns requested page
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
2nd HTTP RequestReturns requested page
HTTP Request in a different session
GET request for /DeviceInformationXResponse: 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 uPortalportlet
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 AuthorizationClient(IP Phone)
Server(Web server)
Is user authorized?
Authenticationserver
HTTP Post request with CiscoIPPhoneExecute
and Basic Authentication data
(Un)Authorized
Request to the pushed URL
Response with the actual (pushed) data
Default model – server must know the user’s credentials
Modified model – a proxy-authorization module supports global admin credentials
Client(IP Phone)
Server(Web server)
Is authorized?
AuthenticationServer (CCM)
Push request
(Un)Authorized
Request to the pushed URL
Response with the actual (pushed) data
ProxyAuthentication
authorized?(Un)Authorized
Proxy scans the authorization request for admin credentials
and if found then it will authorize the request
System Architecture
Message Queue (RDBMS)
Cisco Call Manager
IP phone user
Administrator
authorization
Configuration
Queue polling
Push requests
Private network – public network boundary
Private VOIP network
Campus network
Proxy-authorization
authorization
Application server & queue monitoring agent
response
PushExecute
1
2
3
4 5
7
8
6
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– 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.
top related