Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

SCCP ALG

 

The Skinny Client Control Protocol (SCCP) is a simple and lightweight protocol requiring relatively little computer processing. SCCP clients use TCP/IP to communicate with Call Manager applications in a cluster.

Understanding SCCP ALGs

Skinny Client Control Protocol (SCCP) is a Cisco proprietary protocol for call signaling. Skinny is based on a call-agent-based call-control architecture. The control protocol uses binary-coded frames encoded on TCP frames sent to well-known TCP port number destinations to set up and tear down RTP media sessions.

The SCCP protocol, in the same way as other call control protocols, negotiates media endpoint parameters—specifically the Real-Time Transport Protocol (RTP) port number and the IP address of media termination—by embedding information in the control packets. The SCCP Application Layer Gateway (ALG) parses these control packets and facilitates media and control packets to flow through the system.

The SCCP ALG also implements rate limiting of calls and helps protect critical resources from overloading and denial-of-service (DoS) attacks.

The following functions are implemented by the SCCP ALG in Junos OS:

  • Validation of SCCP protocol data units

  • Translation of embedded IP address and port numbers

  • Allocation of firewall resources (pinholes and gates) to pass media

  • Aging out idle calls

  • Configuration API for SCCP ALG parameters

  • Operational mode API for displaying counters, status and statistics

In the SCCP architecture, a proxy, known as the Call Manager, does most of the processing. IP phones, also called End Stations, run the SCCP client and connect to a primary (and, if available, a secondary) Call Manager over TCP on port 2000 and register with the primary Call Manager. This connection is then used to establish calls coming to or from the client.

The SCCP ALG supports the following:

  • Call flow from a SCCP client, through the Call Manager, to another SCCP client.

  • Seamless failover—Switches over all calls in process to the standby firewall during failure of the primary.

  • Voice-over-IP (VoIP) signaling payload inspection—Fully inspects the payload of incoming VoIP signaling packets. Any malformed packet attack is blocked by the ALG.

  • SCCP signaling payload inspection—Fully inspects the payload of incoming SCCP signaling packets. Any malformed-packet attack is blocked by the ALG.

  • Stateful processing—Invokes the corresponding VoIP-based state machines to process the parsed information. Any out-of-state or out-of-transaction packet is identified and properly handled.

  • Network Address Translation (NAT)—Translates any embedded IP address and port information in the payload, based on the existing routing information and network topology, with the translated IP address and port number, if necessary.

  • Pinhole creation and management for VoIP traffic—Identifies IP address and port information used for media or signaling and dynamically opens (and closes) pinholes to securely stream the media.

This topic includes the following sections:

SCCP Security

The SCCP ALG includes the following security features:

  • Stateful inspection of SCCP control messages over TCP and validation of the message format, and message validity for the current call state. Invalid messages are dropped.

  • Security policy enforcement between Cisco IP phones and Cisco Call Manager.

  • Protect against call flooding by rate limiting the number of calls processed by the ALG.

  • Seamless failover of calls, including the ones in progress in case of device failure in a clustered deployment.

SCCP Components

The principal components of the SCCP VoIP architecture include the following:

SCCP Client

The SCCP client runs on an IP phone, also called an End Station, which uses SCCP for signaling and for making calls. For an SCCP client to make a call, it must first register with a Primary Call Manager (and a secondary, if available). The connection between the client and the Call Manager is over TCP on port 2000. This connection is then used to establish calls to or from the client. Transmission of media is over RTP, UDP, and IP.

Call Manager

The Call Manager implements SCCP call control server software and has overall control of all devices and communication in the SCCP VoIP network. Its functions include defining, monitoring and controlling SCCP groups, regions of numbers, and route plans; providing initialization, admission, and registration of devices on the network; providing a redundant database that contains addresses, phone numbers, and number formats; and initiating contact with called devices or their agents to establish logical sessions in which voice communication can flow.

Cluster

A cluster is a collection of SCCP clients and a Call Manager. The Call Manager in the cluster detects all SCCP clients in the cluster. There can be more than one Call Manager for backup in a cluster. Call Manager behavior varies in each of the following cluster scenarios:

  • Intra-Cluster, in which the Call Manager detects each SCCP client, and the call is between SCCP clients of the same cluster.

  • Inter-Cluster, in which the Call Manager needs to communicate with another Call Manager using H.323 for call setup.

  • Inter-Cluster calls using the gatekeeper for admission control and address resolution.

    Call Manager behavior also varies with calls between an SCCP client and a phone in a public switched telephone network (PSTN), and with calls between an SCCP client and a phone in another administrative domain that is using H.323.

SCCP Transactions

SCCP transactions are the processes that need to take place in order for an SCCP call to proceed. SCCP transactions include the following processes:

Client Initialization

To initialize, the SCCP client needs to determine the IP address of the Call Manager, its own IP address, and other information about the IP gateway and DNS servers. Initialization takes place on the local LAN. The client sends a Dynamic Host Control Protocol (DHCP) request to get an IP address, the DNS server address, and the TFTP server name and address. The client needs the TFTP server name to download the configuration file called sepmacaddr.cnf. If the TFTP name is not given, the client uses the default filename in the IP phone. The client then downloads the .cnf (xml) configuration file from TFTP server. CNF files contain the IP address or addresses of the primary and secondary Cisco Call Manager. With this information, the client contacts the Call Manager to register.

Client Registration

The SCCP client, after initialization, registers with the Call Manager over a TCP connection on well-known default port 2000. The client registers by providing the Call Manager with its IP address, the MAC address of the phone, and other information, such as protocol and version. The client cannot initiate or receive calls until it is registered. Keepalive messages keep this TCP connection open between the client and Call Manager so that the client can initiate or receive calls at any time, provided that a policy on the device allows this.

Call Setup

IP phone-to-IP phone call setup using SCCP is always handled by the Call Manager. Messages for call setup are sent to the Call Manager, which returns messages appropriate to the status of the call. If call setup is successful, and a policy on the device allows the call, the Call Manager sends the media setup messages to the client.

Media Setup

The Call Manager sends the IP address and port number of the called party to the calling party. The Call Manager also sends the media IP address and port number of the calling party to the called party. After media setup, media is transmitted directly between clients. When the call ends, the Call Manager is informed and terminates the media streams. At no time during this process does the Call Manager hand over call-setup function to the client. Media is streamed directly between clients through RTP/UDP/IP.

SCCP Version

Starting in Junos OS Release 12.1X46-D10 and Junos OS Release 17.3R1, the SCCP ALG supports SCCP versions 16, 17, and 20 and several SCCP messages have been updated with a new format. Cisco Call Manager (CM) version 7 uses SCCP version 20.

SCCP Control Messages and RTP Flow

Figure 1 shows the SCCP control messages used to set up and tear down a simple call between Phone 1 and Phone 2. Except for the OffHook message initiating the call from Phone1 and the OnHook message signaling the end of the call, all aspects of the call are controlled by the Call Manager.

Figure 1: Call Setup and Teardown
Call Setup and Teardown

SCCP Messages

Table 1, Table 2, Table 3, and Table 4 list the SCCP call message IDs in the four intervals allowed by the device.

Table 1: Station to Call Manager Messages

#define STATION_REGISTER_MESSAGE

0x00000001

#define STATION_IP_PORT_MESSAGE

0x00000002

#define STATION_ALARM_MESSAGE

0x00000020

#define STATION_OPEN_RECEIVE_CHANNEL_ACK

0x00000022

Table 2: Call Manager to Station Messages

#define STATION_START_MEDIA_TRANSMISSION

0x00000001

#define STATION_STOP_MEDIA_TRANSMISSION

0x00000002

#define STATION_CALL_INFO_MESSAGE

0x00000020

#define STATION_OPEN_RECEIVE_CHANNEL_ACK

0x00000022

#define STATION_CLOSE_RECEIVE_CHANNEL

0x00000106

Table 3: Call Manager 4.0 Messages and Post Sccp 6.2

#define STATION_REGISTER_TOKEN_REQ_MESSAGE

0x00000029

#define STATION_MEDIA_TRANSMISSION_FAILURE

0x0000002A

#define STATION_OPEN_MULTIMEDIA_RECEIVE_CHANNEL_ACK

0x00000031

Table 4: Call Manager to Station

#define STATION_OPEN_MULTIMEDIA_RECEIVE_CHANNEL

0x00000131

#define STATION_START_MULTIMEDIA_TRANSMISSION

0x00000132

#define STATION_STOP_MULTIMEDIA_TRANSMISSION

0x00000133

#define STATION_CLOSE_MULTIMEDIA_RECEIVE_CHANNEL

0x00000136

SCCP ALG Limitations

  • The SCCP is a Cisco proprietary protocol. So, any changes to the protocol by Cisco cause the SCCP ALG implementation to break. However, workarounds are provided to bypass strict decoding and allow any protocol changes to be handled gracefully.

  • Any changes to the policies will drop the sessions and impact already established SCCP calls.

  • The SCCP ALG opens pinholes that are collapsed during traffic or media inactivity. This means that during a temporary loss of connectivity, media sessions are not reestablished.

  • Call Manager (CM) version 6.x and later does not support TCP probe packets in chassis cluster mode. As a result, the existing SCCP sessions will break when there is a failover. You can still create new SCCP sessions during failover.

Understanding SCCP ALG Inactive Media Timeouts

The inactive media timeout feature helps you to conserve network resources and maximize throughput.

This parameter indicates the maximum length of time (in seconds) a call can remain active without any media traffic within a group. Each time a Real-Time Transport Protocol (RTP) or Real-Time Control Protocol (RTCP) packet occurs within a call, this timeout resets. When the period of inactivity exceeds this setting, the gates the Skinny Client Control Protocol (SCCP) opened for media are closed. The default setting is 120 seconds, and the range is from 10 to 2550 seconds. Note that upon timeout, while resources for media (sessions and pinholes) are removed, the call is not terminated.

SCCP ALG Configuration Overview

The Skinny Client Control Protocol Application Layer Gateway (SCCP ALG) is enabled by default on the device—no action is required to enable it. However, you might choose to fine-tune SCCP ALG operations by using the following instructions:

  1. Conserve network resources and maximize throughput. For instructions, see Example: Setting SCCP ALG Inactive Media Timeouts.

  2. Enable unknown messages to pass when the session is in Network Address Translation (NAT) mode and route mode. For instructions, see Example: Allowing Unknown SCCP ALG Message Types.

  3. Protect the SCCP clients from denial-of-service (DoS) flood attacks. For instructions, see Example: Configuring SCCP ALG DoS Attack Protection.

Example: Setting SCCP ALG Inactive Media Timeouts

This example shows how to set the inactive media timeout value for the SCCP ALG.

Requirements

Before you begin, review the parameter used to indicate the maximum length of time (in seconds) a call can remain active without any media traffic within a group. See Understanding SCCP ALG Inactive Media Timeouts.

Overview

Each time an RTP or RTCP packet occurs within a call, this timeout resets. When the period of inactivity exceeds this setting, the gates the SCCP opened for media are closed. This example sets the media inactivity timeout to 90 seconds.

Configuration

GUI Step-by-Step Procedure

To set the inactive media timeout for the SCCP ALG:

  1. Select Configure>Security>ALG.
  2. Select the SCCP tab.
  3. In the Inactive Media Timeout box, enter 90.
  4. Click OK to check your configuration and save it as a candidate configuration.
  5. If you are done configuring the device, click Commit Options>Commit.

Step-by-Step Procedure

To set the inactive media timeout for the SCCP ALG:

  1. Configure the SCCP ALG inactive media timeout value.
  2. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show security alg sccp command.

Example: Allowing Unknown SCCP ALG Message Types

This example shows how to configure the SCCP ALG to allow unknown SCCP message types in both NAT mode and route mode.

Requirements

Before you begin, determine whether to accommodate new and unknown SCCP message types for the device.

Overview

To accommodate on-going development of the Skinny Client Control Protocol (SCCP), you might want to allow traffic containing new SCCP message types. The unknown SCCP message type feature enables you to configure the device to accept SCCP traffic containing unknown message types in both Network Address Translation (NAT) mode and route mode.

The default is to drop unknown (unsupported) messages. We do not recommend permitting unknown messages because they can compromise security. However, in a secure test or production environment, the unknown SCCP message type command can be useful for resolving interoperability issues with disparate vendor equipment. Permitting unknown SCCP messages can help you get your network operational so that you can later analyze your voice-over-IP (VoIP) traffic to determine why some messages were being dropped.

Note that the unknown SCCP message type command applies only to received packets identified as supported VoIP packets. If a packet cannot be identified, it is always dropped. If a packet is identified as a supported protocol and you have configured the device to permit unknown message types, the message is forwarded without processing.

Configuration

GUI Step-by-Step Procedure

To configure the SCCP ALG to allow unknown message types:

  1. Select Configure>Security>ALG.
  2. Select the SCCP tab.
  3. Select the Enable Permit NAT applied check box.
  4. Select the Enable Permit routed check box.
  5. Click OK to check your configuration and save it as a candidate configuration.
  6. If you are done configuring the device, click Commit Options>Commit.

Step-by-Step Procedure

To configure the SCCP ALG to allow unknown message types:

  1. Allow unknown message types to pass if the session is in either NAT mode or in route mode.
  2. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show security alg sccp command.

Example: Configuring SCCP ALG DoS Attack Protection

This example shows how to configure connection flood protection for the SCCP ALG.

Requirements

Before you begin, determine whether to protect the SCCP media gateway from DoS flood attacks.

Overview

You can protect Skinny Client Control Protocol Application Layer Gateway (SCCP ALG) clients from denial-of-service (DoS) flood attacks by limiting the number of calls they attempt to process.

When you configure SCCP call flood protection, the SCCP ALG drops any calls exceeding the threshold you set. The range is 2 to 1000 calls per second per client, the default is 20.

In this example, the device is configured to drop any calls exceeding 500 per second per client.

Configuration

GUI Step-by-Step Procedure

To configure call flood protection for the SCCP ALG:

  1. Select Configure>Security>ALG.
  2. Select the SCCP tab.
  3. In the Call flood threshold box, type 500.
  4. Click OK to check your configuration and save it as a candidate configuration.
  5. If you are done configuring the device, click Commit Options>Commit.

Step-by-Step Procedure

To configure call flood protection for the SCCP ALG:

  1. Configure the DoS attack protection:
  2. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show security alg sccp command.

Example: Configuring the SCCP ALG Call Manager or TFTP Server in the Private Zone

This example shows how to configure static NAT on the outgoing interface of a Juniper Networks device to allow callers in a public zone to register with an SCCP ALG Call Manager or a TFTP server located in a private zone.

Requirements

Before you begin, understand NAT support with SCCP ALG. See Understanding SCCP ALGs.

Overview

In this example (see Figure 2), a single device is serving as a Call Manager or a TFTP server. The Call Manager or TFTP server and phone1 are attached to the private zone, and phone2 is attached to the public zone. You configure a static NAT rule set for the Call Manager or TFTP server so that when phone2 boots up it contacts the TFTP server and obtains the IP address of the Call Manager. You then create a policy called in-pol to allow SCCP traffic from the public to the private zone and a policy called out-pol to allow phone1 to call out.

Note

We recommend that you change the IP address of the Call Manager, which resides in the TFTP server configuration file (sep <mac_addr>.cnf), to the NAT IP address of the Call Manager.

Topology

Figure 2 shows call manager or TFTP server in the private zone.

Figure 2: Call Manager or TFTP Server in the Private Zone
Call Manager or TFTP Server in the Private
Zone

In this example, you configure NAT as follows:

  • Create a static NAT rule set called to-proxy with a rule called phone2 to match packets from the public zone with the destination address 1.1.1.2/32. For matching packets, the destination IP address is translated to the private address 10.1.1.4/32.

  • Configure proxy ARP for the address 1.1.1.2/32 on interface ge-0/0/1.0. This allows the system to respond to ARP requests received on the interface for these addresses.

  • Configure a second rule set called phones with a rule called phone1 to enable interface NAT for communication from phone1 to phone2.

Configuration

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure NAT for an SCCP ALG Call Manager or a TFTP server located in a private zone:

  1. Configure interfaces.
  2. Create security zones.
  3. Create address books and attach zones to them.
  4. Create a rule set for static NAT and assign a rule to it.
  5. Configure proxy ARP.
  6. Configure interface NAT for communication from phone1 to phone2.
  7. Configure a policy to allow traffic from the public zone to the private zone.
  8. Configure a policy to allow traffic from the private zone to the public zone.
  9. Configure a policy to allow traffic from phone1 to the CM/TFTP server.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show security zones, show security address-book, show security nat, and show security policies commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the configuration is working properly, perform these tasks:

Verifying Source NAT Rule Usage

Purpose

Verify that there is traffic matching the source NAT rule.

Action

From operational mode, enter the show security nat source rule all command.

Meaning

The Translation hits field shows that, there is no traffic matching the source NAT rule.

Verifying Static NAT Configuration

Purpose

Verify that there is traffic matching the static NAT rule set.

Action

From operational mode, enter the show security nat static rule phone1 command.

Meaning

The Translation hits field shows that, there is no traffic matching the source NAT rule set.

Verifying Static NAT Configuration

Purpose

Verify that there is traffic matching the static NAT rule set.

Action

From operational mode, enter the show security nat static rule phone2 command.

Meaning

The Translation hits field shows that, there is no traffic matching the source NAT rule set.

Verifying SCCP ALG

Purpose

Verify that the SCCP ALG is enabled.

Action

From operational mode, enter the show security alg status | match sccp command.

Meaning

The output shows the SCCP ALG status as follows:

  • Enabled—Shows the SCCP ALG is enabled.

  • Disabled—Shows the SCCP ALG is disabled.

Verifying the Security Polices of SIP ALG

Purpose

Verify that the static NAT between public zone and private zone is set.

Action

From operational mode, enter the show security policies command.

Meaning

The sample output shows that the static NAT between public zone and private zone is set.

Verifying SCCP ALG Configurations

Verifying SCCP ALG

Purpose

Display SCCP verification options.

Action

From the CLI, enter the show security alg sccp command.

user@host> show security alg sccp ?

Meaning

The output shows a list of all SCCP verification parameters. Verify the following information:

  • All SCCP calls

  • Counters for all SCCP calls

Verifying SCCP ALG Calls

Purpose

Display a list of all SCCP calls

Action

From the CLI, enter the show security alg sccp calls command.

user@host> show security alg sccp calls

Meaning

The output shows a list of all SCCP verification parameters. Verify the following information:

  • All SCCP calls

  • Counters for all SCCP c alls

  • Information about all SCCP endpoints

Verifying SCCP ALG Call Details

Purpose

Display details about all SCCP calls.

Action

From the CLI, enter the show security alg sccp calls detail command.

user@host> show security alg sccp calls detail

Meaning

The output shows a list of all SCCP verification parameters. Verify the following information:

  • Client zone

  • Call Manager IP address: 13.0.99.226

  • Conference ID

  • Resource manager group

  • SCCP channel information

  • Total number of calls

Verifying SCCP ALG Counters

Purpose

Display a list of all SCCP counters

Action

From the J-Web interface, select Monitor>ALGs>SCCP>Counters. Alternatively, from the CLI, enter the show security alg sccp counters command.

user@host> show security alg sccp ounters

Meaning

The output shows a list of all SCCP verification parameters. Verify the following information:

  • SCCP call statistics

  • Error counters

Release History Table
Release
Description
Starting in Junos OS Release 12.1X46-D10 and Junos OS Release 17.3R1, the SCCP ALG supports SCCP versions 16, 17, and 20 and several SCCP messages have been updated with a new format.