XML phone directory populated from MySQL

ciscodotcom1 · ‎12-03-2014

I have created a php script that can be placed on a web server and called from a SPA handset and will return a CiscoIPPhoneDirectory XML object.

My particular use case was to access the phonebook that the Flash Operator Panel 2 (FOP2) that is often installed on Asterisk based systems.

Simply rename the attachment to <something>.php and put it on your webserver. Adjust as required and reference it on your phone eg by populating these elements in the phone config or by typing them into the phone's web interface:

<XML_Directory_Service_Name group="Phone/XML_Service">Company Directory</XML_Directory_Service_Name>
<XML_Directory_Service_URL group="Phone/XML_Service">http://webserver.example.co.uk/CiscoIPPhoneDirectory.php</XML_Directory_Service_URL>

Hope someone finds this handy.

Cheers

Jon

ciscodotcom1 · ‎12-05-2014

Here's an updated version that supports the next button so that an unlimited number of entries can be sent one page of entries at a time, when it gets to the end it will start at the beginning again.

I've also ported it to PDO from mysql.

Cheers

Jon

Dan Lukes · ‎12-05-2014

Some Cisco docs claim a max of 32 entries but I have tested this on a
SPA303 and found 100 may be the limit for firmware 7.5.6a.
If you send too many entries you will probably get an error on the phone.

You may got error with more than 32 entries. Also further unpredictable behavior of the phone has been observer because of it (it seems that an internal memory has been overwritten). Don't exceed documented maximum unless you are wishing to live on the edge.

ciscodotcom1 · ‎12-05-2014

I set the script to 20 entries anyway - that seemed a usable number to scroll through.

We have 250 odd entries and at 20 per page you don't have to "next" too many times if you overshoot the entry you are looking for.

For users with say up to 100 entries in total, 10 or 15 would be a good number.

Jon

Dan Lukes · ‎12-05-2014

32 entries per page seems to be safe. So I see no benefit from 10-15 entries per page only.

ciscodotcom1 · ‎12-07-2014

Now you've got me started! 8)

Note the entries are sorted.

For a given number of entries in a directory we need to find the optimal number of key presses required to find a particular entry. Here optimal is the least number of key presses.

Let k = number of key presses, n = number of entries in a directory, x = number of entries returned in one page, p = number of pages, which is (n/x)

The number of key presses required is approximated by (p/2 + x/2). That is - on average - half the number of pages and then half the number of entries in a page.

So for example if n = 100 and x = 32:

(~= means "roughly equals" and => means "the above implies")

=> k = (100/32)/2 + 32/2 ~= 1.5 + 16 = 17.5

Now let x = 10:

=> k ~= (100/10)/2 + 10/2 = 5 + 5 = 10

What about x = 15:

=> k ~= (100/15)/2 + 15/2 = 3.3 + 7.5 ~= 10.8

So, for 100 entries in the directory it will generally require a lot less keypresses to find an entry if you restrict the number returned in a given page to 10-15.

Ok, so this is pretty simplified and is complicated by the fact that we don't have a back button available. However if we allow an extra keypress for the user to check whether the current page contains their entry by pressing up to find the last entry and see if they are on the right page, then 10 entries is per page still the best value for 100 entries in the directory as a whole.

I could write the above logic into the script to set an optimal number of entries per page for a given directory size but that is probably going a little far!

Cheers

Jon

Dan Lukes · ‎12-13-2014

I assume you slowed down, in the meantime ;-)

I will start with formal bug. You missed that you can reach last record on the page using one key - the "up" key. So, in the ideal world, you can reach a particular record in x/4 not x/2. The same you should implement for paging, so p/4 will become more appropriate than p/2.

I'm not disputing your conclusion now, just the constants you selected.

My main critics is related to the fact that you missed some important facts. Your optimization is based on the fact that number of record on the page should be same as number of pages. You can save keystrokes for rather very small lists. You win for the address book with just 32 records. Naive implementation require 8 keypresses, "optimized" implementation require 3 keypresses. As you will add more record, the number of keypresses saved will decrease.

I can rephrase it - you can save keypresses as long as it's count is low already. As number of records, this keypresses, will increase, your's ability to save them will decrease.

For >1024 records you will be able to optimize no longer this way because of limit 32 records per page.

But it's still not the core of my critics of your conclusions.

You considered cost of any keypress to be equal. But it's not true. "up" and "down" within the same page is cheap. But PgDn/PgUp is expensive. It take the substantial amount of time. Scrolling down eight lines is easy. Move eight pages to down is tiring.

Your optimization is nice application of mathematics, but you ignored parameters that affect results substantially. It is unacceptable thus your mathematics model can't be used for the real world application.

Well. I don't wish to create reply full of critics only.

So I would like to describe different method of optimization.

You can create form that will ask user for a string. You should return the records related to user's input only then.

For example just names starting with such strings, or containing just string or so - according your local conditions.

The resulting list will fit on one page in most cases even on phone networks with few thousand users.

If you will implement address book this way, the number of key presses required is almost constant and you will save most of expensive "pagging" keystrokes.

justa · ‎09-07-2015

Hello,

Would you mind to repost updated script version? Currently clicking on it returns:

The requested URL "/sites/default/files/attachments/document/ciscoipphonedirectory_0.txt" was not found on this server.

Thank You.

Julius

ciscodotcom1 · ‎09-07-2015

(Re-uploaded)

Cheers

Jon

justa · ‎09-07-2015

Thanks for sharing!

This script saves lots of time for some of us.

Julius

Travis Ryan · ‎12-07-2015

How would one figure out how to add categories? I'd like to give the option for them to drill down one more level before showing the users. They have hundreds for each employee for vendors to contact and they want to put them into different buckets.

Or even a search on the contacts too.

Dan Lukes · ‎12-08-2015

You can ask user for anything you wish - category, name, phase of moon, of shoes ...

You can generate a list of names and numbers according your wishes and answers provided then ..

Did you read XML forms documentation ?

What issue you hit ?

Travis Ryan · ‎12-08-2015

I can't even find the coding reference that Cisco should have to help developers. I love XML and generate my own XML for the provisioning, but can't find the info for the directory or apps. I want to modify the script provided here to work in my own environment. If I can create the category list before the listing of the phone numbers, that would be great.

Dan Lukes · ‎12-08-2015

Open "Documents" tab of the area we are discussing now (e.g. XML Phone Applications).

Start with Cisco XML Services Application Development Note - Interface Specification. Don't miss other documents, like XML Services Examples.

Do not hesitate to ask in doubt (but create new thread for your particular question).