Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Bug in firmware

Phone type: 7941, 7961, 7970

Firmware tested:TERM41.7-0-3-0S, SCCP41.8-0-2SR1S, TERM61.DEFAULT, TERM70.7-0-1-0S

CallManager tested: 4.1, 4.2

The issue is related with "<CiscoIPPhoneInput>" XML tag. This tag has a sub tag <URL> which seems to be causing problems with above mentioned firmware, and we have confirmed it with Ethereal.

Here is the XML page sent to the phone:


<Title>PhoneTop Login</Title>

<Prompt>Enter user ID and PIN</Prompt>



<DisplayName>User ID</DisplayName>












When the URL is like this:

This is what the IP phone actually requests from the web server (as confirmed by Ethereal). Note how the query strings are inserted in the middle of the URL instead of the end.

The above URL is not correct. It should append the query sting parameters to the end the URL, like this (as all other firmwares do)

We have tested out other firmware, and they are working correctly. Most of the old firmware of 7940/60/70 are working fine. However, some of the new 7970 (7.x series loads) firmware also have the same problem.

Has anyone else run into this? Any comments/advise?



Re: Bug in firmware

I know this sounds sarcastic but unfortunately it's the truth: welcome to xml development. It's not uncommon for different loads to act differently. So basically what I do is stick to the programming guide (except for the request headers which are not reliable) and if something doesn't work, try a different load and open a case.

The QueryStringParam is a feature that has proven to be quite problematic in the past (see my other thread from a few days ago). The documentation says the QueryStringParam should be appended, but there are no examples that would confirm this. But if one phone acts different than the others, it's definitely time for a case.

I'm a bit puzzled by your url though.. how can a http get to an xml page work as an application? And why does the order of the querystrings matter? In most programming languages, you have a means to get any query string parameter regardless of the order in which they are given.

New Member

Re: Bug in firmware

I agree with you that phone loads behave slightly different. We have, at times, resolved problems by upgrading or downgrading the phone load, even when we are using simple XML object (no JTAPI/AXL stuff).

I am using a web server that acts differently based on the first parameter in the query sting. For example, http://someURL?Open will do one thing, but http://someURL?close will do another. The first parameter is what is looks for. The order after the first one does not matter. We are able to use http by adding xml content header in the http response. This has worked well for the past many years.

I have opened a TAC, but I got a response back that this is a developer support issue. That means, I now I have buy $5K/year subscription to resolve this issue which I believe is a bug in the firmware.


Re: Bug in firmware

>That means, I now I have buy $5K/year subscription to resolve this issue which I believe is a bug in the firmware.

Join me in singing the "that's not right" song. It has happened to me many times - depending on which TAC engineer you get. You can try to push your luck by providing easy reproducability and traces upfront, make references to the appropriate documentation.. basically everything to support your thesis that it's a phone bug. It still very much depends on what engineer it gets to, but not all are so stubborn. In the end, if you can open TAC cases and are a Cisco partner, cases that prove to be a waste of their time will negatively influence your company's performance which means lower rebates so in the end your company loses anyway and you have sufficient motivation to only open cases when needed.

I'm still waiting to have the subscription approved.. somehow the last two approvals got lost somewhere in the process.. a third is pending. But what I don't get at all is that each case is $500 and there's not a single word about a refund in case your case turned out to be a bug on Cisco's side.. I mean.. pay $500 bucks to be allowed to tell Cisco about a bug in their product? Give me a break. I can understand why they ask for money in case it turns out I'm wasting their time or need them to support me in what it supposed to be my job, but as soon as a bug is opened, you should get the money back.

What kind of webserver are you using? All the languages I've used, be it Javascript (ASP), Perl, PHP, ASP.NET (C#) and Java - they all don't care about the order of query strings. I'd be very surprised if the HTTP RFC said something about querystrings having to be in some particular order and the order having to be consistent in between calls. I recall sometimes writing querystring urls in rather random order (depending on which variables I use first I add them to the base url again and so forth). That may not look terribly consistent but it really matters neither to the webserver nor to the programming language.

New Member

Re: Bug in firmware

We mostly use Tomcat but in this particular case we are using IBM Lotus Domino. It uses URL like this:


(i.e )

The URLCommand (i.e "Search" in the example above) is the first thing after ? and query strings are to be added after the URL Command. The order of query parameters does not matter.

A bug in some firmware changes the URL like this:

http://ip_address/resource?QueryStrings... &URLCommand

even though, we are hard coding the URL in the URL tag like this

The problem is most firmwares are working fine, but a few (7941/61 firmwares and the 7.x for 7970) are behaving inconsistently.


New Member

Re: Bug in firmware

Have you guys come up with a solution to this yet? I'm having the same problem with the 7961 when using my modification of the intercom.asp that I've enabled two-way intercom.

I basically send http requests to other phones with certain parameters in the querystring that tell it which functions to perform.

Works on all phones just fine, except that when you dial from a 7961 to any other phone model other than our 7940's, it cannot display the page. But it will display the page just fine when you dial a 7940 phone.

CreatePlease login to create content