Showing posts with label Jabber. Show all posts
Showing posts with label Jabber. Show all posts

Wednesday, 28 June 2017

Phone Reason for Out of Service Codes

Examine jabber.log or Debug Display on a phone's web server to look for entries after a disconnect occurred.
Then refer to this list, which is scraped from CUCM Serviceability > Alarm > Definition > CallManager Alarm Catalog > Phone > Find > LastOutOfServiceInformation.
Note that CUCM 11.5 added some more reason codes but the alarm catalogue hasn't been updated, there's a bug listing for this: CSCvb63000

10   --  TCPtimedOut - The TCP connection to the Cisco Unified Communication Manager experienced a timeout error
12   --  TCPucmResetConnection - The Cisco Unified Communication Manager reset the TCP connection
13   --  TCPucmAbortedConnection - The Cisco Unified Communication Manager aborted the TCP connection
14   --  TCPucmClosedConnection - The Cisco Unified Communication Manager closed the TCP connection
15   --  SCCPKeepAliveFailure - The device closed the connection due to a SCCP KeepAlive failure
16   --  TCPdeviceLostIPAddress - The connection closed due to the IP address being lost.  This may be due to the DHCP Lease expiring or the detection of IP address duplication. Check that the DHCP Server is online and that no duplication has been reported by the DHCP Server
17   --  TCPDeviceRegsistrationTimedOut - The device closed the TCP connection due to a registration timeout
18   --  TCPclosedConnectHighPriorityUcm - The device closed the TCP connection in order to reconnect to a higher priority Cisco Unified CM
20   --  TCPclosedUserInitiatedReset - The device closed the TCP connection due to a user initiated reset
22   --  TCPclosedUcmInitiatedReset - The device closed the TCP connection due to a reset command from the Cisco Unified CM
23   --  TCPclosedUcmInitiatedRestart - The device closed the TCP connection due to a restart command from the Cisco Unified CM
24   --  TCPClosedRegistrationReject - The device closed the TCP connection due to receiving a registration rejection from the Cisco Unified CM
25   --  RegistrationSuccessful - The device has initialized and is unaware of any previous connection to the Cisco Unified CM
26   --  TCPclosedVlanChange - The device closed the TCP connection due to reconfiguration of IP on a new Voice VLAN
27   --  TCPclosedPowerSavePlus - The device closed the TCP connection in order to enter Power Save Plus mode
100  --  ConfigVersionMismatch - The device detected a version stamp mismatch during registration Cisco Unified CM
104  --  TCPclosedApplyConfig - The device closed the TCP connection to restart triggered internally by the device to apply the configuration changes
105  --  TCPclosedDeviceRestart - The device closed the TCP connection due to a restart triggered internally by the device because device failed to download the configuration or dial plan file
106  --  TCPsecureConnectionFailed - The device failed to setup a secure TCP connection with Cisco Unified CM
107  --  TCPclosedDeviceReset - The device closed the TCP connection to set the inactive partition as active partition, then reset, and come up from the new active partition
108  --  VpnConnectionLost - The device could not register to Unified CM because VPN connectivity was lost
200  --  ClientApplicationClosed - The device was unregistered because the client application was closed
201  --  OsInStandbyMode - The device was unregistered because the OS was put in standby mode
202  --  OsInHibernateMode - The device was unregistered because the OS was put in hibernate mode
203  --  OsInShutdownMode - The device was unregistered because the OS was shut down
204  --  ClientApplicationAbort - The device was unregistered because the client application crashed
205  --  DeviceUnregNoCleanupTime - The device was unregistered in the previous session because the system did not allow sufficient time for cleanup
206  --  DeviceUnregOnSwitchingToDeskphone - The device was unregistered because the client requested to switch from softphone to deskphone control
207  --  DeviceUnregOnSwitchingToSoftphone - The device is being registered because the client requested to switch from deskphone control to softphone
208  --  DeviceUnregOnNetworkChanged - The device is being unregistered because the client detected a change of network
209  --  DeviceUnregExceededRegCount - The device is being unregistered because the device has exceeded the maximum number of concurrent registrations
210  --  DeviceUnregExceededLoginCount - The device is being unregistered because the client has exceeded the maximum number of concurrent logons

Monday, 22 December 2014

Jabber IM Chat Log

The best way to log IM chats for Jabber is to use the server side chat logging to a PostgreSQL database, but for those of you who haven’t deployed this feature there is a limited workaround for getting at a user’s chat history...

Jabber for Windows will create a history of the last 99 messages in an IM conversation. When a conversation reaches 100 messages the client will loop and overwrite the history. The IM history is stored in a local database file in the user’s local machine profile:

C:\Users\[userid]\AppData\Local\Cisco\Unified Communications\Jabber\CSF\History

The .db file is simply an SQLite database file, and can be opened in any SQLite editor, such as DB Browser for SQLite.
Look at the history_participant table to find usernames in the jid field, if there are multiple entries with the same number in the item field then these are the conversation participants.
The history_item table lists details of a particular call/conversation, the item field from the history_participant table identifies the id in the history_item table.
The history_message table contains IM messages (with HTML tags) in the payload field, the date & sender fields let you identify when & who sent the message. The item field links to the id field from the history_item table and the item field from the history_participant table.

Thursday, 20 November 2014

Jabber SIP URI Dialling Check List

Quick check list for enabling calls to SIP URIs in Jabber:

  1. In LDAP Directory configuration set Directory URI to "mail" (i.e. use email address for URI).
  2. Configure a SIP Profile for use by Jabber with "Use FQDN in SIP requests" & "Allow presentation sharing using BFCP" enabled. Any SIP Trunk carrying URI calls will also need a SIP Profile with "Use FQDN in SIP requests" enabled.
  3. In Enterprise Parameters set the Organisation Top Level Domain & Cluster FQDN (e.g. example.com & *.example.com).
  4. In Enterprise Parameters set the Directory URI Alias partition.
  5. In CallManager Service Parameters check that SIP Max Incoming Message Size is >= 11000.
  6.  On the SIP trunk to the VCS Control/Expressway-C set Calling and Connected Party Info to "Deliver URI and DN".
  7. In jabber-config.xml under <Policies> put <EnableSIPURIDialling>true</EnableSIPURIDialling> & <DirectoryURI>mail</DirectoryURI>.

Wednesday, 20 August 2014

Jabber Pickup Groups

Cisco recently released Jabber for Windows 10.5 which introduces support for notification of calls to hunt groups & group pickup capability. However these features aren't enabled by default & the Call Pickup/Hunt Group sections in the Jabber Jabber deployment guide don't actually tell you this, nor does the release notes or the advanced functionality guide. To enable these features you need to add some parameters to jabber-config.xml, the deployment guide does list these parameters in the Client Configuration > Configure Users > Policies Parameters > On-Premises Policies section.
Below is an example jabber-config.xml that enable hunt group notification, pickup & other group pickup:

<?xml version="1.0" encoding="utf-8"?>
<config version="1.0">
 <Policies>
   <EnableCallPickup>true</EnableCallPickup>
   <EnableOtherGroupPickup>true</EnableOtherGroupPickup>
   <EnableHuntGroup>true</EnableHuntGroup>
 </Policies>

</config>

As per usual, this needs to be uploaded to all your TFTP servers & the TFTP service restarted.