Today we’ll tell you about Cisco Systems’ proprietary protocol named SCCP – Skinny Client Control Protocol. It was created for corporate phone networks based on Cisco products, such as:

• IP Phone series 7900
• Cisco IP Communicator softphones
• Cisco Unified Communications Manager
• Cisco Unity

Notice that there’s another protocol with the same abbreviation: Signaling Connection and Control Protocol (SCCP). However, this protocol belongs to Signaling System №7 (CCSS7), while SCCP (Skinny Client Control Protocol) works in TCP/IP stack.

In VoIP, SCCP occupies the same place as SIP, H.323 and MGCP and performs the same functions. However, unlike all the listed protocols, SCCP has much easier syntax and requires less processing power.

Like most VoIP protocols, SCCP was designed for exchange of signaling messages between client and server during call establishment and call termination.

SCCP doesn’t take part in audio data transfer, there’s another protocol for this purpose: RTP (Real-Time Transport Protocol). It’s also important to note that SCCP doesn’t use RTCP (Real-Time Transport Control Protocol) that transfers diagnostic information about the current connection. SCCP has its own mechanism for this purpose.

As mentioned above, SCCP has very simple syntax. You can easily define the exact status of the current connection by any message header. This makes SCCP very convenient for trouble shooting. The well-known TCP (Transmission Control Protocol) port 2000 is used for SCCP messages transmission.

A connection via SCCP can’t be discussed without a server (usually CUCM). SCCP has a great number of messages to be sent to server for every single reason in order to get a guide to action. It looks like this:

• IP Phone: StationInit: Someone picked up the receiver
• Server: StationD: Turn on the buzzer
• Server: StationD: Show “Enter the phone number” message on the screen
• IP Phone: StationInit: Beginning to call the subscriber, the first digit of the number is “4”
• IP Phone: StationInit: The second digit is “7”

Each event is being registered until the server receives a message saying the receiver has been hung up.

Notice that SCCP messages are being sent to client and server both, so there are identifiers that define the message source: StationInit if client is the source; StationIniD if server is the source. So, any call performed inside a corporate network can be traced in detail.

Here’s an example of some SCCP messages:

• 0x0000 - Keep Alive Message – a message sent from server to client immediately after the registration
• 0x0001 - Station Register Message – a request for registration on server
• 0x0002 - Station IP Port Message – UDP port number for an RTP session (sent by a client)
• 0x0006 - Station Off Hook Message – a phone picked up (sent by a client)
• 0x0099 - Station Display Text Message – shows “Enter the number” message on the screen
• 0x0082 - Station Start Tone Message – turns the buzzer on
• 0x27 - Station Soft Key Event Message (new call/end call) – if it's the start of a call, this message contains the first digit of the subscriber’s number. It can also contain middle digits and a request to drop the connection (call end)
• 0x107 - Station Connection Statistics Request Message – a request for diagnostic information (delays, media packet loss, jitter buffer, accepted and sent packets, etc.) sent by a client. This mechanism makes up for the RTCP absence

You can see that each MessageID describes the corresponding event, so reading SCCP traces is usually a straightforward process.

It’s also important to note that some voice solutions developing companies, such as Digium, SocketIP and Symbol Technologies, have added SCCP support in their products.