XML Services with Cisco Phone Proxy: Part 1 - the easy part

The ASA phone proxy is a very nice feature where a ASA acts as Skinny or SIP proxy for cisco phones. Generally i prefer the new phone vpn feature in UCM 8, there are very valid reasons to use phone proxy for remote worker phones.

Key to understand phone proxy is, that it only proxies signalling (secure signalling to be exact) and media traffic to ucm. anything else is not proxied, and this means XML services (e.g. Extension Mobility Login/Logout). So these services do not work by default.
Generally opening up those XML services to the outside world SHOULD not be an option ;-).

There is a new feature to help with this since ASA 8.2 but is very well hidden.
When looking at the ASA config guide at http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/unified_comm_phoneproxy.html, there is the proxy-server configuration command, which is described as follows:

If the operational environment has an external HTTP proxy to which the IP phones direct all HTTP request, configures a proxy server.

You can configure only one proxy server while the phone proxy is in use.

By default, the Phone URL Parameters configured under the Enterprise Parameters use an FQDN in the URLs. The parameters might need to be changed to use an IP address if the DNS lookup for the HTTP proxy does not resolve the FQDNs.

Note If the IP phones have already downloaded their configuration files after you have configured the proxy server, you must restart the IP phones so that they get the configuration file with the proxy server address in the file.

So, the command can actually be used to at least make the services on the UCM directly available WITHOUT an extra proxy.
for this, just configure the following under the phone proxy configuration

proxy-server a.b.c.d interface <inside>

where a.b.c.d is the internal IP of the communications manager and <inside> is the name of the inside interface.
For example:

phone-proxy ASA-phone-proxy
   proxy-server 192.168.214.10 interface inside

would make the services available on the UCM 192.168.214.10 directly

Et voila, this will open a dynamic pinhole for port 8080 for all registered phones to the UCM and it will allow the phones to use the services that are directly located on the UCM (even though the UCM is of course not a proxy server as such)

If you need other XML services, you need to use a external proxy. A configuration example for such a case follows during the next days.

Kerberos Authentication in Cisco Unified Videoconferencing Manager: Too large SPNEGO Token

Cisco Unified Videoconferencing Manager (CUVCM) is the current Cisco Videoconferencing Manager Product (Radvision OEM). Which means it won't be the future product since it will be replaced by Tandberg VCS and TMS I guess (this actually makes a lot of sense).
Still, there is quite an installed base of this product in the field and there will be one for quite some time in the future.  So for those who have an installation and want to replace the build in NTLMv1 SSO here is a caveat i fought with:
Basically the setup is pretty straight forward, just go according to the guide here:
www.cisco.com/en/US/docs/video/cuvcm/7_1/configuration_guide/kerberoscuvcm71.pdf

Some things to look at in detail:
->Make sure the principal matches your hostname
->Sniff traffic on the CUVCM server to make sure you are hitting the right Domain Controller


For us it still did not work initially. After search together with TAC for a long time, a Linux server admin at the customer put us on the right track for resolution:
The customer had a relatively large AD with multiple domains. Therefore the SPNEGO header used for Kerberos became comparatively large.

It turns out, Tomcat (and quite a lot of other Web Servers put a limit to the maximum size of the HTTP header that is being processed. The large SPNEGO token pushed us over that limit.

So to change that limit for the HTTP header in the Tomcat SAR (CUVCM is actually using JBOSS which is using tomcat as the embedded Servlet Container):
Open the following file:
\JBOSS_DIR\server\default\deploy\jbossweb-tomcat55.sar\server.xml 

Change the value for : maxHttpHeaderSize to something larger than the default of 8192 (8KB), e.g. 16384 or 32768

Reset CTL on Cisco Unified Personal Communicator (CUPC) 8

One of the new features of CUPC 8 (or CSF in general) is that it supports a lot of the UCM encryption and security features.
If you are hopping between different clusters (because you are an SE) you might run into troubles with this.
For example you might have connected to a secure cluster before and now your CTL (Certificate Trust List) does not match with the new cluster. Therefore CUPC Presence and chat will work but the Softphone component will not.
In this case the CTL needs to be deleted.
This can be done by delete the CTL file in the following directory:
C:\%USERPROFILE%\AppData\Cisco\Unified Communications\Client Services Framework\Security\sec\lsc0

Be aware, that the "AppData" part might be localized, e.g. "Anwendungsdaten" in German.