Jabber for Windows Call Flow Analysis Procedure

Available Languages

Updated:July 29, 2013
Document ID:116309

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

This document describes the procedure used in order to analyze call flow in Cisco Jabber for Windows.

Prerequisites

Requirements

Cisco recommends that you have knowledge of Cisco Jabber for Windows Version 9.x.

Components Used

The information in this document is based on Cisco Jabber for Windows Version 9.x.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Analyze Call Flow in Cisco Jabber for Windows

In order to determine when a call begins and ends in Cisco Jabber for Windows, open the csf-unified.log file in Notepad++, and search for CALL_EVENT. In order to find the first line of a call, locate Initial shortly after the CALL_EVENT statement:

2013-02-24 18:22:07,362 INFO  [0x000009e4][control\CallControlManagerImpl.cpp(2021)]
 [csf.ecc.evt] [ecc::CallControlManagerImpl::notifyCallEventObservers] - 
  CALL_EVENT: evCreated,
 0x005B1818, Initial, CC_ATTR_NOT_DEFINED, CC_CALL_TYPE_NONE, CalledPartyNumber: , 
  CallingPartyNumber: ,
 CallInstance: -1, Status: , GCID: , IsConference: 0, IsCallSelected: 0, CapabilitySet:

Jabber Log Terms

Watch for these keywords in the Jabber call flow:

Call State

  • Initial  -  The call is in setup, Jabber determines if it is incoming/outgoing, and the calling/called phone numbers are prepped.
  • OffHook  -  The Jabber phone goes off hook.
  • Dialing  -  The called phone number digits are dialed.
  • Proceed  -  The digits are passed to Cisco Unified Communications Manager (CUCM) and processed.
  • RingOut  -  The number is dialed and a ring is sent to the remote end.
  • Connected  -  The remote end is answered and the connection is established.
  • OnHook  -  The Jabber phone has hung up.

CC_CALL_TYPE  -  This changes from "NONE" after initialization to either "OUTGOING" or "INCOMING," which depends on whether the call is sent or received.

Call ID  -  The hexadecimal number (0x005B1818) before the Call State is the Jabber Call ID, which stays consistent for the duration of each call. It increments when the next call occurs.

The CSF-UNIFIED.LOG

If you use Notepad++, you can use the Find All in Current Document option, which displays the entire call flow. It looks like this (for viewer ease, the timestamps and informational brackets are removed):

CALL_EVENT: evCreated, 0x005B1818, Initial, CC_ATTR_NOT_DEFINED, CC_CALL_TYPE_NONE,
 CalledPartyNumber: , CallingPartyNumber: , CallInstance: -1, Status: ,
 GCID: , IsConference: 0,
 IsCallSelected: 0, CapabilitySet:

CALL_EVENT: evInfoChanged, 0x005B1818, Initial, CC_ATTR_NOT_DEFINED, CC_CALL_TYPE_OUTGOING,
 CalledPartyNumber: , CallingPartyNumber: , CallInstance: 1, Status: ,
 GCID: , IsConference: 0,
 IsCallSelected: 0, CapabilitySet: canOriginateCall,canDialVoicemail

CALL_EVENT: evInfoChanged, 0x005B1818, Initial, CC_ATTR_NOT_DEFINED, CC_CALL_TYPE_OUTGOING,
 CalledPartyNumber: 1001, CallingPartyNumber: 1000, CallInstance: 1, Status: ,
 GCID: , IsConference:
 0, IsCallSelected: 0, CapabilitySet: canOriginateCall,canDialVoicemail

CALL_EVENT: evStateChanged, 0x005B1818, OffHook, CC_ATTR_NOT_DEFINED, CC_CALL_TYPE_OUTGOING,
 CalledPartyNumber: 1001, CallingPartyNumber: 1000, CallInstance: 1, Status: ,
 GCID: , IsConference:
 0, IsCallSelected: 0, CapabilitySet: canEndCall,canSendDigit

CALL_EVENT: evStateChanged, 0x005B1818, Dialing, CC_ATTR_NOT_DEFINED, CC_CALL_TYPE_OUTGOING,
 CalledPartyNumber: 1001, CallingPartyNumber: 1000, CallInstance: 1, Status: ,
 GCID: , IsConference:
 0, IsCallSelected: 0, CapabilitySet: canEndCall,canSendDigit

CALL_EVENT: evStateChanged, 0x005B1818, Proceed, CC_ATTR_NOT_DEFINED, CC_CALL_TYPE_OUTGOING,
 CalledPartyNumber: 1001, CallingPartyNumber: 1000, CallInstance: 1, Status: ,
 GCID: , IsConference:
 0, IsCallSelected: 0, CapabilitySet: canEndCall

CALL_EVENT: evStateChanged, 0x005B1818, RingOut, CC_ATTR_NOT_DEFINED, CC_CALL_TYPE_OUTGOING,
 CalledPartyNumber: 1001, CallingPartyNumber: 1000, CallInstance: 1, Status: ,
 GCID: , IsConference:
 0, IsCallSelected: 0, CapabilitySet: canEndCall,canDirectTransfer

CALL_EVENT: evCallStarted, 0x005B1818, Connected, CC_ATTR_NOT_DEFINED, CC_CALL_TYPE_OUTGOING,
 CalledPartyNumber: 1001, CallingPartyNumber: 1000, CallInstance: 1, Status: ,
 GCID: , IsConference:
 0, IsCallSelected: 0, CapabilitySet: canHold,canEndCall,canSendDigit,canCallPark,
 canDirectTransfer,
 canJoinAcrossLine

CALL_EVENT: evStateChanged, 0x005B1818, OnHook, CC_ATTR_NOT_DEFINED, CC_CALL_TYPE_OUTGOING,
 CalledPartyNumber: 1001, CallingPartyNumber: 1000, CallInstance: 1, Status: ,
 GCID: , IsConference:
 0, IsCallSelected: 0, CapabilitySet:

CALL_EVENT: evDestroyed, 0x005B1818, OnHook, CC_ATTR_NOT_DEFINED, CC_CALL_TYPE_OUTGOING,
 CalledPartyNumber: , CallingPartyNumber: , CallInstance: 1, Status: ,
 GCID: , IsConference:
 0, IsCallSelected: 0, CapabilitySet:

The output displays when Jabber first goes offhook and dials, as well as the Calling Party and Called Party numbers. For calls that are INCOMING,  a similar call flow pattern is seen. However, the CC_CALL_TYPE is different:

2013-02-24 18:22:07,130 INFO  [0x00000ec0] [control\CallControlManagerImpl.cpp(2001)]
 [csf.ecc.evt][ecc::CallControlManagerImpl::notifyCallEventObservers] - 
 CALL_EVENT: evCreated, 0x10003, Initial,
 CC_ATTR_NORMAL, CC_CALL_TYPE_INCOMING, CalledPartyNumber: 1001, 
 CallingPartyNumber: 1000,
 CallInstance: 1, Status: , GCID: , IsConference: 0, IsCallSelected: 0, CapabilitySet:

Office Integration (Click to Call in Jabber Logs)

For calls made from Microsoft Office Integration, one extra line is added before the call flow. If you search for "Starting voice call with," it provides every point in the log where a Click to Call function is performed. For example, a call from Microsoft Outlook on a contact (Right-Click and Call) looks like this:

2013-02-24 18:42:18,912 INFO  [0x000009e0] [\ExtensionProviderFunctionsImpl.cpp(235)] 
[cuc-extension-provider] [StartVoiceCallImpl2] - Starting voice call with 1001

A few milliseconds later, the same "Initial" keyword begins:

2013-02-24 18:42:18,915 INFO  [0x0000053c] [control\CallControlManagerImpl.cpp(2021)]
 [csf.ecc.evt][ecc::CallControlManagerImpl::notifyCallEventObservers] - 
 CALL_EVENT: evCreated, 0x00EF3BA0,Initial, CC_ATTR_NOT_DEFINED, CC_CALL_TYPE_NONE, 
 CalledPartyNumber: , CallingPartyNumber: ,
 CallInstance: -1, Status: , GCID: , IsConference: 0, IsCallSelected: 0, CapabilitySet:

Notice the [cuc-extension-provider] section in the Click to Call function. If you search for this in the Jabber log, it also provides any results carried from Microsoft Office Integration.

Related Information

TAC Authored

Contributed by Cisco Engineers

  • Billy Turnbow, Amit Kumar, and Jasmeet Sandhu
    Cisco TAC Engineers.

Was this Document Helpful?

FeedbackFeedback

Contact Cisco

This Document Applies to These Products