Troubleshooting Guide for Cisco CallManager, Release 3.3(3) - Case Study: Troubleshooting Intracluster Phone Calls [Cisco Unified Communications Manager (CallManager)]

Table Of Contents

Case Study: Troubleshooting Intracluster Phone Calls

Sample Topology

Cisco IP Phone Initialization Process

Skinny Station Registration Process

Cisco IP Phone-to-Cisco IP Phone Call Flow Within a Cluster

Cisco IP Phone-to-Cisco IP Phone Exchange of Skinny Station Messages During Call Flow

Cisco CallManager Initialization Process

Self-Starting Processes

Cisco CallManager Registration Process

Cisco CallManager KeepAlive Process

Cisco CallManager Intracluster Call Flow Traces

Case Study: Troubleshooting Intracluster Phone Calls

The case study in this appendix discusses in detail the call flow between two Cisco IP Phones within a cluster, called an intracluster call. This case study also focuses on Cisco CallManager and Cisco IP Phone initialization, registration, and keepalive processes. A detailed explanation of an intracluster call flow follows the discussion. The explanation of the processes are explained using the trace utilities and tools discussed in "Troubleshooting Tools".

This appendix contains the following topics:

•Sample Topology

•Cisco IP Phone Initialization Process

•Skinny Station Registration Process

•Cisco IP Phone-to-Cisco IP Phone Call Flow Within a Cluster

•Cisco IP Phone-to-Cisco IP Phone Exchange of Skinny Station Messages During Call Flow

•Cisco CallManager Initialization Process

•Self-Starting Processes

•Cisco CallManager Registration Process

•Cisco CallManager KeepAlive Process

•Cisco CallManager Intracluster Call Flow Traces

Sample Topology

Given that you have two clusters named Cluster 1 and Cluster 2, the two Cisco CallManagers in Cluster 1 are called CCM3 and CCM4, while the two Cisco CallManagers in Cluster 2 are called CCM1 and CCM2.

The traces collected for this case study come from CCM1, which is located in Cluster 2, as shown in Figure B-1. The basis for the call flow are the two Cisco IP Phones in Cluster 2. The IP addresses of these two Cisco IP Phones are 172.16.70.230 (directory number 1000) and 172.16.70.231 (directory number 1001), respectively.

Figure B-1 Sample Topology of Intra-Cluster Cisco IP Phone-to-Cisco IP Phone Calls

Cisco IP Phone Initialization Process

The following procedure explains in detail the Cisco IP Phone initialization (or boot up) process.

Procedure

Step 1 If you have set the appropriate options in DHCP server (such as Option 066 or Option 150), the Cisco IP Phone sends a request, at initialization to the DHCP server to get an IP address, Domain Name System (DNS) server address, and TFTP server name or address. It also gets a default gateway address if you have set these options in the DHCP server (Option 003).

Step 2 If a DNS name of the TFTP sever is sent by DHCP, you need a DNS server IP address to map the name to an IP address. Bypass this step if the DHCP server sends the IP address of the TFTP server. In this case study, the DHCP server sent the IP address of TFTP because DNS was not configured.

Step 3 If a TFTP server name is not included in the DHCP reply, the Cisco IP Phone uses the default server name.

Step 4 The configuration file (.cnf) file gets retrieved from the TFTP server. All .cnf files have the name SEP<mac_address>.cnf. If this is the first time the phone is registering with the Cisco CallManager, a default file, SEPdefault.cnf, gets downloaded to the Cisco IP Phone. In this case study, the first Cisco IP Phone uses the IP address 172.16.70.230 (its MAC address is SEP0010EB001720), and the second Cisco IP Phone uses the IP address 172.16.70.231 (its MAC address is SEP003094C26105).

Step 5 All .cnf files include the IP address(es) for the primary and secondary Cisco CallManager(s). The Cisco IP Phone uses this IP address to contact the primary Cisco CallManager and to register.

Step 6 Once the Cisco IP Phone connects and registers with Cisco CallManager, the Cisco CallManager tells the Cisco IP Phone which executable version (called a load ID) to run. If the specified version does not match the executing version on the Cisco IP Phone, the Cisco IP Phone will request the new executable from the TFTP server and reset automatically

Skinny Station Registration Process

Cisco IP Phones communicate with the Cisco CallManager by using the Cisco Skinny Station Protocol. The registration process allows a Skinny Station, such as the Cisco IP Phone, to inform the Cisco CallManager of its existence and to make calling possible. Figure B-2 provides a sample of this process.

Figure B-2 Skinny Client Registration Sequence

With the advent of the Cisco IP Phone 7960 and 7940 phone sets, the registration process increased in complexity. Figure B-3 illustrates the registration and initialization sequence for this telephone set.

Figure B-3 Cisco IP Phone 7960 or 7940 Registration and Initialization

Table B-1 describes the primary messages in the Skinny Station registration process.

Table B-1 Skinny Station Registration Process Descriptions

Message

Description

Station Register

The station sends this message to announce its existence to the controlling Cisco CallManager.

Station Reset

Cisco CallManager sends this message to command the station to reset its processes.

Station IP Port

The station sends this message to provide Cisco CallManager with the User Datagram Protocol (UDP) port to be used with the Real-Time Protocol (RTP) stream.

Station Register Acknowledge

Cisco CallManager sends this message to acknowledge the registration of a station.

Station Register Reject

Cisco CallManager sends this message to reject a registration attempt from the indicated phone.
char text [StationMaxDisplayTextSize];
};

Where:
text represents a character string, maximum length of 33 bytes, containing a textual description of the reason that registration is rejected.

Station Capabilities Request

Cisco CallManager sends this message to request the current capabilities of the station. Station capabilities may include compression standard and other H.323 capabilities.

Station Version Request

The station sends this message to request the version number of the software load for the station.

Station Version Response

Cisco CallManager sends this message to inform the station of the appropriate software version number.

Station Capabilities Response

The station sends this message to the Cisco CallManager in response to a Station Capabilities Request. The Cisco CallManager caches the station's capabilities and uses them to negotiate terminal capabilities with an H.323 compliant terminal.

Station Button Template Request

The station sends this message to request the button template definition for that specific terminal or Cisco IP Phone.

Station Button Template Response

Cisco CallManager sends this message to update the button template information that is contained in the station.

Station Time Date Request

The station sends this message to request the current date and time for internal usage and for displaying as a text string.

Station Define Time and Date

Cisco CallManager uses this message to provide the date and time information to the station. It provides time synchronization for the stations.

Cisco IP Phone-to-Cisco IP Phone Call Flow Within a Cluster

This section describes a Cisco IP Phone (directory number 1000) calling another Cisco IP Phone (directory number 1001) within the same cluster. The cluster represents a group of Cisco CallManagers having one common Publisher Structured Query Language (SQL) database and many Subscriber SQL databases.

In this cluster scenario, CCM1 identifies the publisher, and CCM2 identifies a subscriber. The two Cisco IP Phones (1000 and 1001) are registered to CCM1 and CCM2, respectively. The two Cisco CallManagers within a cluster communicate with each other using Intracluster Control Protocol (ICCP).

When a Cisco IP Phone goes off hook, it opens a control Skinny Station session (with TCP as the underlying protocol) with the Cisco CallManager. After call control signaling is established between the two Cisco IP Phones and their respective Cisco CallManagers, the RTP stream starts flowing directly between the two phones, as shown in Figure B-4. The next section provides an explanation of the Skinny Station call flow messages for this intracluster call.

Figure B-4 RTP Stream Between Phones 1000 and 1001

Cisco IP Phone-to-Cisco IP Phone Exchange of Skinny Station Messages During Call Flow

The Skinny Station, in this case a Cisco IP Phone, initiates a connection to the Cisco CallManager and then Cisco CallManager performs digit analysis before opening a control session with the destination Skinny Station.

Note The Skinny Station messages, written in English, can be understood by end users. Therefore, this section does not explain these messages. However, later sections explain the call flow Skinny Station messages when traces are being examined.

Figure B-5 shows a sample exchange of messages between two Skinny Clients.

Figure B-5 Skinny Client to Skinny Client Call Signaling

Cisco CallManager Initialization Process

This section explains the initialization process of Cisco CallManager with the help of traces that are captured from CCM1 (identified by the IP address 172.16.70.228). As described previously, SDI traces provide a very effective troubleshooting tool because they detail every packet sent between endpoints.

This section describes the events that occur when Cisco CallManager is initialized. Understanding how to read traces will help you to properly troubleshoot the various Cisco CallManager processes and the effect of those processes on services such as conferencing and call forwarding.

The following messages from the Cisco CallManager SDI trace utility show the initialization process on one of the Cisco CallManagers, in this case, CCM1.

•The first message indicates that Cisco CallManager started its initialization process.

•The second message indicates that Cisco CallManager read the default database values (for this case, it is the primary or publisher database).

•The third message indicates Cisco CallManager received the various messages on TCP port 8002.

•The fourth message shows that, after receiving to these messages, Cisco CallManager added a second Cisco CallManager to its list: CCM2 (172.16.70.229).

•The fifth message indicates that Cisco CallManager has started and is running Cisco CallManager version 3.1(1).
16:02:47.765 CCM|CMProcMon - CallManagerState Changed - Initialization 
Started.
16:02:47.796 CCM|NodeId:  0, EventId: 107 EventClass: 3 EventInfo: 
Cisco CM Database Defaults Read
16:02:49.937 CCM| SDL Info - NodeId: [1], Listen IP/Hostname: 
[172.16.70.228], Listen Port: [8002]
16:02:49.984 CCM|dBProcs - Adding SdlLink to NodeId: [2], IP/Hostname: 
[172.16.70.229]
16:02:51.031 CCM|NodeId:  1, EventId:  1 EventClass:  3 EventInfo: 
Cisco CallManager Version=<3.1(1)> started
Self-Starting Processes

Once Cisco CallManager is up and running, it starts several other processes within itself. Some of these processes follow, including MulticastPoint Manager, UnicastBridge Manager, digit analysis, and route list. You will find the messages described during these processes very useful when you are troubleshooting a problem related to the features in Cisco CallManager.

For example, assume that the route lists are not functioning and are unusable. To troubleshoot this problem, you would monitor these traces to determine whether the Cisco CallManager has started RoutePlanManager and if it is trying to load the RouteLists. The sample configuration below shows that RouteListName=''ipwan'' and RouteGroupName=''ipwan'' are loading and starting.
16:02:51.031 CCM|MulicastPointManager - Started
16:02:51.031 CCM|UnicastBridgeManager - Started
16:02:51.031 CCM|MediaTerminationPointManager - Started
16:02:51.125 CCM|MediaCoordinator(1) - started
16:02:51.125 CCM|NodeId:    1, EventId: 1543 EventClass:  2 EventInfo: 
Database manager started
16:02:51.234 CCM|NodeId:    1, EventId: 1542 EventClass:  2 EventInfo: 
Link manager started
16:02:51.390 CCM|NodeId:    1, EventId: 1541 EventClass:  2 EventInfo: 
Digit analysis started
16:02:51.406 CCM|RoutePlanManager - Started, loading RouteLists
16:02:51.562 CCM|RoutePlanManager - finished loading RouteLists
16:02:51.671 CCM|RoutePlanManager - finished loading RouteGroups
16:02:51.671 CCM|RoutePlanManager - Displaying Resulting RoutePlan
16:02:51.671 CCM|RoutePlanServer - RouteList Info, by RouteList and 
RouteGroup Selection Order
16:02:51.671 CCM|RouteList - RouteListName=''ipwan''
16:02:51.671 CCM|RouteList - RouteGroupName=''ipwan''
16:02:51.671 CCM|RoutePlanServer - RouteGroup Info, by RouteGroup and 
Device Selection Order
16:02:51.671 CCM|RouteGroup - RouteGroupName=''ipwan''
The following trace shows the RouteGroup adding the device 172.16.70.245, which is CCM3 located in Cluster 1 and is considered an H.323 device. In this case, the RouteGroup is created to route calls to CCM3 in Cluster 1 with Cisco IOS Gatekeeper permission. If a problem occurs while routing the call to a Cisco IP Phone located in Cluster 1, the following messages would help you find the cause of the problem.
16:02:51.671 CCM|RouteGroup - DeviceName=''172.16.70.245''
16:02:51.671 CCM|RouteGroup -AllPorts
Part of the initialization process shows that Cisco CallManager is adding "Dns" (Directory Numbers). By reviewing these messages, you can determine whether the Cisco CallManager has read the directory number from the database.
16:02:51.671 CCM|NodeId:    1, EventId: 1540 EventClass:  2 EventInfo: 
Call control started
16:02:51.843 CCM|ProcessDb -        Dn = 2XXX,      Line = 0,    
Display = ,  RouteThisPattern, NetworkLocation = OffNet,  
DigitDiscardingInstruction = 1,   WhereClause = 
16:02:51.859 CCM|Digit analysis: Add local pattern 2XXX , PID: 1,80,1
16:02:51.859 CCM|ForwardManager - Started
16:02:51.984 CCM|CallParkManager - Started
16:02:52.046 CCM|ConferenceManager - Started
In the following traces, the Device Manager in Cisco CallManager statically initializes two devices. The device with IP address 172.17.70.226 represents a gatekeeper, and the device with IP address 172.17.70.245 gets another Cisco CallManager in a different cluster. That Cisco CallManager gets registered as an H.323 Gateway with this Cisco CallManager.
16:02:52.250 CCM|DeviceManager: Statically Initializing Device;  
DeviceName=172.16.70.226
16:02:52.250 CCM|DeviceManager: Statically Initializing Device;  
DeviceName=172.16.70.245
Cisco CallManager Registration Process

Another important part of the SDI trace involves the registration process. When a device is powered up, it gets information via DHCP, connects to the TFTP server for its .cnf file, and then connects to the Cisco CallManager that is specified in the .cnf file. The device could be an MGCP gateway, a Skinny gateway, or a Cisco IP Phone. Therefore, you need to be able to discover whether devices have successfully registered on the Cisco AVVID network.

In the following trace, Cisco CallManager has received new connections for registration. The registering devices are MTP_nsa-cm1 (MTP services on CCM1), and CFB_nsa-cm1 (Conference Bridge service on CCM1). Although these are software services that are running on Cisco CallManager, they get treated internally as different external services and therefore get assigned a TCPHandle, socket number, and port number as well as a device name.
16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, 
TCPHandle=0x4fbaa00, Socket=0x594, IPAddr=172.16.70.228, Port=3279, 
StationD=[0,0,0]
16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, 
TCPHandle=0x4fe05e8, Socket=0x59c, IPAddr=172.16.70.228, Port=3280, 
StationD=[0,0,0]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 
DeviceName=MTP_nsa-cm1, TCPHandle=0x4fbaa00, Socket=0x594, 
IPAddr=172.16.70.228, Port=3279, StationD=[1,45,2]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 
DeviceName=CFB_nsa-cm1, TCPHandle=0x4fe05e8, Socket=0x59c, 
IPAddr=172.16.70.228, Port=3280, StationD=[1,96,2]
In the following trace, Skinny Station messages get sent between a Cisco IP Phone and Cisco CallManager. The Cisco IP Phone (172.16.70.231) is registering with Cisco CallManager. Table B-1 provides the descriptions of Skinny Station messages. As soon as Cisco CallManager receives the registration request from a Cisco IP Phone, it assigns a TCPHandle number to this device. This number remains the same until the device or Cisco CallManager is restarted. Therefore, you can follow all the events related to a particular device by searching for or keeping track of the device TCPHandle number, which appears in hexidecimal notation. Also, notice that Cisco CallManager provides the load ID to the Cisco IP Phone. Based on this load ID, the Cisco IP Phone runs the executable file (acquired from the TFTP server) that corresponds to the device.
16:02:57.000 CCM|StationInit - New connection accepted. DeviceName=, 
TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, 
StationD=[0,0,0]
16:02:57.046 CCM|NodeId:    1, EventId: 1703 EventClass:  2 EventInfo: 
Station Alarm, TCP Handle: 4fbbc30, Text: Name=SEP003094C26105  
Load=AJ.30  Parms=Status/IPaddr LastTime=A P1: 2304(900) P2: 
-414838612(e74610ac)
16:02:57.046 CCM|StationInit - ***** InboundStim - AlarmMessageID 
tcpHandle=0x4fbbc30 Message="Name=SEP003094C26105  Load=AJ.30  
Parms=Status/IPaddr LastTime=A" Parm1=2304 (900) Parm2=-414838612 
(e74610ac)
16:02:57.093 CCM|StationInit - Processing StationReg. regCount: 1 
DeviceName=SEP003094C26105, TCPHandle=0x4fbbc30, Socket=0x5a4, 
IPAddr=172.16.70.231, Port=52095, StationD=[1,85,1]
16:02:57.093 CCM|StationInit - InboundStim - IpPortMessageID: 
32715(0x7fcb) tcpHandle=0x4fbbc30
Cisco CallManager KeepAlive Process

The station, device, or service and the Cisco CallManager use the following messages to maintain a knowledge of the communications channel between them. The messages begin the KeepAlive sequence that ensures that the communications link between the Cisco CallManager and the station remains active. The following messages can originate from either the Cisco CallManager or the station.
16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - 
Forward KeepAlive to StationD. DeviceName=MTP_nsa-cm2, 
TCPHandle=0x4fa7dc0, Socket=0x568, IPAddr=172.16.70.229, Port=1556, 
StationD=[1,45,1]
16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - 
Forward KeepAlive to StationD. DeviceName=CFB_nsa-cm2, 
TCPHandle=0x4bf8a70, Socket=0x57c, IPAddr=172.16.70.229, Port=1557, 
StationD=[1,96,1]
16:03:06.640 CCM|StationInit - InboundStim - KeepAliveMessage - 
Forward KeepAlive to StationD. DeviceName=SEP0010EB001720, 
TCPHandle=0x4fbb150, Socket=0x600, IPAddr=172.16.70.230, Port=49211, 
StationD=[1,85,2]
16:03:06.703 CCM|StationInit - InboundStim - KeepAliveMessage - 
Forward KeepAlive to StationD. DeviceName=SEP003094C26105, 
TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, 
StationD=[1,85,1]
The messages in the following trace depict the KeepAlive sequence that indicates that the communications link between the Cisco CallManager and the station is active. Again, these messages can originate from either the Cisco CallManager or the station.
16:03:02.328 CCM|MediaTerminationPointControl - 
stationOutputKeepAliveAck tcpHandle=4fa7dc0
16:03:02.328 CCM|UnicastBridgeControl - stationOutputKeepAliveAck 
tcpHandle=4bf8a70
16:03:06.703 CCM|StationInit - InboundStim - IpPortMessageID: 
32715(0x7fcb) tcpHandle=0x4fbbc30
16:03:06.703 CCM|StationD - stationOutputKeepAliveAck 
tcpHandle=0x4fbbc30
Cisco CallManager Intracluster Call Flow Traces

The following SDI traces explore the intracluster call flow in detail. You can identify the Cisco IP Phones in the call flow by the directory number (dn), tcpHandle, and IP address. A Cisco IP Phone (dn: 1001, tcpHandle: 0x4fbbc30, IP address: 172.16.70.231) located in Cluster 2 is calling another Cisco IP Phone in the same Cluster (dn=1000, tcpHandle= 0x4fbb150, IP address= 172.16.70.230). Remember that you can follow a device through the trace by looking at the TCP handle value, time stamp, or name of the device. The TCP handle value for the device remains the same until the device is rebooted or goes offline.

The following traces show that the Cisco IP Phone (1001) has gone off hook. The trace below shows the unique messages, TCP handle, and the called number, which display on the Cisco IP Phone. No calling number appears at this point because the user has not tried to dial any digits. The information below appears in the form of Skinny Station messages between the Cisco IP Phones and the Cisco CallManager.
16:05:41.625 CCM|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x4fbbc30
16:05:41.625 CCM|StationD - stationOutputDisplayText 
tcpHandle=0x4fbbc30, Display= 1001
The next trace shows Skinny Station messages going from Cisco CallManager to a Cisco IP Phone. The first message is to turn on the lamp on the calling party Cisco IP Phone.
16:05:41.625 CCM|StationD - stationOutputSetLamp stim: 9=Line 
instance=1 lampMode=LampOn tcpHandle=0x4fbbc30
Cisco CallManager uses the stationOutputCallState message to notify the station of certain call-related information.
16:05:41.625 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30
Cisco CallManager uses the stationOutputDisplayPromptStatus message to cause a call-related prompt message to display on the Cisco IP Phone.
16:05:41.625 CCM|StationD - stationOutputDisplayPromptStatus 
tcpHandle=0x4fbbc30
Cisco CallManager uses the stationOutputSelectSoftKey message to cause the Skinny Station to choose a specific set of soft keys.
16:05:41.625 CCM|StationD - stationOutputSelectSoftKeys 
tcpHandle=0x4fbbc30
Cisco CallManager uses the next message to instruct the Skinny Station as to the correct line context for the display.
16:05:41.625 CCM|StationD - stationOutputActivateCallPlane 
tcpHandle=0x4fbbc30
In the following message, the digit analysis process is ready to identify incoming digits and check them for potential routing matches in the database. The entry, cn=1001, represents the calling party number where dd="" represents the dialed digit, which would show the called part number. The phone sends StationInit messages, Cisco CallManager sends StationD messages, and Cisco CallManager performs digit analysis.
16:05:41.625 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", 
dd="")
16:05:41.625 CCM|Digit analysis: 
potentialMatches=PotentialMatchesExist
The following debug message shows that the Cisco CallManager is providing inside dial tone to the calling party Cisco IP Phone.
16:05:41.625 CCM|StationD - stationOutputStartTone: 33=InsideDialTone 
tcpHandle=0x4fbbc30
After Cisco CallManager detects an incoming message and recognizes that the keypad button 1 has been pressed on the Cisco IP Phone, it immediately stops the output tone.
16:05:42.890 CCM|StationInit - InboundStim - KeypadButtonMessageID 
kpButton: 1 tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputSelectSoftKeys 
tcpHandle=0x4fbbc30
16:05:42.890 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", 
dd="1")
16:05:42.890 CCM|Digit analysis: 
potentialMatches=PotentialMatchesExist
16:05:43.203 CCM|StationInit - InboundStim - KeypadButtonMessageID 
kpButton: 0 tcpHandle=0x4fbbc30
16:05:43.203 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", 
dd="10")
16:05:43.203 CCM|Digit analysis: 
potentialMatches=PotentialMatchesExist
16:05:43.406 CCM|StationInit - InboundStim - KeypadButtonMessageID 
kpButton: 0 tcpHandle=0x4fbbc30
16:05:43.406 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", 
dd="100")
16:05:43.406 CCM|Digit analysis: 
potentialMatches=PotentialMatchesExist
16:05:43.562 CCM|StationInit - InboundStim - KeypadButtonMessageID 
kpButton: 0 tcpHandle=0x4fbbc30
16:05:43.562 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", 
dd="1000")
After the Cisco CallManager has received enough digits to match, it provides the digit analysis results in a table format. Cisco CallManager ignores any extra digits that are pressed on the phone after this point because a match has already been found.
16:05:43.562 CCM|Digit analysis: analysis results
16:05:43.562 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=1000
|DialingRoutePatternRegularExpression=(1000)
|PotentialMatches=PotentialMatchesExist
|DialingSdlProcessId=(1,38,2)
|PretransformDigitString=1000
|PretransformPositionalMatchList=1000
|CollectedDigits=1000
|PositionalMatchList=1000
|RouteBlockFlag=RouteThisPattern
The next trace shows that Cisco CallManager is sending out this information to a called party phone (the tcpHandle number identifies the phone).
16:05:43.578 CCM|StationD - stationOutputCallInfo 
CallingPartyName=1001,  CallingParty=1001, CalledPartyName=1000, 
CalledParty=1000, tcpHandle=0x4fbb150
The next trace indicates that Cisco CallManager is ordering the lamp to blink for incoming call indication on the called party Cisco IP Phone.
16:05:43.578 CCM|StationD - stationOutputSetLamp stim: 9=Line 
instance=1 lampMode=LampBlink tcpHandle=0x4fbb150
In the following traces, Cisco CallManager provides ringer, display notification, and other call-related information to the called party Cisco IP Phone. Again, you can see that all messages get directed to the same Cisco IP Phone because the same tcpHandle gets used throughout the traces.
16:05:43.578 CCM|StationD - stationOutputSetRinger: 2=InsideRing 
tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayNotify 
tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus 
tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys 
tcpHandle=0x4fbb150
Notice that Cisco CallManager also provides similar information to the calling party Cisco IP Phone. Again, the tcpHandle differentiates between Cisco IP Phones.
16:05:43.578 CCM|StationD - stationOutputCallInfo 
CallingPartyName=1001,  CallingParty=1001, CalledPartyName=, 
CalledParty=1000, tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallInfo 
CallingPartyName=1001,  CallingParty=1001, CalledPartyName=1000, 
CalledParty=1000, tcpHandle=0x4fbbc30
In the next trace, Cisco CallManager provides an alerting or ringing tone to the calling party Cisco IP Phone, notifying that the connection has been established.
16:05:43.578 CCM|StationD - stationOutputStartTone: 36=AlertingTone 
tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys 
tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus 
tcpHandle=0x4fbbc30
At this point, the called party's Cisco IP Phone goes off hook; therefore, Cisco CallManager stops generating the ringer tone to calling party.
16:05:45.140 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30
In the following messages, Cisco CallManager causes the Skinny Station to begin receiving a Unicast RTP stream. To do so, Cisco CallManager provides the IP address of the called party as well as codec information and packet size in msec (milliseconds). PacketSize designates an integer that contains the sampling time, in milliseconds, that is used to create the RTP packets.

Note Normally this value gets set to 30 msec. In this case, it is set to 20 msec.
16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel 
tcpHandle=0x4fbbc30 myIP: e74610ac (172.16.70.231)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
Similarly, Cisco CallManager provides information to the called party (1000).
16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel 
tcpHandle=0x4fbb150 myIP: e64610ac (172.16.70.230)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
Cisco CallManager has received the acknowledgment message from called party for establishing the open channel for RTP stream, as well as the IP address of the called party. This message informs the Cisco CallManager of two pieces of information about the Skinny Station. First, it contains the status of the open action. Second, it contains the receive port address and number for transmission to the remote end. The IP address of the transmitter (calling part) of the RTP stream is ipAddr, and PortNumber is the IP port number of the RTP stream transmitter (calling party).
16:05:45.265 CCM|StationInit - InboundStim - 
StationOpenReceiveChannelAckID tcpHandle=0x4fbb150, Status=0, 
IpAddr=0xe64610ac, Port=17054, PartyID=2
Cisco CallManager uses the following messages to order the station to begin transmitting the audio stream to the indicated remote Cisco IP Phone IP address and port number.
16:05:45.265 CCM|StationD - stationOutputStartMediaTransmission 
tcpHandle=0x4fbbc30 myIP: e74610ac (172.16.70.231)
16:05:45.265 CCM|StationD - RemoteIpAddr: e64610ac (172.16.70.230) 
RemoteRtpPortNumber: 17054 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
In the following traces, the previously explained messages are sent to the called party. The messages that indicate that the RTP media stream has been started between the called and calling party, follow these messages.
16:05:45.312 CCM|StationD - stationOutputStartMediaTransmission 
tcpHandle=0x4fbb150 myIP: e64610ac (172.16.70.230)
16:05:45.328 CCM|StationD - RemoteIpAddr: e74610ac (172.16.70.231) 
RemoteRtpPortNumber: 18448 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID 
tcpHandle=0x4fbbc30
The calling party Cisco IP Phone finally goes on hook, which terminates all the control messages between the Skinny Station and Cisco CallManager as well as the RTP stream between Skinny Stations.
16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID 
tcpHandle=0x4fbbc30