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

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

Strange problem with IP Phone web client

This is a bug in the Allegro Webclient, as best I can tell, but a workaround would be great if somebody has one.

I'm attempting to configure an email parameter for a phone server on the callmanager. For whatever reason, passing an email redirects the web request to the domain in the email address, not the actual URL given in the services config.

For example, if my service URL is:

http://192.168.1.1/IPPhone/service.asp

and I configure a parameter called email and assign it a value of foo@bar.com, the will request whatever is at http://bar.com and display the HTML.

The '@' character appears to be the problem, as if I just enter 'bar.com' as the value of the parameter the requests goes through to the configured URL correctly.

This is with Callmanager 3.3(3).

Any suggestions?

4 REPLIES
Silver

Re: Strange problem with IP Phone web client

Have you tried using Server.UrlEncode("foo@bar.com") before passing the param?

New Member

Re: Strange problem with IP Phone web client

I suppose I should clarify a little. I can make this work from a developer's perspective fairly easily. There's no reason an escape character can't be used, since this is just for passing an initial parameter to the application when its called from the services menu.

What bothers me, and maybe this should be reported as a bug rather than posted here, is that I won't be able to simply tell the users to subscribe to the service and enter their email address when they subscribe.

I can guarantee this is going to cause issues down the road, as this application is being rolled out to a customer, not internally, and I'm not looking forward to the customer complaining about having to enter foo%40bar.com when they subscribe instead of an unescaped email address, particularly since the @ character is not required to be escaped in a standard URL in any other web client.

Silver

Re: Strange problem with IP Phone web client

Thats an interesting situation.

Browsing to the services menu given to the phone (ie http://callmanager/CCMCIP/getservicesmenu.asp?name=SEP003000A000F0 replace the SEP... string with the device name) shows that the entire URL including the parameter is passed properly, so as you have noted, it must be the Allegro web client itself causing the issue.

Actually, the @ character does have special meaning in an URL when using authentication. That may be why the Allegro web client is having trouble with it.

Browsers handle it a bit differently, though if I recall correctly at one time it was possible to make you think you were visiting one website when you were actually visiting another (ie www.cnn.com@www.therealsite.com')">http://www.cnn.com@www.therealsite.com The first site would be treated as a authentication to the actual site. This was probably fixed for security reasons. I may be wrong though :)

EDIT: the Cisco forum software seems to be having trouble with that sample URL as well..

The URL RFC can be found at http://www.w3.org/Addressing/rfc1738.txt.

That being said, the problem remains unsolved. I would think that it is up to Cisco to properly encode the URLs when sending the service list to the phone (just as we would when developing our own services). The alternative is to have Allegro change their client code, and I would think that the former would be changed more quickly than the latter.

The only "workaround" I could think of would be to break the email address into two parts (username and host/mailserver name) and have your code put them back together. Not very nice, but perhaps better than the %40 alternative.

Thanks for bringing this up, and good luck with it!

New Member

Re: Strange problem with IP Phone web client

That pretty much sums up my conclusions as well.

I went ahead and opened a TAC case on this, although I suspect they'll tell me the same thing. I'd like to at least get confirmation from Cisco that they know its an issue.

If anybody runs into this in the future and happens to read this forum though, breaking the email into two parts appears to be the cleanest workaround from a user interface perspective.

118
Views
0
Helpful
4
Replies