Cisco SCCP: "Skinny" | Signaling Protocols in Detail

Cisco has a proprietary Skinny Client Control Protocol (SCCP), which is used by the Cisco Unified Communications Manager and Cisco phones as their own signaling protocol. SCCP requires the Cisco Unified Communications Manager or open-source PBXs to operate. Given the downside of proprietary protocols, the main reason for discussing SCCP within the context of voice mobility is only that Cisco's Wi-Fi-only handsets support SCCP, and so SCCP may be seen in some voice mobility networks. Unfortunately, SCCP internal documentation is not widely available or as well understood as an open protocol is, and so enterprise-grade implementations tend to lock the user into one vendor only.

SCCP runs on TCP, using port 2000. The design goal of SCCP was to keep it "skinny," to allow the phone to have as little intelligence as needed. In this sense, the Cisco Unified Communications Manager (or older Cisco Call Manager) is designed to interface with other telephone technologies as a proxy, leaving the phone to deal with supporting the one proprietary protocol.

SCCP has a markedly different architecture from what we have seen already. SCCP is still an IP-based protocol, and there is the one point of contact that the phone uses for all of its signaling. However, the signaling design of SCCP has the remarkable property, unlike with SIP or H.323, that the phone is not self-contained as an extension. Rather, SCCP is entirely user event—based. The phone's job is to report back to the call manager, in real time, whenever a button is pressed. The call manager then pushes down to the phone any change in state that should accompany the button press. In this way, the entire logic as to what buttons mean is contained in the call manager, which locally runs the various telephone endpoint logic. In this way, SCCP has more in common with Remote Desktop than it has with telephone signaling protocols: the phone's logic really runs in some centralized terminal server, which is called the call manager. To emphasize this point, Table 1 lists a typical sequence of events between a phone and a call manager, from when the phone is taken off the hook.

Table 1: Example SCCP Call Setup Event Flow 

#	Direction	Event Name	State	Meaning
1	Phone → Call Manager	Offhook	Dialing	User has taken the phone off the hook.
2	Call Manager → Phone	StationOutputDisplayText		Displays a prompt that the phone is off hook and waiting for digits.
3	Call Manager → Phone	SetRinger		Turns off the ringer.
4	Call Manager → Phone	SetLamp		Turns on the light for the line that is being used.
5	Call Manager → Phone	CallState		Sets the phone up so that the user can hear audio and press buttons.
6	Call Manager → Phone	DisplayPromptStatus		The phone is not connected to any other extension yet.
7	Call Manager → Phone	SelectSoftKeys
8	Call Manager → Phone	ActivateCallPlane
9	Call Manager → Phone	StartTone		Starts a dial tone.
10	Phone → Call Manager	KeypadButton (dialed 7)		The user dialed the number 7.
11	Call Manager → Phone	StopTone		Stops the dial tone, acknowledging that a digit has been dialed.
12	Call Manager → Phone	SelectSoftKeys		Changes the keys of interest to just the number pad (no redial buttons, etc.).
13	Phone → Call Manager	KeypadButton (dialed 0)		The user dialed the number 0.
14	Phone → Call Manager	KeypadButton (dialed 2)		The user dialed the number 2.
15	Phone → Call Manager	KeypadButton (dialed 0)		The user dialed the number 0.
16	Call Manager → Phone	SelectSoftKeys	Ringing	Changes the keys of interest.
17	Call Manager → Phone	CallState		Changes the state of the phone.
18	Call Manager → Phone	Callinfo
19	Call Manager → Phone	DialedNumber		Reports that 7020 has been dialed.
20	Call Manager → Phone	StartTone		Starts playing a ringback tone.
21	Call Manager → Phone	DisplayPromptStatus		Changes the prompt to show that the other side of the phone is ringing.
22	Call Manager → Phone	Callinfo		The call is still ringing.
23	Call Manager → Phone	StopTone	Connected	Stops playing the ringback tone.
24	Call Manager → Phone	DisplayPromptStatus		Displays that the phone call was answered.
25	Call Manager → Phone	OpenReceiveChannel		Prepares for the downward leg of the call.
26	Phone → Call Manager	OpenReceiveChannelAck		Acknowledges the downward leg.
27	Call Manager → Phone	StartMediaTransmission		The call's bearer channel starts flowing.
28	Phone → Call Manager	OnHook	Hanging Up	The caller hung up.
29	Call Manager → Phone	CloseReceiveChannel		Tears down the receive leg.
30	Call Manager → Phone	StopMediaTransmission		Stops the bearer channel entirely.
31	Call Manager → Phone	SetSpeakerMode		Restores the phone to the original state.
32	Call Manager → Phone	ClearPromptStatus
33	Call Manager → Phone	CallState
34	Call Manager → Phone	DisplayPromptStatus
35	Call Manager → Phone	ActivateCallPlane
36	Call Manager → Phone	SetLamp		Turns off the light for the line that was in use.

As you can see, the phone's entire personality—the meaning of the buttons, what the display states, which lights are lit, the tones generated—are entirely controlled by the call manager.

Overall, this is a marked difference from true telephone signaling protocols. In this sense, then, one can consider SCCP to be mostly a remote control protocol for phones, and the call manager is thus left with the burden of implementing the true telephone protocol. Unfortunately, however, when SCCP is used with a packet-based voice mobility network, the protocol going over the wireless or edge network is going to be SCCP, and not whatever protocol the call manager is enabled with.

Bearer traffic, on the other hand, still uses RTP, as do the other protocols we have looked at so far. Therefore, most of the discussion on bearer traffic, and on voice traffic in general, holds for SCCP networks.