Stack8 Technologies Inc. is a new breed of Cisco Solutions Partner. The founders, former Cisco guys, created the company to provide Cisco solutions adapted to each customer’s reality. Their focus is on how people use Cisco technology and ensuring they get the most out of it.
Good day Pedro, Based on our insights, Jabber is here to stay for the foreseeable future. True, their is a big marketing push for Spark. However, your choice is dependent upon your or your customer's business requirements. We actually just released a new technical article regarding Jabber and the next major iOS release. You can read it here:
... View more
"The Future of Cisco UC: The URI Advantage" was a recent post by the team at Stack8 that explained URI and the advantages of using it in your Unified Communications Environment. A directory URI is the abbreviation of U niform Resource Identifier and its directory format is similar to an email address (username@host) where the host portion is an IPv4 address or a fully qualified domain name. One of the main advantages that was outlined in the above article was that by adding SIP URI integration in your dial plan or at least a URI directory adds significant flexibility.
The following post, we take you through the step-by-step to setting up and activating URI dialing within a Cisco UC environment from mapping the Directory URI address to an email address to modifying display preferences.
Step 1: Map Directory URI address to email address
We must map the Directory URI address to the email address of the user. If your Cisco UC environment is LDAP synchronized, then the Directory URI address is most commonly already mapped to the email address of the user from the corporate directory, so this step is taken care of.
If this is not the case, you will have to include the mapping in your LDAP Directory sync or simply enter on each End User's settings into the Directory URI manually as an alternative solution.
Step 2: Select Primary Extension for each user
Once the Directory URI for each user is mapped to their email, the next step is to make sure the Primary Extension field is selected for each user (User management - End User Configuration). This will automatically associate the Directory URI with the user’s primary extension.
Step 3: Ensure URI partition is part of the phone CSS
The next step is to ensure that the Directory URI partition is part of the phone CSS. An alternative option to achieve this is to map Directory URI to an existing partition from the Enterprise Parameters Configuration, "Directory URI Alias Partition” option.
Step 4: Change case sensitivity in URI Lookup policy
Now, in the same Enterprise Parameters section, make sure you change the “URI Lookup Policy” from the default “Case Sensitive” to “Case Insensitive”.
Step 5: Update phone SIP profile
Now go to the phone's SIP profile, check “ Use Fully Qualified Domain Name " in SIP requests.
Step 6: Activate and configure Intercluster Lookup Service and Directory URI (Multi CUCM clusters only)
For environments with multiple CUCM clusters, ILS activation, and proper configuration is required. In order to verify if users URI addresses are replicated from a Home cluster to remote clusters using ILS service: go to Call Routing -- Global dial plan replication and check the "Learned Directory URIs" section.
NOTE: Keep in mind that there are two known bugs related to ILS URIs replication:
Bug 1: CSCuv57329: ILS 10.5 cluster does not insert URIs received from 9.1.2 Cluster
Workaround: Remove the apostrophe (') from the configured URI in all 9.x clusters.
Bug 2: CSCur59758: ILS should encode special characters when saving it in Database.
Workaround: Delete temporarily the specific URI from spoke/source cluster, and connect the spoke with HUB again.
Step 7: Configure SIP trunks (Multi CUCM cluster only)
Make sure you have configured the SIP trunks between each pair of clusters in your UC environment. Also, create SIP route patterns with the ILS Route string as Domain and assign the respective SIP trunk towards the remote cluster as the destination.
Step 8: Modify URI display preferences for B2B calls feature with Expressway
If you have Expressway with B2B configured in your Cisco UC environment, make sure that within the CUCM Service parameters, Cluster-wide Parameters section “URI Dialing Display preference” is set to “URI” instead the default “DN” . This is to make the "call-back" on a B2B call functional. Otherwise, when you receive a call via the B2B feature, the extension/DID instead of URI is displayed on your SIP phone. In consequence, you will not be able to dial back the person using the calling information from your phone as the URI is not displayed properly.
Lastly, ensure that the SIP trunk from CUCM towards Expressway is using the SIP profile with the “ Use Fully Qualified Domain Name in SIP requests” option activated.
Now you have completed all of these steps you are all set to begin dialling with URI. You can now dial anyone within your company via your email from your phone, jabber or video end device: Another big advantage of configuring URI within your CUCM.
Are you interested in setting up SIP URI dialling in your environment and need some help integrating it into your Cisco Unified Communications environment, let us know we would be happy to give you a hand.
For more tips and insights regarding Cisco Unified Communications, please visit the team at Stack8
... View more
More and more companies these days have mobile workforces: teams that work on the road or who have the ability to work from home. To help maximize efficiency and to make this mobility seamless to the individuals and the rest of the team Mobile and Remote Access (MRA) via Cisco Expressway is the key. Being able to use Cisco Jabber and IM&P help bring mobile collaboration to another level. However, there are times when this seamless mobility runs into a snag and an error occurs; one of the most common errors while using Jabber in MRA mode via Cisco Expressway is "cannot communicate with the server". Today's tip is about how to effectively troubleshoot this problem.
Cisco Jabber login error when trying to communicate using Mobile and Remote Access via Cisco Expressway: "cannot communicate with the server".''
The following will outline three areas to explore when troubleshooting your Cisco Jabber login error: " cannot communicate with server" when trying to communicate using Mobile and Remote Access via Cisco Expressway. In this scenario, we will assume that the user is able to login to Jabber from inside the corporate LAN and focus our troubleshooting efforts on Expressway pair servers.
STEP 1. Verify the DNS and firewall related configurations.
Verify that the collab-edge.tls.company.com SRV type DNS record is present. Please note that it is important to set the type to SRV. In this example below, we use a well known public DNS server.
b) Verify that the returned FQDN of the Expressway-Edge server from the SRV record is resolving to an IP address.
c) Verify that the Cisco Expressway-Edge server's FQDN name matches exactly the value created in the collab-edge SRV record.
Defect CSCuo82526: MRA Jabber does not send cookie x-auth token with login request.
d) Verify that the corporate firewall has a rule for port 8443 that forwards traffic to the DMZ LAN interface of the Expressway-Edge server.
STEP2. Verify that the traversal-zone between Cisco Expressway Edge and Core servers are <<Active>>.
Verify the Expressway-Edge server.
b) Verify the Cisco Expressway-Core server.
c) Verify that Unified Communications status on Cisco Expressway-Core is enabled and configured
If both the main configuration and the Cisco Expressway-Edge and Core servers are active then proceed to step 3 and start digging into the log files.
STEP 3. Dig into the log files of Expressway.
Start by digging into the Network logs and filter using <<trafficserver>>. This will help you see how the get_edge_config process between the Edge and Core servers is happening.
b) Now begin a dignostic log and reproduce your problem. Make sure to check <<take tcpdump while logging>> which will generate a pcap file as well. Note: there is an alarm active once you start your diagnostic log and it will disappear automatically when you stop the diagnostics. There is also a <<download>> option available after diagnostic logging is complete. These logs are the first thing that the Cisco TAC will require from you if you open a case with Cisco in regards to Expressway.
Analyze the logs. The following identify the two most common errors to look for in your diagnostic logs.
Error: <<SIP/2.0 405 Method Not Allowed>> If this error is found in the Core logs, it is in response to SIP registration request failure. Resolution: The error is usually due to an existing SIP trunk between Expressway-C and CUCM using port 5060/5061 (the trunk is not used for MRA, but usually is created for another feature of Expressway – B2B dialing). In order to correct the issue, you will have to change the SIP port on the SIP Trunk Security Profile that is applied to the existing SIP trunk configured in CUCM. You can use 5065 instead.
Error: <<edgeconfigprovisioning: Level="WARNING" Service="UDSManager" Detail="User cluster not found">> If this error is found and you have multiple Unifed CM clusters defined in Expressway-Core. Resolution: In this case ILS (Intercluster Lookup Service) must be set up on all of the clusters. This is because the Expressway has to authenticate a client against its home Unified CM cluster and to discover the home cluster it sends a UDS (User Data Service) query to any one of the Unified CM nodes over ILS.
After you have completed the above three steps you should have been able to identify and resolve your Jabber "cannot communicate with the server" error. If you need occasional or ongoing additional support please feel free to contact us at Stack8.
... View more
You have integrated Jabber for your internal Instant Messaging and Presence needs (IM&P). Someone at your company is trying to get in touch with you, but your Jabber status shows as " Offline" even though you are logged in. How can you identify the source of the problem? What can be done do to fix this issue? This issue is usually a scattered occurrence and one that not everyone is able to observe, making troubleshooting a challenge.
Note: This document was originally published by the team at Stack8 as a tip and insight for the Cisco Unified Communications community
PROBLEM: Jabber status shows as "Offline" to others, even though you are logged in.
The following will provide you with a simple verification method to identify the two most probable causes to this issue and how to handle them.
Step 1. Verify the user's account on the Call Manager
Log into the CUCM admin page (9.1 & later) or the IM & P admin page for (8.6 & earlier).
Look at the user's account status at the server level.
A. The Presence server shows your user as "Available", then you have a user level issue; move to step 2A. B. The Presence server shows your user as "Offline", then you have a server level issue; move to step 2B. Step 2A. User level issue resolution Now let's look at the Jabber client user level to see if there are multiple profiles that appear.
Type in the username in the search box.
Multiple instances could show up. There are three possible issues that can be causing these multiple instances:
the jabber cache of local contacts,
the integration of outlook contacts, and
the duplication of contacts in LDAP.
At this point, the user simply needs to ensure they select the correct profile to communicate with over Jabber .
To clean up contacts you can do the following:
Close the Jabber application, then clear the jabber cache of local contacts.
Determine whether or not you would like Outlook contacts in Jabber, this will almost always create duplicates, at this point, you will need to ensure you choose the correct profile.
Look into LDAP, validate user credentials, delete or hide duplicates as needed.
-Remember for all of these, always close Jabber application before making a change-
Step 2B. Server level issue resolution
This can be a common occurrence when you are operating in an environment that has redundant Presence servers. The following steps should be used to validate that this is the true issue:
Verify if your users are configured under the same Presence server, from the cluster topology in IM&P admin page.
Conduct a test by adding users to the same server.
The Presence status should change after the users have been added to the same node. In this case, the servers most likely lost connection and were unable to properly synchronize afterwards. In this case, you will need to conduct a full reboot of the Presence cluster to restore functionality .
If the presence status does not change, then the problem does not lie at the server level and there is no need for a full reboot. You must continue to troubleshoot to identify the source of the problem.
By conducting this simple validation test, you will be able to identify whether the cause of the user's "Offline" Jabber problem is at the user level or the server level and then take the appropriate course of action to resolve or manage the issue. Thus, showing your user as "Available" when logged in and "Offline" when logged out.
For more information, please visit us at Stack8
... View more
In this blog post, we will explore 3 possible troubleshooting solutions in order to identify and resolve the c hallenges of registering phones to the CUCM.
SOLUTION 1 - Delete Trust Lists
This first solution troubleshoots one of the most common problems when introducing new devices to your Unified Communications environment. Typically, this occurs with pre-used phones who retained the information of the previous CUCM.
Step 1. Unlock the phone and delete the CTL and ITL files.
Navigate to the security settings on your phone, the location can vary depending on the phone model. Certain models will have a “reset security settings”, others will require you to navigate to the CTL & ITL files manually.
Use “**#” to unlock your phone and delete the CTL & ITL files.
Step 2. Verify that the phone has registered.
Once you’ve deleted the security settings, the phone should restart. Verify if it registers.
Want more tips on CUCM please visit us at Stack8
SOLUTION 2 - No Network Connectivity
Step 1. Verification of connectivity via packet capture
You can take a packet capture by one of two methods, either by using “ span PC port ” functionality of the phone or by configuring the same functionality on the switch .
Packet Captures can be difficult to read when there is a lot going on, narrow it down the fields as much as possible with the following filters in Wireshark :
ip.addr eq and ip.addr eq
Step 2. Validate 2-way connectivity
The next thing to do is validate that there is two-way communication between the CUCM and the phone. If there is none, then we can confirm there is no network connectivity.
If there were no network connectivity, you would see traffic originating from your phone’s IP address only, not the CUCM (first column is the originator).
Solution 3 - Validate File Downloadability
Finally, we will want to see is that the phone is able to download its files.
Step 1. Verify that .cnf is being downloaded
.cnf files contain the phone configuration, in the below screen capture we see the GET sent by phone on line 4, we then see the transaction being completed successfully on line 13.
Step 2. Verify that .tlv file is being downloaded .tlv files contain the security information which allows the phone to trust the CUCM, we see the GET on line 1, and in this case, the CUCM returns “404 Not Found”.
Step 3. Investigate resolution options below
If you are not able to download any files from CUCM, always ensure that TFTP is permitted on your network, you can also attempt to reboot the TFTP service on CUCM, this will only affect phones which are in the registering process.
If the phone isn’t finding the .cnf file, it is possible that there is a typo in the device name of the call manager.
If the phone isn’t finding the .tlv file, it is possible that there is a problem with the TVS service, this service much like the TFTP service will only affect phones which are attempting to register to the call manager. If this is the case, the issue is always widespread and may require the server to be rebooted.
Useful Insights - Phone Traces
Reading traces is an unpopular way of diagnosing problems, however, it can quickly become your go-to technique if you work on it. Don’t ever be afraid to collect logs, whether it be endpoint or server logs, if you have a good idea of what you want to find, you may be able to get it without fully understanding the log file.
The logs we will need for this are the console logs from the phone, we should take the latest one – in this case, I will take /FS/cache/log85.log:
So, once we’re in the log file, if you’re familiar with log files, you can parse through these manually. Alternatively, we can search for keywords which will point us in the right direction. For instance, search for CTL – This will bring you to all of the lines involving certificates.
And in this case, we can see that there is an error – The call manager isn’t in the phone’s trust list. This is why the phone is being rejected from the CUCM.
With the help of these steps, you should be in good shape to diagnose the issue behind why your phone is not registering to your CUCM. Alternatively, you can always reach out and discuss how we can help; The team at Stack8 are experts at troubleshooting Cisco Unified Communications issues for our customers.
... View more