Friday, June 10, 2011

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.

No comments:

Post a Comment