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• 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

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.