In order for CUPC to receive presence information, it has to connect to a presence node.
Just to remind you again, "presence node" is NOT necessarily the same node as the logon server. For example, you have two CUPS servers - CUPS-A and CUPS-B. The logon server could be CUPS-A, but the "presence node" could be CUPS-B.
Even in a single-node environment, CUPC still has to run through a set of rules to determine the "presence address".
If you ever looked at CUPC > Show Server Health (or CUPC logs), you'll notice two parameters: "Presence.Primary.Address" and "Presence.Domain".
"Presence.Primary.Address" is the node name of the server. You may find this under CUPS Admin > System > Servers.
"Presence.Domain" is the SIP proxy domain. You may find this under CUPS Admin > System > Service Parameters > Cisco UP SIP Proxy.
If the node name was configured as dotted IP address (e.g. 192.168.1.100), CUPC will use that as the presence address.
If the node name was non dotted IP, things are more complicated. Here are the rules CUPC uses to determine the presence address:
When you specify a non IP string for the node name, CUPC looks at the string to see if it already ends with the domain value -- if not, it appends it. Examples:
1)
Proxy.Domain = cisco.com
Presence.Primary.Address = cup1
Registration will be to user@cup1.cisco.com (hostname, domain is appended)
2)
Proxy.Domain = cisco.com
Presence.Primary.Address = cup1.cisco.com
Registration will be to user@cup1.cisco.com (FQDN, domain was already included)
3)
Proxy.Domain = cisco.com
Presence.Primary.Address = 10.11.12.13
Registration will be to user@10.11.12.13 (address was dotted-decimal)
4)
Proxy.Domain = 10.11.12.13
Presence.Primary.Address = 10.11.12.13
Registration will be to user@10.11.12.13 (address was dotted-decimal)
5)
Proxy.Domain = 10.11.12.13
Presence.Primary.Address = cup1
Registration will be to user@cup1.10.11.12.13 (hostname, domain is appended) WRONG
6)
Proxy.Domain = 10.11.12.13
Presence.Primary.Address = cup1.cisco.com
Registration will be to user@cup1.cisco.com.10.11.12.13 (FQDN, domain is appended) WRONG
7)
Proxy.Domain = PROXY_DOMAIN_NOT_SET
Presence.Primary.Address = cup1.cisco.com
Registration will be to user@cup1.cisco.com.PROXY_DOMAIN_NOT_SET (FQDN, domain is appended) WRONG
The last 3 of these are wrong (there are other permutations) because the domain portion of the URI is neither an IP address nor DNS-resolvable FQDN. While the proxy might be content to match the strings, CUPC's SIP stack needs to resolve to a routable address.
Please note everything is case sensitive. If node name was cup1.cisco.com, proxy domain was CISCO.COM, presence address will be "cup1.cisco.com.CISCO.COM", which is also WRONG.
Wednesday, January 28, 2009
Monday, January 26, 2009
Mysterious "Invalid Crdentials" on CUPC
On CUPC > Help > Show Server Health, sometimes you would see failed items with the message "invalid credential", such as "Presence", "Desk Phone", or "Voicemail".
This is very confusing. Since you already logged into CUPC, why it's giving you "invalid credential"? What kind of credential it was failing on?
Before we can move further, please take a look at "CUPS and CUPC, father and son? or not".
CUPS and CUPC's relationship is not as tight as you thought. CUPC has many features, but CUPS is only relevant in two of them (configuration repository and presence).
When you type username and password on CUPC login window, that is majorly for "Configuration Repository". If you typed in the wrong password, CUPC won't be able to download configuration from CUPS. No other functions CUPC can perform without configuration.
However, sucessfully downloading configuration does not guarantee other functionalities. To use other fucntions, a 2nd authentication might be required (either explicitly or implicitly).
Presence - Invalid Credential
For presence feature, 2nd authentication is required on SIP layer. This authentication is implicit. For more details on "Digest Authentication", please see http://www.ietf.org/rfc/rfc3261.txt.
Why is it implicit? Why does it fail?
To make it implicit is Cisco development's decision. If they made it explicit, you'd have to provide digest credential (2nd password) after login. This could be annoying since SSO (Single Sign On) was what we preferred.
So Cisco development made CUPS/CUPC worked this way:
1) You (system admin) configure digest credential on CUCM Admin > User Management > End User page.
2) CUPS synchronizes digest credentials from CUCM to CUPS.
3) CUPS transmits digest credential to CUPC during logon.
4) CUPC uses that degest credential to authenticate with SIP proxy.
Step 3 and 4 look funny because it's like a door keeper gives the key to you and asks you open the door with the key. But keep in mind:
a) The "door keeper" acutally verified your identify (username/password), before giving you the key.
b) The key was encrypted during transmission.
c) The key door keeper gave you might be for a different door (SIP proxy could be on a different server other than the logon server)
d) This is a compromise (or balance) between inconvenience of SSO and SIP protocol requirements.
If there's no digest credential configured on CUCM (ie. it's blank), you'll get "Invalid Credential" for presence. To fix it, take one of the following options:
Option 1: Go to CUCM Admin > User Management > End User, configure a dummy value for "digest credential". It could be any value. Why? See workflow explained above.
Option 2: Go to CUPS Admin > Cisco Unified Presence > Proxy Server > Incoming ACL. (on CUPS 7.x, it's "System > Security > Incoming ACL". Configure an address pattern that covers your CUPC machines. For example, a "all" pattern matches all machines.
This option is considered less secure, because any machine in that address pattern (subnet) would be able to connect to SIP proxy without digest authentication challenge.
Option 3: Go to System > Service Parameters > Cisco UP SIP Proxy. Set "Authentication Module" to "off". This is the least secure option, which turns off SIP authentication at all.
Desk Phone - Invalid Credential
This usually happens when CUCM was configured to use "LDAP Authentication".
To control desk phone from CUPC, CTI protocol was used. Before a CTI client (CUPC) can control the phone, it needs to authenticate with CTI server (CTIManager). This authentication is implicit. CUPC would use the same logon username/password to authenticate with CTIManager. CTIManager, in turn, would authenticate that with LDAP.
Question: Why the authentication would fail?
Answer: In short, this is a bug on CUCM.
Question: Any workaround for that before we can upgrade CUCM?
Answer: On CUCM, change LDAP authentication port to 3268 and restart CTIManager.
Question: Why it would fix the problem?
Answer: When LDAP referral happens, CTIManager would fail on authentication. Using 3268 (Global Catalog) port eliminate LDAP referals.
Question: Why it only affects CUPC?
Answer: CUPC is the only application (so far) that uses end user credential to authenticate with CTIManager.
Voicemail - Invalid username/password or account locked
Depending on what Unity edition you're running (Unity or Unity Connection), the cause could be different.
Before moving on, please take a look at "How to test IMAP connection".
On Exchange 2007, it's because IMAP login was disabled on TCP (port 143) by default.
On Unity Connection, make sure you reset "Web Application Password" instead of VoiceMail password.
This is very confusing. Since you already logged into CUPC, why it's giving you "invalid credential"? What kind of credential it was failing on?
Before we can move further, please take a look at "CUPS and CUPC, father and son? or not".
CUPS and CUPC's relationship is not as tight as you thought. CUPC has many features, but CUPS is only relevant in two of them (configuration repository and presence).
When you type username and password on CUPC login window, that is majorly for "Configuration Repository". If you typed in the wrong password, CUPC won't be able to download configuration from CUPS. No other functions CUPC can perform without configuration.
However, sucessfully downloading configuration does not guarantee other functionalities. To use other fucntions, a 2nd authentication might be required (either explicitly or implicitly).
Presence - Invalid Credential
For presence feature, 2nd authentication is required on SIP layer. This authentication is implicit. For more details on "Digest Authentication", please see http://www.ietf.org/rfc/rfc3261.txt.
Why is it implicit? Why does it fail?
To make it implicit is Cisco development's decision. If they made it explicit, you'd have to provide digest credential (2nd password) after login. This could be annoying since SSO (Single Sign On) was what we preferred.
So Cisco development made CUPS/CUPC worked this way:
1) You (system admin) configure digest credential on CUCM Admin > User Management > End User page.
2) CUPS synchronizes digest credentials from CUCM to CUPS.
3) CUPS transmits digest credential to CUPC during logon.
4) CUPC uses that degest credential to authenticate with SIP proxy.
Step 3 and 4 look funny because it's like a door keeper gives the key to you and asks you open the door with the key. But keep in mind:
a) The "door keeper" acutally verified your identify (username/password), before giving you the key.
b) The key was encrypted during transmission.
c) The key door keeper gave you might be for a different door (SIP proxy could be on a different server other than the logon server)
d) This is a compromise (or balance) between inconvenience of SSO and SIP protocol requirements.
If there's no digest credential configured on CUCM (ie. it's blank), you'll get "Invalid Credential" for presence. To fix it, take one of the following options:
Option 1: Go to CUCM Admin > User Management > End User, configure a dummy value for "digest credential". It could be any value. Why? See workflow explained above.
Option 2: Go to CUPS Admin > Cisco Unified Presence > Proxy Server > Incoming ACL. (on CUPS 7.x, it's "System > Security > Incoming ACL". Configure an address pattern that covers your CUPC machines. For example, a "all" pattern matches all machines.
This option is considered less secure, because any machine in that address pattern (subnet) would be able to connect to SIP proxy without digest authentication challenge.
Option 3: Go to System > Service Parameters > Cisco UP SIP Proxy. Set "Authentication Module" to "off". This is the least secure option, which turns off SIP authentication at all.
Desk Phone - Invalid Credential
This usually happens when CUCM was configured to use "LDAP Authentication".
To control desk phone from CUPC, CTI protocol was used. Before a CTI client (CUPC) can control the phone, it needs to authenticate with CTI server (CTIManager). This authentication is implicit. CUPC would use the same logon username/password to authenticate with CTIManager. CTIManager, in turn, would authenticate that with LDAP.
Question: Why the authentication would fail?
Answer: In short, this is a bug on CUCM.
Question: Any workaround for that before we can upgrade CUCM?
Answer: On CUCM, change LDAP authentication port to 3268 and restart CTIManager.
Question: Why it would fix the problem?
Answer: When LDAP referral happens, CTIManager would fail on authentication. Using 3268 (Global Catalog) port eliminate LDAP referals.
Question: Why it only affects CUPC?
Answer: CUPC is the only application (so far) that uses end user credential to authenticate with CTIManager.
Voicemail - Invalid username/password or account locked
Depending on what Unity edition you're running (Unity or Unity Connection), the cause could be different.
Before moving on, please take a look at "How to test IMAP connection".
On Exchange 2007, it's because IMAP login was disabled on TCP (port 143) by default.
On Unity Connection, make sure you reset "Web Application Password" instead of VoiceMail password.
Saturday, January 24, 2009
Decrypt HTTPS traffic with Wireshark
Wireshark is a useful tool in troubleshooting. However, if the traffic was encrypted (such as https between CUPS and Exchange), it's unreadable unless you can decrypt it.
Look at packet 11 in sniffer capture above. Application data was encrypted. There's not too much useful data in it.
To decrypt this data, we need the "private key" of the server certificate. You cannot get the private key from client side (such as web browsers). To get the private key, you need access to the server.
Step 1. Export the server certificate with private key
1-1: Go to IIS Admin > Right-click "Defautl Web Site" > Properties > "Directory Security" > "View Certificate".
1-2: Go to "Details" tab > "Copy to File" > Choose "Yes, export the private key"
1-3: You'll save the file in PKCS #12 (.PFX) with all three options UNCHECKED
1-4: You'll have to provide a password to protect the file. Because private key is a very sensitive information.
1-5: Save the file (system will add ".pfx" extension to the file name)
Now we have a PKCS #12 file (.pfx file).
Step 2: Extract the private key from .pfx file
openssl pkcs12 -in test.pfx -nocerts -out privateKey.pem -nodes
The command above take "test.pfx" as the input file, extract the private key, save it unencrypted in "privateKey.pem" file. You'll be asked for the password (where you entered on step 1-4).
Where to find openssl? Google!
Step 3: Go to Wireshark > Edit > Preferences > Protocols > SSL. In "RSA keys list", type the following:
10.88.229.196,443,http,C:\privateKey.pem
Where "10.88.229.196" is the server IP. "443" is the port number (HTTPS). "http" is the protocol you want Wireshark decode to. "C:\privateKey.pem" is the file name of the private key. "SSL debug file" is optional.
Step 4: Once you click OK, you'll notice the changes on Wireshark screen. Now the data was decrypted!
Look at packet 11 in sniffer capture above. Application data was encrypted. There's not too much useful data in it.
To decrypt this data, we need the "private key" of the server certificate. You cannot get the private key from client side (such as web browsers). To get the private key, you need access to the server.
Step 1. Export the server certificate with private key
1-1: Go to IIS Admin > Right-click "Defautl Web Site" > Properties > "Directory Security" > "View Certificate".
1-2: Go to "Details" tab > "Copy to File" > Choose "Yes, export the private key"
1-3: You'll save the file in PKCS #12 (.PFX) with all three options UNCHECKED
1-4: You'll have to provide a password to protect the file. Because private key is a very sensitive information.
1-5: Save the file (system will add ".pfx" extension to the file name)
Now we have a PKCS #12 file (.pfx file).
Step 2: Extract the private key from .pfx file
openssl pkcs12 -in test.pfx -nocerts -out privateKey.pem -nodes
The command above take "test.pfx" as the input file, extract the private key, save it unencrypted in "privateKey.pem" file. You'll be asked for the password (where you entered on step 1-4).
Where to find openssl? Google!
Step 3: Go to Wireshark > Edit > Preferences > Protocols > SSL. In "RSA keys list", type the following:
10.88.229.196,443,http,C:\privateKey.pem
Where "10.88.229.196" is the server IP. "443" is the port number (HTTPS). "http" is the protocol you want Wireshark decode to. "C:\privateKey.pem" is the file name of the private key. "SSL debug file" is optional.
Step 4: Once you click OK, you'll notice the changes on Wireshark screen. Now the data was decrypted!
Friday, January 23, 2009
CUPS Calendar integration
Calendar integration is probably the most mysterious part of CUPS.
There are many catchas in Calendar integration due to the following:
1) CUPS uses WebDAV protocol to query calendar, which is a pretty old-school protocol and has many limitations. Microsoft recommend developers use EWS (Exchange Web Service) for better compatibility and features. Cisco will eventually change to EWS. But no ETA yet.
2) CUPS requires HTTPS (TLS/SSL) connection between CUPS and Exchange. This adds more complexity to the picture because you have to deal with CA, certificates, etc.
3) Exchange authentication and permissions
Exchange (OWA/IIS) has many authentication methods (FBA, classic, NTLM, etc.). Exchange also has two different sets of permissions: AD permission and Mailbox permission.
It's impossible to elaborate all scenarios in this blog. But here are some recommendations:
1) Avoid "2003/2007 mixed mode"
More likely than not, it's not going to work with CUPS due to limitation of WebDAV.
2) Avoid any firewall (especially MSFT ISA server) between CUPS and Exchange.
3) Avoid any load-balancer or traffice directory between CUPS and Exchange.
4) Try to disable FBA (Form Based Authentication) for troubleshooting purpose.
5) If you don't care about certificates, use "makecert.exe" utility to create self-signed certificate for Exchange. See http://www.lulu.com/content/5552336 for details.
6) Make sure you set your meeting status to "Busy" for testing. Make sure you set it to "whole day event" to avoid time zone glitches. (be aware, when you set it to "whole day event", the status in outlook will be "FREE" by default)
There are many catchas in Calendar integration due to the following:
1) CUPS uses WebDAV protocol to query calendar, which is a pretty old-school protocol and has many limitations. Microsoft recommend developers use EWS (Exchange Web Service) for better compatibility and features. Cisco will eventually change to EWS. But no ETA yet.
2) CUPS requires HTTPS (TLS/SSL) connection between CUPS and Exchange. This adds more complexity to the picture because you have to deal with CA, certificates, etc.
3) Exchange authentication and permissions
Exchange (OWA/IIS) has many authentication methods (FBA, classic, NTLM, etc.). Exchange also has two different sets of permissions: AD permission and Mailbox permission.
It's impossible to elaborate all scenarios in this blog. But here are some recommendations:
1) Avoid "2003/2007 mixed mode"
More likely than not, it's not going to work with CUPS due to limitation of WebDAV.
2) Avoid any firewall (especially MSFT ISA server) between CUPS and Exchange.
3) Avoid any load-balancer or traffice directory between CUPS and Exchange.
4) Try to disable FBA (Form Based Authentication) for troubleshooting purpose.
5) If you don't care about certificates, use "makecert.exe" utility to create self-signed certificate for Exchange. See http://www.lulu.com/content/5552336 for details.
6) Make sure you set your meeting status to "Busy" for testing. Make sure you set it to "whole day event" to avoid time zone glitches. (be aware, when you set it to "whole day event", the status in outlook will be "FREE" by default)
Wednesday, January 21, 2009
SIP domain and DNS domain
If you deal with SIP products (such as CUPS/CUPC), you'll have to deal with SIP domain sooner or later.
Here are some of the most asked questions:
1) What is a SIP domain?
2) Does the SIP domain has to match the DNS domain?
3) What if I'm not using DNS with the application?
SIP domain is more like on application layer versus DNS domain on network layer.
Let's take a look at a real life example. Let say, you have a SIP application that can send instant message and make phone calls (such as CUPC and MOC).
When the application initiate a call, the SIP message would look like this "INVITE 6002@acme.com". This message means - "I want to call extension number 6002 in ACME company".
Usually, the first stop of this SIP message would be your local proxy server (SIP proxy). The local proxy server will determine how to route this message to its destination.
Whenever a SIP proxy server receive a SIP message, it will always look at the domain part of the SIP request. Based on the domain, SIP proxy will determine how to route the message.
Here's the detailed workflow:
1) If the SIP message's domain matches with the SIP domain configured on SIP proxy, SIP proxy will handle that within the same domain. Otherwise, SIP proxy will forward it to a different domain (or just ignore/discard it depends on the design).
This is very important. Let say, CUPC sent a message "INVITE johndoe@acme.com" to SIP proxy. However, the SIP domain configured on SIP proxy was "abc.com". The SIP proxy will treat it as "foreign message" and try to forward it to its destination domain or discard/ignore it.
2) SIP proxy will look at the SIP static routes to determine the messages' destination.
SIP static routes are configured on the SIP proxy server on application layer. Don't confuse it with TCP/IP static routes.
On CUPS 6.x, you may configure static routes on CUPS Admin > Cisco Unified Presence > Proxy Server > Static Routes. On OCS 2007, you may configure static routes by right-click on the "Front End" folder > properties > routing.
You may configure IP address or FQHN for static routes.
For example:
Static route: acme.com ---> apple.acme.com
This means for all SIP messages with SIP domain acme.com will be routed to a host with FQHN apple.acme.com.
Static route: acme.com ---> 192.168.1.100
This means for all SIP messages with SIP domain acme.com will be routed to a host with IP address 192.168.1.100.
Keep in mind, the above is on application layer.
3) If there's no static route configured, SIP Proxy would try to determine the next hop by name resolution.
If SRV records were configured, SIP proxy would try to resolve the domain by SRV records.
Then SIP proxy would try to resolve by A records.
Now lets answer the questions.
Q1: What is a SIP domain?
Answer: A SIP domain is an application layer configuration that define the management domain of a SIP proxy.
2) Does the SIP domain has to match the DNS domain?
Answer: Yes, it has to match the DNS domain in most of the scenarios. And it's strongly recommended to match the SIP domain with DNS domain.
3) What if I'm not using DNS with the application?
Answer: You may or may not be able to use application features if you don't have appropriate name resolution configured. For example, in CUPC 1.2.x, you may use presence feature without name resolution to the presence FQHN. On CUPC 7.0.x, it doesn't work (because they changed the design on 7.0.x). If you don't have a DNS, you may use local host files to do name resolution.
To be continued...
Here are some of the most asked questions:
1) What is a SIP domain?
2) Does the SIP domain has to match the DNS domain?
3) What if I'm not using DNS with the application?
SIP domain is more like on application layer versus DNS domain on network layer.
Let's take a look at a real life example. Let say, you have a SIP application that can send instant message and make phone calls (such as CUPC and MOC).
When the application initiate a call, the SIP message would look like this "INVITE 6002@acme.com". This message means - "I want to call extension number 6002 in ACME company".
Usually, the first stop of this SIP message would be your local proxy server (SIP proxy). The local proxy server will determine how to route this message to its destination.
Whenever a SIP proxy server receive a SIP message, it will always look at the domain part of the SIP request. Based on the domain, SIP proxy will determine how to route the message.
Here's the detailed workflow:
1) If the SIP message's domain matches with the SIP domain configured on SIP proxy, SIP proxy will handle that within the same domain. Otherwise, SIP proxy will forward it to a different domain (or just ignore/discard it depends on the design).
This is very important. Let say, CUPC sent a message "INVITE johndoe@acme.com" to SIP proxy. However, the SIP domain configured on SIP proxy was "abc.com". The SIP proxy will treat it as "foreign message" and try to forward it to its destination domain or discard/ignore it.
2) SIP proxy will look at the SIP static routes to determine the messages' destination.
SIP static routes are configured on the SIP proxy server on application layer. Don't confuse it with TCP/IP static routes.
On CUPS 6.x, you may configure static routes on CUPS Admin > Cisco Unified Presence > Proxy Server > Static Routes. On OCS 2007, you may configure static routes by right-click on the "Front End" folder > properties > routing.
You may configure IP address or FQHN for static routes.
For example:
Static route: acme.com ---> apple.acme.com
This means for all SIP messages with SIP domain acme.com will be routed to a host with FQHN apple.acme.com.
Static route: acme.com ---> 192.168.1.100
This means for all SIP messages with SIP domain acme.com will be routed to a host with IP address 192.168.1.100.
Keep in mind, the above is on application layer.
3) If there's no static route configured, SIP Proxy would try to determine the next hop by name resolution.
If SRV records were configured, SIP proxy would try to resolve the domain by SRV records.
Then SIP proxy would try to resolve by A records.
Now lets answer the questions.
Q1: What is a SIP domain?
Answer: A SIP domain is an application layer configuration that define the management domain of a SIP proxy.
2) Does the SIP domain has to match the DNS domain?
Answer: Yes, it has to match the DNS domain in most of the scenarios. And it's strongly recommended to match the SIP domain with DNS domain.
3) What if I'm not using DNS with the application?
Answer: You may or may not be able to use application features if you don't have appropriate name resolution configured. For example, in CUPC 1.2.x, you may use presence feature without name resolution to the presence FQHN. On CUPC 7.0.x, it doesn't work (because they changed the design on 7.0.x). If you don't have a DNS, you may use local host files to do name resolution.
To be continued...
Monday, January 19, 2009
LDAP account keeps locking out on CUPC
CUPC has the capability to search LDAP. So you can easily add contacts to your CUPC contact list.
In order to search LDAP, the application (CUPC) has to authenticate with LDAP first. A service account was used. This service account was configured in CUPS Admin > Application > Cisco Unified Personal Communicator > LDAP Profile.
Once this service account was locked out, none of the CUPCs would be able to search LDAP.
The strange thing is: as soon as you unlocked the account, it got locked up pretty soon. By looking at Windows Event Viewer (Security Log), you'd see the source was the CUPC computer. You changed the password in LDAP, and changed it on CUPC. But the account still got locked up.
Now you got confused. Since you already "refreshed" the password, why the account still got locked up?
The answer is: the "refresh" didn't get populated to CUPC. Some of the CUPCs were still trying the LDAP with old (wrong) password.
When you change the LDAP profile on CUPS, CUPC didn't get the updated profile (password) until next logon. It'll keep trying LDAP with the old password and keep locking out the account.
To solve this problem, you'll have to logout all CUPC before you unlock the LDAP account.
Sometimes, this is "mission impossible" in a large network where you have hundreds of users.
The workaround is:
1) Create a 2nd LDAP account.
2) On CUPS, update LDAP profile to use the new account.
On step2, you have to make sure you put in the correct information in one shot. If you misconfigured something and tried to correct that, chances are some CUPC might get the wrong info before you corrected it. The loop starts again.
Thursday, January 15, 2009
LDAP Integration with CUPS
There's no GUI on CUPS to configure "LDAP Integration".
CUPS synchronizes users from CUCM. CUPS does not sychronize with LDAP.
How about "CUPS Admin > Application > Cisco Unified Personal Communicator > LDAP server"? Well, as the menu inidcated, it's a configuration for CUPC. It's not a configuration for CUPS. CUPC download this configuration upon login and use that to query LDAP (for contact search).
Even though LDAP integration is not configurable on CUPS, it might affect CUPS in an unexpected way.
Scenario 1: CUCM is using LDAP authentication. CUPC user not able to login.
When CUPC users try to login, the username/password was authenticated aginst CUPS (via SOAP). In turn, CUPS will authenticated the username/password against LDAP (because CUCM is using LDAP authentication). If for whatever reason, CUPS having problem with LDAP, authentication would failed.
Reason A: Access-list blocked traffic between CUPS and LDAP. Access-list allow traffic between CUCM and LDAP. Access-list allow traffic between CUPS and CUCM.
In this case, CUPS would synchronize CUCM users over. But those users won't be able to log into CUPC. Because CUPS cannot talk to LDAP.
Reason B: CUCM was configured to use LDAP over SSL (LDAPS). Certificates were uploaded to CUCM but not to CUPS.
In this case, CUPS won't be able to set up the LDAPS connection because the certificates were missing.
Frequently asked questions:
Do I need CUCM/LDAP integration to use CUPS/CUPC?
Answer: No. But there are some catchas. CUCM/LDAP integration is highly recommended.
Explanation:
1) Without LDAP, adding contacts to CUPC would be a pain. Because CUPC cannot search CUCM for contacts. (there's no such a thing called "CUCM native directory")
2) If you use LDAP with CUPC but not CUCM, potential problem is on the way. If you search LDAP from CUPC and add that contact to CUPC contact list, user ID in LDAP would be used as "presence user ID". If the "presence user ID" is different with the user ID in CUCM, you won't be able to see your contact's presence (your contact would always be offline).
Workarounds:
1) Make sure the user ID in LDAP matches the user ID in CUCM.
or
2) If the CUCM ID happens to be the phone extension number. And you happen to have the phone extension number configured in LDAP. You may go to "CUPS Admin > Application > Cisco Unified Personal Communicator > Settings" to map the LDAP phone attribute to the CUPC "user ID" attribute.
Wednesday, January 14, 2009
LDAP integration with CUCM 5.0 or above
On CUCM 5.0 or above, LDAP integration actually consists of two parts:
Part 1: LDAP Sychronization.
Part 2: LDAP Authentication.
You may enable part 1 without part 2. But you cannot enable part 2 without part 1.
In either scenario, CUCM never, ever synchronizes passwords from LDAP.
Part 1: LDAP Sychronization
When LDAP synchronization was configured, CUCM will import user accounts from LDAP and create users in CUCM database. As mentioned before, CUCM won't import passwords. CUCM will import user ID, first name, last name, etc.
Any user that pre-exists in CUCM user database but not exists in LDAP will be deleted. CUCM will mark them as "delete pending" and give them 72 hours grace period. After 72 hours, those "delete pending" accounts will be deleted permanently and no way to recover.
Part 2: LDAP authentication
Whenever a CUCM user need to authenticate, CUCM will authenticate the password against LDAP.
Commonly seen problems:
1) Some user accounts in LDAP didn't synchronize over to CUCM
Usually, it's because some 'critical' attributes were missing. For CUCM, "last name" is a critical attribute. If the LDAP account does not have last name configured, it won't synchronize over to CUCM.
2) Slow synchronization
If you have a large active directory, use Global Catalog port (default is 3268) is recommended.
3) LDAP over SSL
After uploading the certificate to CUCM for LDAP over SSL, you need to restart Cisco Tomcat service to take effect.
Saturday, January 10, 2009
CTI vs. Presence
When talking about "phone presence", people are always confused with "line status".
CTI (Computer Telephony Interface) has been around for a while. It allows computer software control phone devices. So you can make calls, answer calls, tranfer calls, etc.
The software that controls the phone is usually referred as "CTI client". More often than not, there's a "CTI server". In Cisco products, CTI clients include Attendant Console client, Cisco Agent Desktop, etc. CTImanager on CUCM (CallManager) is the CTI server.
When a phone was controlled by CTI, the phone's staus is usually reported to CTI client. For example, when you pick up the handset on the phone, CTI client would display "off-hook" or "dial tone" on the screen. We usually refer this as "CTI status" instead of "Presence".
You can only see CTI status for the phones you controlled. You won't be able to see CTI status on other phones. CTI is more like a protocol to control the phone.
"Presence" is a rather new term comparing with CTI. "Presence" is usually referred to the SIP extension SIMPLE (Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions).
When using "Presence" with phones, we can see the status of the phone (off-hook, on-hook, do-not-disturb, etc.). You don't necessarily have control of the phone. In face, "presence" won't provide any function to control phone devices.
Keep that in mind when you troubleshoot clients (such as CUPC, MOC, etc.)
For example, when you make a call from your phone, MOC would display the phone status (CTI status). However, you might not be able to see the phone status of your contacts on MOC contact list. That part was "presence".
Tuesday, January 6, 2009
How to test IMAP connection
IMAP is a protocol to retrieve email from mail server. With appropriate settings, Cisco Unity allows application retrieve voicemail via IMAP. CUPC is one of the clients that uses IMAP to retrieve voicemail.
There are two Unity families - regular Unity (which works on Windows and Exchange) and Unity Connection (a Linux appliance).
For regular Unity, MS Exchange is required as mail store. CUPC should always point to Exchange. But the GUI on CUPS refers this as "Unity Server". This is pretty confusing, especially in "Unfied Messaging" mode, where Unity server and Exchange are actually two different servers.
By default, IMAP service is disabled on Exchange. You'll have to go to Windows services to set the startup type to "Automatic" and start it. Please note the following difference between Exchange 2003 and 2007:
Exchange 2003 use IMAP over TCP (port 143) by default.
Exchange 2007 use IMAP over SSL (port 993) by default.
The bad thing about SSL is you cannot test it with telnet command. We'll talk about the workaround later.
For Exchange 2003, here's how to test the IMAP connection and login.
Each command begins with a number and a space. Though you may use any numbers and you may reuse the number, it's recommended you use unique, sequential numbers.
The first command we want to use is "capability". Pay attention to "LOGINDISABLED" in screen output. You usually saw that on Exchange 2007, which means LOGIN is disabled on TCP (available on SSL only). On Exchange you normally won't see that.
If you don't see "LOGINDISABLED", you may continue the test.
The next commend is "login JohnDoe pass123", where JohnDoe is the username you want to test and pass123 is the actually password. If you got a "OK", that means the username and password was correct.
As mentioned about, on Exchange 2007, LOGIN on TCP was disabled by default. To enable it, you run the following commands on in Exchange Management Shell:
Set-IMAPSettings –LoginType 1
Resart IMAP service after that.
Currently, CUPC does not support IMAP referral. Which means, if you have multiple mailbox servers, you have to enable IMAP service on each one and create multiple profiles on CUPS.
Monday, January 5, 2009
Name resolution in Cisco voice products
In Cisco documentations, there's no specific requirements for name resultion. You may install Cisco voice products (such as CUCM, CUPS, CER) without worrying about name resolution. The reason was - there's a process on those products called "ClusterManager'.
ClusterManager is the process takes care of IPSec communication between nodes in a cluster. ClusterManager also takes care of host table (/etc/hosts). Whenever a node was added to the cluster, ClusterManager will add the hostname into host table. Hence every node in the cluster should be able to resolve each other's hostname without DNS involved.
Before we moving on, let's get familiar with some terminologies.
Hostname - The name for a computer. e.g. ccm-1. This name was entered during installation and used as the default "node name". To show the host name, use CLI command "show status".
Node name (or process node name) - The name for a voice appliance(application). By default, the node name was set to the hostname entered during installation. You may change the node name to any value. But the hostname stays the same. To show the node name, use CLI command "run sql select * from processnode".
Domain name - A name for a domain (a group of computers). e.g. sales domain, support domain, etc. A domain name could be ambiguous. For example, a sales domain could mean the sales domain in Asia Pacific or the sales domain in Europe. To eliminate this ambiguity, we want to use Fully Qualified Domain Name (or FQDN).
Fully Qualified Domain Name (or FQDN) - For example, sales.apac.acme.com. is a FQDN. (Technically, every FQDN should have a dot (.) at the end. The dot means the root. Without the dot, it's not a FQDN, it's a partial domain.)
Fully Qualified Host Name (or FQHN) - a FQHN consists of a hostname and a FQDN. For example, a FQHN ccm-1.acme.com. consists of a hostname ccm-1 and a FQDN acme.com.
For the reason mentioned above (to avoid ambiguity), all DNS query should use FQHN or FQDN. If a hostname was used, it's the client's responsibility to translate that into a FQHN. For example, on client PC, we do a "nslookup ccm-1". Windows actually translates "ccm-1" into "ccm-1.acme.com" before sending out the query to DNS server. A sniffer capture could prove this.
The key point is - whether the client can translate the hostname into a correct FQHN.
This translation is controlled by the "DNS suffix" configuration on client side. Client computers usually got this from DHCP. To see the DNS suffix, use "ipconfig/all" command in Windows command prompt.
Though we don't have to worry about name resolution on voice servers (CUCM, CUPC, etc.), we do have to take end points (clients) into consideration. End points might request hostname even though you thought you were using IP address.
IP Phones.
Let say, you just finish installing a CUCM 6.1.2 server (named ccm-1). You registered Cisco IP phones to the CUCM. You can make make/receive phone calls. Everything looks good, right? Right, until you press the "Directory" button on IP phone.
When you press the "Directory" button on IP phone, the phone actually acts like a web browser and initate a http request to http://ccm-1:8080/ccmcip/xmldirectory.jsp. If the phone cannot resolve ccm-1 into an IP address, it won't be able to make that connection.
"ccm-1" is the node name. By default, it's the hostname you entered during installation. You may change the node name on CCMAdmin page > System > Servers. Changing the node name does not change the hostname.
Application Clients (such as Attendant Console client)
On Attendant Console client logon, you specified IP address of the CUCM server. You successfully logged in. But you were not able to control the phones. Looking at log files, you realized that Attendant Console client was trying to initiate the JTAPI connection to CUCM server by node name (ccm-1). Adding ccm-1 to C:\Windows\system32\drivers\etc\hosts on client computer solved the problem.
CUPC (Cisco Unified Personal Client)
Things become more insteresting (complicated) when SIP comes into play.
On CUPC 7.x, some customer noticed an annoying behavior. On the first logon, user specified HQHN of CUPS server (e.g. cups1.acme.com) as the login server. CUPC logged in successfully. Exit and re-launch CUPC. User noticed that the login server field was automatically poplated with the CUPS node name (e.g. cups1). Since "cups1" was not resolvable from the client computer, logon failed. User changed the login server to FQHN cups1.acme.com. Logon succeeded. But on next logon, it changed to hostname again.
This annoying behavior is actually a new feature in CUPC. We might have multiple CUPS servers in a cluster. To better load-balancing between those servers, we specify a "home node" for each user. A user's request should designated to his "home node" (unless the "home node" is down). On the initial logon, CUPC gets "home node" information from CUPS. CUPC will try to use "home node" as logon server afterwards. This is why the login server field was populated with the node name (by default, it's the hostname).
You might want to ask "why does the client computer can resolve FQHN but not hostname?". Please refer to the earlier section of this article. It was because DNS suffix was "incorrect". I put a quote around "incorrect" because sometimes, it can't be fixed.
Scenario #1. The client computer is on a offsite location (mobile user, VPN, etc.), where the DNS suffix from DHCP is not the same as the corporate domain. (e.g. "isp.com" instead of "acme.com")
Scenario #2. Customer has multiple subdomains (e.g. "apac.acme.com" and "emea.acme.com"). The client computers are in different subdomains.
Workarounds (pick one below):
#1 On CUPC side, manually change the login server to FQHN on each login.
#2 On CUPC side, add the hostname to local hosts table (C:\Windows\System32\drivers\etc\hosts)
#3 On CUPS side, change the node name to FQHN.
#4 On CUPS side, change the node name to IP address.
Thursday, January 1, 2009
CUPS and CUPC - Father and Son? Or not?
Like many client/server models, people would think CUPS and CUPC are like father and son, like Exchange and Outlook.
However, CUPS and CUPC are more like peers. They were designed by two different groups of developers. These two groups treat each other as an "important customer", but not the only customer.
For example, CUPS can be used without CUPC.
Example #1: MOC RCC (Microsoft Office Communicator Remote Call Control).
MOC can control an IP Phone via CUPS and CUCM without CUPC in the picture.
Example #2: SIP Proxy
CUPS acts as a SIP proxy without CUPC in the picture.
Example #3: IPPM (IP Phone Messenger)
An IP phone can see buddy's status, send IMs, retrieve meeting schedules without CUPC in the picture.
On the other hand, CUPC was built as a multi-function software other than just a "CUPS client".
Right now, CUPC can't function without CUPS. Because it uses CUPS as a configuration repository. CUPC has to retrieve the configuration from CUPS for all its features. But except for the presence feature, all other features do NOT rely on CUPS.
For example, CUPC's soft phone feature is most demanded from Mac OS users. It's the only Cisco soft phone works on Mac OS. (CIPC - Cisco IP Communicator does not run on Mac). However, to use CUPC, you need a CUPS server. In this scenario, CUPS server provides no value other than supplying the TFTP address to CUPC. If CUPC can save the TFTP address locally (like CIPC), there's no need for CUPS server. It makes perfect sense from both technical and economic perspective.
Same for other CUPC features like Voicemail, Web Conference, LDAP search, click to dial, etc.
For this reason, CUPC developers are considering the options of "separating CUPC from CUPS" and make them more independent to each other.
With that said, CUPC and CUPS are more like peers other than father and son (or couple). Keep that in mind would help you understanding the function modules of CUPC.
Cisco Presence Products
When talking about Cisco presence products, we usually refer to BLF (Busy Lamp Field) and CUPS (Cisco Unified Presence Server).
BLF is a built-in feature of CUCM (CallManager). It allows you to see a person's phone status (off hook / on hook) on a speed dial button or in phone directory.
BLF: Pone 6001 is on-hook (idle)
BLF: Pone 6001 is off-hook (active)
For more information regarding CUCM presence, please see: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/6_1_1/ccmfeat/fsprsnc.html
CUPS (Cisco Unified Presence Server) is a standalone products. It requires a separate server, it cannot coresident with CUCM. For supported server models, see: http://www.cisco.com/en/US/docs/voice_ip_comm/cups/7_0/english/compatibility/cupcompatibility.html
Usually, CUPS is used with a presence client - CUPC. The official name of CUPC is "Cisco Unified Personal Communicator". Some people also refer it as "Cisco Unified Presence Client".
CUPC can run on Windows and Mac OS. CUPC is a multi-function client. It can send IMs (like MSN Messenger). It can display your buddies' presence (on the phone, in a meeting, etc.). It can retrieve voicemail. It can control your desk phone. It can act as a soft phone as well. It support video calls. It can also be a outlook plugin. So you can "click-to-dial" from Outlook.
For more information regarding CUPC, please see: http://www.cisco.com/en/US/products/ps6844/index.html
Introduction of 'Presence'
Many people are still confused about 'presence' and what it can do for us.
The official explanation of presence was "Presence is a real-time indicator of a person’s willingness and availability to communicate".
Ya, that explanation is as clear as mud. Let's take a look at some real life examples.
Instant Messaging.
If you're reading this blog, you're unlikely to be unaware of "Instant Messaging" (or IM). Just to name some of the IM software: MSN Messenger, Yahoo Messenger, AOL Messenger, ICQ, IBM Sametime.
Obviously, the major purpose of IM software is to send instant message. Yet another important information they provide is buddy status - 'Available', 'Away', 'Out to lunch', 'In a meeting', 'Do not disturb', etc. Those status are 'presence' info, and play a more and more important role in our life.
Phone presence.
With the adoption of IP phones, more and more features were built on it. In the old world, you call somebody and got a busy signal. You know he's on the phone. In the new world, you could see if he's on the phone or not, before you actually call him. This is called 'phone presence'.
Let say, you'd like to ask your buddy out for lunch. With presence tool, you know he's on the phone. You would use other method to communicate, such as instant message, email, etc. With appropriate tools, you can even send the instant message to his IP phone.
Calendar presence.
If you'd like, you may also have the presence software publish your calendar status. So your buddy would see your status as 'In a meeting' when you have a meeting going on in the calendar.
Subscribe to:
Posts (Atom)
