RE: Phone service - HTTP Connection failed error on 8941 phones http://developer.cisco.com/c/message_boards/find_recent_posts?p_l_id= 2013-05-26T03:37:59Z 2013-05-26T03:37:59Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15110099 2013-05-09T17:59:51Z 2013-05-09T17:59:51Z

Re-attached to the wiki, should be working now...hope it helps!

David Staudt 2013-05-09T17:59:51Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=14566192 2013-04-23T15:33:53Z 2013-04-23T15:33:53Z

The DX650 does not support any IP Phone Services XML APIs - applications can use the general design patterns (and far greater functionality) provided by Android itself to deliver custom services on the device.

David Staudt 2013-04-23T15:33:53Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=14012953 2013-04-08T21:01:16Z 2013-04-08T21:01:16Z

I believe this is a limitation of the 7940/60 devices.  As these devices have long since been End of Life'ed, you will need to explore workarounds, e.g. adding a service URL parameter to specify the device name, and populating it per device.

David Staudt 2013-04-08T21:01:16Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12953407 2013-03-13T05:54:44Z 2013-03-13T05:54:44Z

Yep, so your script will need to handle this possibility, i.e. parameter being missing results in the same script action as if parameter is missing but null/empty

David Staudt 2013-03-13T05:54:44Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12751689 2013-03-07T15:43:21Z 2013-03-07T15:43:21Z

Can you grab a network packet capture (e.g. via Wireshark) of the traffic and inspect the actual HTTP header? 

David Staudt 2013-03-07T15:43:21Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12717810 2013-03-06T21:40:09Z 2013-03-06T21:40:09Z

A known issue with some phone models requires that the URL in the Refresh header be specified, e.g.: Refresh: 0;url=http://page.to.refresh/to

David Staudt 2013-03-06T21:40:09Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12484417 2013-02-28T17:28:40Z 2013-02-28T17:28:40Z

Generally an application would use CiscoIPPhoneExecute to push down a URL to another screen a URI like 'App:Close' or 'Init:Services' to clear the app.  Note, the CiscoIPPhoneStatus object can only be cleared by the app (or a phone reset), so if the object is displayed and the app 'goes away', users are stuck. It is the general guidance to avoid CiscoIPPhoneStatus, but in certain cases it is still very useful...

David Staudt 2013-02-28T17:28:40Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12438978 2013-02-27T16:03:42Z 2013-02-27T16:03:42Z

The behaviour is phone/firmware specific and not configurable.  Just a guess as to whether this is the actual problem.  We can perhaps gain some more insight by comparing a network packet capture of a working vs non-working phone - and of course identifying the nature of the failure in the application script (on IIS?) would be the primary troubleshooting avenue.

David Staudt 2013-02-27T16:03:42Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12395686 2013-02-26T16:00:47Z 2013-02-26T16:00:47Z

Some models handle un-specified input values differently.  For example, with a input fields 'requiredValue' and 'optionalValue', if the user submits the screen without putting anything into the optional field, the phone may request either: GET /myService?requiredValue=something&optionalValue= or GET /myService?requiredValue=something This makes a difference in the server-side script, as 'if (optionalValue=="")' might work for the former, but won't for the latter (the optionalValue param was never received and is 'undefined'.)  You will want to check if optionalValue!=undefined before assuming it has any value (including empty string)

David Staudt 2013-02-26T16:00:47Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=12222226 2013-02-21T16:40:32Z 2013-02-21T16:40:32Z

Unfortunately no.  One of the overriding goals of the phone UI teams has always been to ensure the device is always perceived/usable as a phone, with apps given sub function status.  As much as it may have made sense for fullscreen apps, the concept has always been declined due to UE reasons... Options for changing app skin/appearance are not available.

David Staudt 2013-02-21T16:40:32Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11984931 2013-02-15T20:41:46Z 2013-02-15T20:41:46Z

If I understand your question correctly the answer is no, but the workaround is to use CiscoIPPhoneExecute to get the phone to make a URL request, which returns something like a CiscoIPPhoneText object with a Refresh header on it.

David Staudt 2013-02-15T20:41:46Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=11746617 2013-02-08T20:39:15Z 2013-02-08T20:39:15Z

Modern browsers prevent 'cross origin' requests like this, where the host that provided the javascript is different from the host that the XMLhttpRequest is going to. http://en.wikipedia.org/wiki/Same_origin_policy The usual recourse is to have the javascript post a custom request back to the origin web server, and have the web server make the actual post to the phone (i.e. proxy)  

David Staudt 2013-02-08T20:39:15Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=9046015 2012-12-03T20:41:31Z 2012-12-03T20:41:31Z

The LDAPSearch component is fairly limited in what it can do, and beyond what's documented that's it.  It is included in the SDK more as a working example than as a robust enterprise solution. It is quite possible to query LDAPs using today's CGI environments, with the obvious benefits being native inclusion and near infinite flexibility.  A few threads that might be helpful: [url=http://forums.aspfree.com/code-bank-54/asp-code-query-ad-ldap-169652.html]http://forums.aspfree.com/code-bank-54/asp-code-query-ad-ldap-169652.html[/url] [url=http://stackoverflow.com/questions/7946856/user-authentication-over-ldap-in-asp]http://stackoverflow.com/questions/7946856/user-authentication-over-ldap-in-asp[/url]

David Staudt 2012-12-03T20:41:31Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=8863998 2012-11-27T20:24:32Z 2012-11-27T20:24:32Z

Not aware of any comprehensive list, unfortunately.  If you have a question about a particular parameter we can probably research it...

David Staudt 2012-11-27T20:24:32Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=8402824 2012-11-07T20:42:54Z 2012-11-07T20:42:54Z

A network packet capture (via Wireshark) is usually the best way to inspect the actual authentication request and response for issues (make sure and capture from a PC connected to the phone's extra PC switch port.)  Feel free to attach the pcap here.

David Staudt 2012-11-07T20:42:54Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=8402391 2012-11-07T20:08:05Z 2012-11-07T20:08:05Z

The IP Phone Services XML interface capabilities are more dependent on the phone model/firmware than the UCM version, but the answer is generally: yes. You should be able to consider the latest available guide/SDK as applicable to the current UCM release, if and until a newer doc/SDK is released.

David Staudt 2012-11-07T20:08:05Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=8369427 2012-11-06T23:54:42Z 2012-11-06T23:54:42Z

Capturing from the camera is not supported.

David Staudt 2012-11-06T23:54:42Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=8151168 2012-10-30T17:05:31Z 2012-10-30T17:05:31Z

DEVICENAME is the only macro of its kind. There is an API that can provide the logged in user by device: http://developer.cisco.com/web/emapi/home

David Staudt 2012-10-30T17:05:31Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=8130578 2012-10-29T20:50:58Z 2012-10-29T20:50:58Z

I think in general your plan should work.  See the 'Interaction with Call Streaming' section for details on how it works with normal call operation. Note also you can take advantage of the 'Idle URL' functionality, which will cause the phone to retrieve a URL (which you can then have trigger your streaming service) after a configurable idle period.

David Staudt 2012-10-29T20:50:58Z David Staudt http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=7806172 2012-10-18T16:05:48Z 2012-10-18T16:05:48Z

Probably the best way to troubleshoot will be to take a look a the HTTP XML messages being sent between phone and application.  Can you get a network packet capture - i.e. via Wireshark running on a PC connected to the phone's extra switch port?  If you don't spot any immediate issues feel free to attach here.

David Staudt 2012-10-18T16:05:48Z