I am working on creating an application that will submit data to an existing web page based on a couple criteria. One is the primary extension of the phone that initiates the request and the other is which of two softkeys the user presses. I can get the softkey part based on assigning different URLs to the different keys, but I can't figure out how to "read" the primary extension from the phone.
Alternately, if it is possible to get "other" phone information from the phone as it reads the page the first time (like the device name) I can use that info to query the CallManager SQL server and get the info.
Unfortunately, while the phone appends its devicename (ie SEP...) as a parameter when it requests its list of services from the CallManager (e.g. "http://callmanager/CCMCIP/getservicesmenu.asp") it does not send this devicename when it requests one of these services. Instead, it uses the parameter list specified when the service was defined.
One option would be to "browse" to the IP address (get the client address from the header) and read the device name (and main DN, etc) from the content returned by the phones internal web server. (You can see this content by typing a phones ip address in a web browser.) Not exactly the best solution, but an option.
A second possible workaround is documented in the "Developing Cisco IP Phone Services: A Cisco AVVID Solution" book. Again, this book is available online at http://safari.oreilly.com/.
This workaround basically entails hijacking the subscription url so that when the user requests a list of subscribed services it calls your service list, which includes your services (which append the device name) and a link back to the "official" CallManager services list. This isn't exactly a perfect solution either.
This may change for future releases, and there might be some other ideas out there to resolve this.
An additional possibility is the #DEVICENAME# queryparameter. This is noted in the Installation Notes for the 3.3(3) IPPS SDK. It is an easy way to get the device name to your services without all the hassle noted above. You still need the DN, but every little bit helps.
To use this, when defining the URL for your service, add the string ?name=#DEVICENAME# to the end of the URL. This will cause CM to add your devicename as a parameter when calling your service. It works for 3.2(2c), I'm not sure about earlier releases.
One further possibility that you might want to consider would be to use the DeviceListX report (available on CM 3.2(3b) and 3.3(3)+. You could crossreference the IP address from the HTTP header with the IP address from the DeviceListX report to find the device name.
Note that you would likely want to cache the information returned by DeviceListX, as it is not meant to be called many times. While you're at it, you could cache the DN info there too, perhaps, to save repeated lookups to the DB/LDAP for the DN. This would also reduce the load on the CM.
You would still have to crossreference the device name found with the database to get a list of extensions for that device, unless the primary extension was available for some reason in the device description field. Or you could find the devicename in the LDAP directory to find the primary DN listed there.
For more information on DeviceListX see the IPPS SDK 3.3(3).
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...
If you have 2 ISR routers, one acting as Failover, do we need to have both the same number of SRST licenses on the 2 routers?
No. You will only need the SRST licenses on the primary router. Because this feature...