disabling h225 CID Updates

So you have a customer who does not want to see the final transmitted number as shown in the last post.
Rather he wants to see the number that was send to the GW (e.g. in a e164 concept the one starting with a +).

Fear not, this can be done by disabling the h225 CID update during the call.
This can be set either globally:

voice service voip

no supplementary-service h225-notify cid-update 

or  on a individual dialpeer:

dial-peer voice 10

no supplementary-service h225-notify cid-update

Prefixing and number display on H323 Dial-peers for granular POTS interface selection

One of the advantages of using MGCP for GW control in UCM is that you can easily do granular routing, e.g. route out of a specific interface for calls.  With H323 and SIP the call is send to the Gateway and then the internal call routing logic (i.e. IOS dialpeers) will take over.
Let's compare the two models to make it clear what the "issue" is:
MGCP:

• In UCM a "chassis" is configured to which multiple endpoints are attached. 
• A endpoint is generally speaking a single interface (fxs, fxo, pri...)
• every single endpoint is controlled by the UCM with regard to call routing logic
• CDRs will show the specific selected endpoint

H323/SIP

• GW is a single endpoint, identified by its IP address
• There might be multiple Interfaces hidden behind that IP address
• UCM does not know wether this is a CUBE or a PSTN GW
• Dial-peer call routing logic applies on IOS GWs
• CDRs will only show the IP of the GW

So unless one does really fancy stuff with multiple IPs on the GW UCM does not actually select the POTS interface (or a SIP trunk via CUBE) to be used but rather just speaks to a "chassis"

There are 2 main problem areas with the H323/SIP approach when used in projects

• Granular Call routing
• Billing

So is there some way to get granular call control  working at least for the call control part?

The requirements for the solution should be (that's what I generally need):
1.)It should be transparent to the user, e.g. he should not see which link is being used (e.g. no prefix is visible to the user)
2.)Path selection should be controlled via the UCM configuration and not via Dial-peer routing on the GW
3.)Failover should still work properly, e.g. RouteGroup redundancy inside of the Routelist can be used.

Consider the following situation:
1x normal PRI for standard PSTN Calls
1x PRI Directlink to Mobile Provider
1x SIP Trunk via CUBE

The goal is to enable selection of indiviual call directions on the UCM (rather than on the gateway itself)

So let's take this in steps:
First we need to decouple the path selection from the actual dialed number. For this we work with, (not very surprising) prefixes.
So for each Link on a GW we decide on a prefix. As an example let's take the following example:

• Primary PSTN Link from Telco: *1
• Directlink from mobile provider: *2
• Alternative Provider via SIP Trunk *3

Now we create a dial-peer for each provider:

dial-peer voice 10 pots

 description Primary Link to Telco

 huntstop

 preference 1

 destination-pattern *10T

 progress_ind setup enable 3

 progress_ind alert enable 8

 progress_ind progress enable 8

 port 0/0/0:15

 forward-digits all

!

dial-peer voice 11 pots

description Directlink to Mobile

 huntstop

 preference 1

 destination-pattern *20T

 progress_ind setup enable 3

 progress_ind alert enable 8

 progress_ind progress enable 8

 port 0/0/1:15

 forward-digits all

dial-peer voice 2000 voip

description Link to SIP Provider

 destination-pattern *30T

 session protocol sipv2

 session target dns:proxy.siprovider.at

 voice-class sip bind control source-interface GigabitEthernet0/1

 voice-class sip bind media source-interface GigabitEthernet0/1

 dtmf-relay rtp-nte

 codec g711alaw

 huntstop

Notice 2 things:
We enabled huntstop on each link (there is actually a small caveat for this which I will explain in a future post)
The POTS Dialpeers will work out of the box (because the matched digits will be dropped), for the SIP dial-peer will not because of the extra *3, we will need a translation rule there.
But we are not finished yet.

On the UCM we will need to do the following:
1.)Create a Routegroup for each GW
2.)create Routelists depending on our routing requirements

When we create the RouteList and assign the Routegroup we do the following:
Assign the Routegroup to the Routelist, go into the details of the Routelist/Routegroup connection and set "prefix digits" to either *1, *2 or *3. This way we can now select the individual paths on the Gateway.
If we want to select the Directlink to the mobile provider, we would configure the RL - RG connection as shown on the following picture:

If we now make a test call there is one major caveat. Let's say we decide on sending everything starting with 0676 out the *2 Link.
Now the user will see the following number on the display of his phone:
*200676 XXX XXX

This of course is less than ideal because we might get some helpdesk calls from users because they are complaining about seeing something different then they have dialed.
This happends because the GW will send a display update via H323 during the call which will be displayed on the phone. Darn!
To get around this we slightly modify our configuration

voice translation-rule 5

 rule 1 /\*.0\(.*\)/ /\1/

!

voice translation-profile POTS-OUT

 translate called 5

voice translation-profile SIP-OUT

 translate called 5

dial-peer voice 10 pots

 translation-profile outgoing POTS-OUT

 description Primary Link to Telco

 huntstop

 preference 1

 destination-pattern *10T

 progress_ind setup enable 3

 progress_ind alert enable 8

 progress_ind progress enable 8

 port 0/0/0:15

 forward-digits all

!

dial-peer voice 11 pots

 translation-profile outgoing POTS-OUT

description Directlink to Mobile

 huntstop

 preference 1

 destination-pattern *20T

 progress_ind setup enable 3

 progress_ind alert enable 8

 progress_ind progress enable 8

 port 0/0/1:15

 forward-digits all

dial-peer voice 2000 voip

 translation-profile outgoing SIP-OUT

description Link to SIP Provider

 destination-pattern *30T

 session protocol sipv2

 session target dns:proxy.siprovider.at

 voice-class sip bind control source-interface GigabitEthernet0/1

 voice-class sip bind media source-interface GigabitEthernet0/1

 dtmf-relay rtp-nte

 codec g711alaw

 huntstop

On the POTS Dialpeers we enabled the command "forward-digits all". This means that digits matched by the destination-pattern will be forwarded rather than dropped.
This means we need now need to take care of the transformation of the called number via translation-rule and a translation-profile.
The rule is quite simple:

voice translation-rule 5

 rule 1 /\*.0\(.*\)/ /\1/

This will match a "*", then any digit, followed by a 0 and finally any number of digits. This will match all of our prefixes. Of course explicitly matching *10, *20 and so on would also be possible (the  0 is part of the match because it is used as the normal PSTN Access Code, e.g. in the US this would likely be *19, *29 and so on)

This rule is bound into the relevant translation-profiles (SIP-OUT and POTS-OUT) which then are applied to the relevant dialpeers.
If we drop the digits this way, the H323 display update will signal the "real" final called number (e..g 0676 XXX XXXX).
For the user this is ideal because he sees the actual, final called number.


Pretty easy, huh?

EMCC and Directory Syncronization: Be careful what you sync

One attractive new feature of UCM 8.x is Extension Mobility Cross Cluster (EMCC)
Extension mobility is the term used by Cisco for the ability to use a device profile to log into a EM capable phone, therefore preserving you personal settings (speed dials, your number etc.) while being on a different desk. This feature is  often used for shared desks or guest offices.

One of the caveats of EM was that one could only log into devices on a single cluster, e.g. if the organization has multiple clusters, user device profiles could not be used between clusters.

This limitation has been resolved in UCM 8.x with EMCC. EMCC allows one cluster to dynamically query "linked/trusted" clusters for a device profile.
The CCM Features Guide has a very nice diagram showing the login process.

EMCC Login Flow

There is one point which needs to be emphasized: For this to work, userids have to be unique across cluster and must not be duplicated. So if I am User "balbler" and the cluster in SJ is my home cluster and i want to do a EMCC login on the AMS cluster, my userid MUST not exist on the AMS cluster.
The reason for this is quite simple: The EMCC process will only query the remote cluster if it can not find the user in the local CCM db.

This is quite easy to do if you have a local user db.
It get's slightly more complicated if you bring LDAP integration into the picture.
DirSync allows you to sync userIDs from a LDAP directory (e.g. Active Directory or OpenLDAP) into the UCM user DB.
Most customers will have a single, global LDAP directory for the whole organization
In that case for EMCC to work, you have to make sure that usernames are not duplicated because of the sync.
There are 2 options on fulfilling this requirement:

• If possible sync only part of the LDAP tree (a subtree)
• Filter based on a attribute: This can be done via GUI on UCM 8.x (and was possible via sql manipulation of the ldapconfig table in prior versions)

So when planning on using EMCC and are already using LDAP Synchronisation, one needs to make sure there is a way to properly filter the users so there is no userid duplication.

Be aware that this will also mean that the ccm generated corporate directory will only contain the users from the local cluster. For a complate directory the CorpDir XML service will have to be replaced.

Some quick notes on UC on UCS Installations

1.)There is quite good documentation on CCO, including the SRND
2.)Some stuff i did have to search in the Docs
a.)the suggested Disc Setup for Co-Res on C-Series is:

• Disks 1+2 as Raid 1
• The other 8 Disks as a Raid 5

 b.)When using the pre-boot cli for Raid creation, the Enclosure IDs in the docs might be wrong for newer server (not "252" but "18" on a c210m2).
You can check this via the command:
encinfo -a0 -page 20
(the page option gives paged output)
Disk IDs for me did not start at zero (again, some docs state this but not all). This you will just have to try.
Otherwise a very nice installation.

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.