I really struggled with the deployment of MIDlets to the phone. What should have been simple, became convoluted because I did not change a mime type on the web server. As a result I emailed back and forth with my Cisco team to finally get it all worked out.
At first I developed my MIDlet on the emulator and tried to deploy it. When I ran into problems I was not sure if the errors were from the MIDlet or the environment, so I stepped back and tried to deploy a Cisco sample MIDlet. As a result I am going to walk through deploying the Cisco supplied DeviceSpecifics MIDlet. This is because you know it will work correctly on a 7926G so any errors or problems are of your own creation.
Phone Trace Settings
First you have to enable access to the phone from it’s web server. IN CUCM select the phone from the phone list and under “Product Specific Configuration Layout” set “Web Access” to “Full” and “Phone Book Web Access” to “Allow Admin.” You login will be username admin and password Cisco.
Next let’s set up the phone to log to your favorite logging server. Bring up your phone in a browser and choose Trace Settings. I set the “Java Module Trace Level” to “Debug” and checked the box to “Enable Remote Syslog.”
Web Server Setttings
Page 37 of the Developers Guide explains how to set up different web servers. I am using Apache on RHEL 5.6, so I made change to /etc/mime.types. When I first added the stanza to the file I did not notice that there was a second definition for “jar” and it wreaked havoc on my trouble shooting for days.
Add the following and be sure to comment out or removed the second definition.
text/vnd.sun.j2me.app-descriptor jad application/java-archive jar #application/x-java-archive jar
If you do not remove that definition you will get an error similar to the one below in the logs from the phone if you set the logging up right. I did not have the logging set to a high enough setting to catch these errors.
May 2 12:39:12 172.22.16.10 SEP-java: *********************Installer - xmlVendor = Cisco Systems, Inc. May 2 12:39:12 172.22.16.10 SEP-java: Installer - info.suiteVendor = Cisco Systems, Inc. May 2 12:39:12 172.22.16.10 SEP-java: 1. Vendor Name are equal May 2 12:39:12 172.22.16.10 SEP-java: Installer - info.suiteVersion = 0.0.1 May 2 12:39:12 172.22.16.10 SEP-java: TEST - Installer - checkPreviousVersion - there is no previous version - RETURN May 2 12:39:12 172.22.16.10 SEP-java: Installer step:2 May 2 12:39:12 172.22.16.10 SEP-java: Installer step:3 May 2 12:39:12 172.22.16.10 SEP-java: Installer step:4 May 2 12:39:12 172.22.16.10 SEP-java: Installer step:5 May 2 12:39:12 172.22.16.10 SEP-java: microedition.profiles is Native System Property May 2 12:39:12 172.22.16.10 SEP-java: microedition.configuration is Native System Property May 2 12:39:13 172.22.16.10 SEP-java: MIDletProxyList:setForegroundMIDlet() May 2 12:39:13 172.22.16.10 SEP-java: MIDletProxyList:setForegroundMIDlet() May 2 12:39:13 172.22.16.10 SEP-java: MIDletProxyList:setForegroundMIDlet() May 2 12:39:13 172.22.16.10 SEP-java: REPORT: <level:3> <channel:1000> ** Error installing suite (38): JAR did not have the correct media type, it had application/x-java-archive
And even though it does not like the JAR file it goes ahead and adds it to the MIDlet list, as seen from below. That is the reason I thought it was being installed, because you see it in the list on the phone, and see it access the .jar on the web server.
May 2 12:39:21 172.22.16.10 SEP-java: Provisioning=0 May 2 12:39:21 172.22.16.10 SEP-java: dump_svc_cfg: name[0]:Missed Calls May 2 12:39:21 172.22.16.10 SEP-java: dump_svc_cfg: name[1]:Voicemail May 2 12:39:21 172.22.16.10 SEP-java: dump_svc_cfg: name[2]:Received Calls May 2 12:39:21 172.22.16.10 SEP-java: dump_svc_cfg: name[3]:Placed Calls May 2 12:39:21 172.22.16.10 SEP-java: dump_svc_cfg: name[4]:Personal Directory May 2 12:39:21 172.22.16.10 SEP-java: dump_svc_cfg: name[5]:Corporate Directory May 2 12:39:21 172.22.16.10 SEP-java: dump_svc_cfg: name[6]:DeviceSpecifics
And from the web server.
172.22.16.10 - - [02/May/2012:12:43:14 -0500] "GET /7926G/DeviceSpecifics/DeviceSpecifics.jad HTTP/1.1" 200 279 "-" "Profile/MIDP-2.0 Configuration/CLDC-1.1" 172.22.16.10 - - [02/May/2012:12:43:16 -0500] "GET /7926G/DeviceSpecifics/DeviceSpecifics.jar HTTP/1.1" 200 6326 "-" "Profile/MIDP-2.0 Configuration/CLDC-1.1"
.JAD File
Page 32 of the Developer’s Guide walks you through setting up a .jad for distribution. It will be located in the “dist” directory of the DeviceSpecifics NetBeans project. According to the Cisco documentation this is how the .jad file matches up to the IP Phone Service Coniguration found under
Device
–> Device Settings
—–> Phone Services
Service Name and MIDlet-Name must match exactly, including case and white space.
Service Version must match MIDlet-Version, or it can be left blank. If left empty the phone will attempt to download the JAD file every time it registers with CUCM as well as every time the MIDlet launches. If there is a version number, it will only download if the version number changes.
Service Type is set to Standard IP Phone Service.
Service Category is set to Java MIDlet.
Service URL is the URL where the .jad file is hosted.
ASCII Service Name and Service Description do not impact whether a MIDlet will run on a phone.
# cat DeviceSpecifics.jad MIDlet-1: DeviceSpecifics,,com.cisco.sdk.specifics.PlatformMIDlet MIDlet-Jar-Size: 6326 MIDlet-Jar-URL: DeviceSpecifics.jar MIDlet-Name: DeviceSpecifics MIDlet-Vendor: Cisco Systems, Inc. MIDlet-Version: 0.0.1 MicroEdition-Configuration: CLDC-1.1 MicroEdition-Profile: MIDP-2.0
Install MIDlet
Finally we tell the phone to download the MIDlet. From the upper right of the Phone Configuration page, choose:
Related Links
–> Subscribe Unsubscribe Services
—–> Go
You should now have the DeviceSpecifics MIDlet installed on your 7925 or 7926 IP phone.