CCNException: deviceDataPassThrough request failed

[davidblair]

com.cisco.jtapi.PlatformExceptionImpl: CCNException not handled:com.cisco.cti.client.CCNException: deviceDataPassThrough request failed

Look familiar? I posted awhile ago about receiving this error when I send an RTPRx:Stop command to a 7912 on CCM 4.0 using the CiscoTerminal.sendData() command in JTAPI.

We've since upgraded to CCM4.1 and I get the same error. Most recently I've tested on a 7905 under CCM4.1...same error.

However if you use the same command under an HTTP push to the phone it works fine...in my old thread Stephan admits it works on his 7905s and I've had success with it on 12s, 40/60s and 70s.

It seems if you're building an app based on sending multicast or unicast streams and you need to support all phone types you'll have to use http push instead of jtapi.

What else have I learned that I can share...since you'll be using HTTP which requires authentication against Call Manager's authenticate.asp you'll have to offload authentication to a different server. In Kelly Stearns documentation for push authentication he states: "For large-scale applications, PUSHing to hundreds or thousands of devices, this [authenticating against Call Manager] can cause performance problems"

That's an understatement! We tried 80 phones. We discovered a race condition occurs in the UMX.UMDefaultProviderX ActiveX Object that locks up the IIS server on Call Manager.

I quit. What can I say...I'm jaded. I'm not the world's greatest programmer, but I'm not a novice either. I'm getting tired of writing apps on top of buggy APIs and then being yelled at for my apps not working. It's my fault for not testing on every phone type under different CCMs / phone loads / infrastructure conditions before Sales sells one of my apps to a customer...but my company just doesn't have the resources required to be a true app shop. However, I feel it's Cisco's fault for documenting that their APIs can do things that they really can't.

I've since pushed my company into forming partnerships with companies such as Syn-Apps and Netelligent...let them worry about Cisco's buggy systems and take the heat if something doesn't work as advertised.

I might post on this board in the future as a hobbyist with some info / bug information for you guys, but I'm not going to try and develop commercial apps anymore...the underlying system and API are just too unstable.

[stephan.steiner]

David: I feel your pain. In fact, starting yesterday, I have been runnning headfirst into the same exception wall. In my case, it's sending CiscoIPPhoneStatus and various CiscoIPPhoneExecute to 7970s and IP Communicators. Today, I managed to try my 7960s and my 7905 and it worked out like a charm (except for the small detail problem that the 7905 doesn't support CiscoIPPhoneStatus objects).

Personally I do not think that for large scale pushing is an option, but those JTAPI passthrough problems really have me worried to.

I find myself asking time and again, what can we do to get Cisco to listen? AXL is extremely messed up. Phones act different to different XML data with almost each new phone load. Apps perform completely different depending on the phone type. The JTAPI implementation is incomplete (and JTAPI 1.2 is pretty darned outdated). When first getting into touch with the Cisco world from a programmer's perspective, I thought, wow, the possibilities (especially since I work for a shop that mostly sells Alcatel.. and the Alcatel API situation, when I started, was extremely bad, but they're now slowly catching up). Now I find myself doubling development hours to account for whatever snafus await me because an API doesn't act like described. Cisco relies heavily on third party apps to complete what they call their ecosystem, but I'm getting the feeling that's mostly a one way street.

I'm waiting for the day when finally the VP in charge of APIs checks in here, and then does something. When I think about the non telephony world (also part of my job and my hobby), APIs tend to be a lot more stable and reliable.

You know what the worst is, this behavior is completely non deterministic. Last week I wrote a personal directory lookup application. It pushes data upon incoming calls. It used to work like a charm. Now that I have a second application also connected via JTAPI, suddenly no push to the 7970 and IP Communicator seems to be working anymore.. and there were no software upgrades since then.. I guess I'll boot my two boxes over the week-end and see where I'm at after the week-end, and pray that since things work out on the 7960's (the platform the customer of these apps uses), it will work out on-site.

[stephan.steiner]

Hmmm.. do I only get one edit? I started getting the same exception even with my dear old 7960s when I added a new feature to my app: to send data upon a terminal going into service. Then I added a 5 second delay between event and sending the data, and it once again worked. The little things that keep eating into your time...

[aaronw.ca]

I have to agree. The variance in how various phone models and/or firmware loads handle XML & XML Push makes it difficult to develop with, let alone support (not to mention AXL, JTAPI, etc).

It can also be discouraging to new developers who, when coming to this forum with a question, are told that we don't know why their app is behaving that way but to try different phone loads in hopes that the bug will go away. Error 6, device busy, etc.

It's only going to get worse in CallManager version 5.0, where we don't have access to the file system to learn and understand what is going on behind the scenes when we attempt to troubleshoot a problem ourselves (only to an IOS-like CLI shell on the console). This lack of access to the internals of the machine is very unfortunate, and makes us more dependant on Cisco to provide stable, documented APIs that work. Lack of access to the SQL database means that executeSQLQuery AXL calls won't be as useful unless the configuration database is well documented. Of course, we should be using AXL for this anyway, but it's still a valid point, imo.

This also makes it more difficult to do things like adding extra device support to devicelistx or modifying directory search behaviours, since we can't just modify the xmldirectory.asp any longer, but have to totally redirect the directory url and create it from scratch. While I can understand why Cisco might not want people doing this, the fact that we're doing it in the first place indicates a lack of functionality in the product itself which forces users to implement the functionality themselves. This only makes it more difficult to do so in extending the product.

I understand the benefits of the network appliance model, but it is disappointing from a developer perspective. (I'm glad they switched to linux, though - I prefer it over windows; I just wish we had access inside!).

I really enjoy developing on Cisco platforms as their products often offer features and APIs unavailable from other vendors, and access to documentation is not inhibited by multiple layers of NDAs and contracts that are unavailable to mere mortals (like some other vendors). This open access to information and SDKs open their products to innovation and development, which is one of the key benefits of convergence (will someone tell the other vendors this?). If they could provide thorough, correct documentation and most importantly make the products behave in a predictable, consistant, stable fashion across product and firmware versions, it would be a dream come true! :)

[stephan.steiner]

Turns out a reboot of both callmanagers did the trick.. for now.

The question remains though, we're all aware of the benefits and drawbacks of the Cisco APIs. We'd all like to work with a more reliable and stable platform where we can really focus on our own bugs and don't have to worry about another layer that behaves unexpectedly and is often the cause why an application does not work as expected. So, how can we make our voice heard so that Cisco will put more manpower behind their APIs and finally creates a stable platform where we can develop on? It cannot be that half of our support time is eaten up by looking into bugs that have nothing to do with our own applications, and spend considerable development time to find workarounds and quirks in the APIs.

Speaking of other vendors, my employer sells 90% Alcatel lines, and we actually to make a direct contact with the product management of the XML APIs, and they gave us a chance to make our case for new features.. and now the next version will include major parts of the functionality we were missing (they didn't have a real addPhone and deletePhone for instance). That's the kind of support that makes developers happy. And as far as NDAs go, Alcatel's APIs are also available for anyone, so at least one vendor has catched up.