Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

header-navigation
keyboard_arrow_up
list Table of Contents
file_download PDF
{ "lLangCode": "en", "lName": "English", "lCountryCode": "us", "transcode": "en_US" }
English
keyboard_arrow_right

SCCP ALG

date_range 28-Nov-23

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 TeardownCall 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

Procedure

GUI Quick Configuration
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.

    content_copy zoom_out_map
    [edit]
    user@host# set security alg sccp inactive-media-timeout 90
    
  2. If you are done configuring the device, commit the configuration.

    content_copy zoom_out_map
    [edit]
    user@host# commit
    

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

Procedure

GUI Quick Configuration
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.

    content_copy zoom_out_map
    [edit]
    user@host#  set security alg sccp application-screen unknown-message permit-nat-applied permit-routed
    
  2. If you are done configuring the device, commit the configuration.

    content_copy zoom_out_map
    [edit]
    user@host# commit
    

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

Procedure

GUI Quick Configuration
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:

    content_copy zoom_out_map
    [edit]
    user@host# set security alg sccp application-screen call-flood threshold 500
    
  2. If you are done configuring the device, commit the configuration.

    content_copy zoom_out_map
    [edit]
    user@host# commit
    

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 ZoneCall 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 172.16.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 172.16.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

Procedure

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.

content_copy zoom_out_map
set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/24  
set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24 
set security zones security-zone private interfaces ge-0/0/0.0  
set security zones security-zone public interfaces ge-0/0/1.0
set security address-book book1 address phone1 10.1.1.3/32  
set security address-book book1 address cm-tftp_server 10.1.1.4/32 
set security address-book book1 attach zone private  
set security address-book book2 address phone2 172.16.1.4/32 
set security address-book book2 attach zone public
set security nat source rule-set phones from zone private 
set security nat source rule-set phones to zone public  
set security nat source rule-set phones rule phone1 match source-address 10.1.1.3/32  
set security nat source rule-set phones rule phone1 then source-nat interface 
set security nat static rule-set to-proxy from zone public  
set security nat static rule-set to-proxy rule phone2 match destination-address 172.16.1.2/32  
set security nat static rule-set to-proxy rule phone2 then static-nat prefix 10.1.1.4/32 
set security nat proxy-arp interface ge-0/0/1.0 address 172.16.1.2/32
set security policies from-zone public to-zone private policy in-pol match source-address phone2  
set security policies from-zone public to-zone private policy in-pol match destination-address cm-tftp_server  
set security policies from-zone public to-zone private policy in-pol match destination-address phone1
set security policies from-zone public to-zone private policy in-pol match application junos-sccp 
set security policies from-zone public to-zone private policy in-pol then permit  
set security policies from-zone private to-zone public policy out-pol match source-address any  
set security policies from-zone private to-zone public policy out-pol match destination-address phone2 
set security policies from-zone private to-zone public policy out-pol match application junos-sccp 
set security policies from-zone private to-zone public policy out-pol then permit 
set security policies from-zone private to-zone private policy tftp-pol match source-address any
set security policies from-zone private to-zone private policy tftp-pol match destination-address any
set security policies from-zone private to-zone private policy tftp-pol match application junos-tftp
set security policies from-zone private to-zone private policy tftp-pol then permit
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.

    content_copy zoom_out_map
    [edit]
    user@host# set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/24
    user@host# set interfaces ge-0/0/1 unit 0 family inet address 172.16.1.1/24
    
  2. Create security zones.

    content_copy zoom_out_map
    [edit security zones]
    user@host# set security-zone private interfaces ge-0/0/0.0
    user@host# set security-zone public interfaces ge-0/0/1.0
    
  3. Create address books and attach zones to them.

    content_copy zoom_out_map
    [edit security address-book book1]
    user@host# set address phone1 10.1.1.3/32  
    user@host# set address cm-tftp_server 10.1.1.4/32 
    user@host# set attach zone private  
    
    content_copy zoom_out_map
    [edits security address-book book2]
    user@host# set address phone2 172.16.1.4/32 
    user@host# set attach zone public
    
  4. Create a rule set for static NAT and assign a rule to it.

    content_copy zoom_out_map
    [edit security nat static rule-set to-proxy]
    user@host# set from zone public 
    user@host# set rule phone2 match destination-address 172.16.1.2/32 
    user@host# set rule phone2 then static-nat prefix 10.1.1.4/32 
    
  5. Configure proxy ARP.

    content_copy zoom_out_map
    [edit security nat]
    user@host# set proxy-arp interface ge-0/0/1.0 address 172.16.1.2/32 
    
  6. Configure interface NAT for communication from phone1 to phone2.

    content_copy zoom_out_map
    [edit security nat source rule-set phones]
    user@host# set from zone private 
    user@host# set to zone public 
    user@host# set rule phone1 match source-address 10.1.1.3/32 
    user@host# set rule phone1 then source-nat interface
    
  7. Configure a policy to allow traffic from the public zone to the private zone.

    content_copy zoom_out_map
    [edit security policies from-zone public to-zone private policy in-pol]
    user@host# set match source-address phone2
    user@host# set match destination-address cm-tftp_server 
    user@host# set match destination-address phone1 
    user@host# set match application junos-sccp
    user@host# set then permit
    
  8. Configure a policy to allow traffic from the private zone to the public zone.

    content_copy zoom_out_map
    [edit security policies from-zone private to-zone public policy out-pol]
    user@host# set match source-address any
    user@host# set match destination-address phone2
    user@host# set match application junos-sccp
    user@host# set then permit 
    
  9. Configure a policy to allow traffic from phone1 to the CM/TFTP server.

    content_copy zoom_out_map
    [edit security policies from-zone private to-zone private policy tftp-pol]
    user@host# set match source-address any
    user@host# set match destination-address any 
    user@host# set match application junos-tftp 
    user@host# set then permit 
    
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.

content_copy zoom_out_map
[edit]
user@host# show interfaces
    ge-0/0/0 {
        unit 0 {
            family inet {
                
                address 10.1.1.1/24;
            }
        }
    }
        ge-0/0/1 {
            unit 0 {
                family inet {
                    
                    address 172.16.1.1/24;
                }
            }
        }
[edit]
user@host# show security zones
security-zone private {
    interfaces {
        ge-0/0/0.0;
    }
}
    security-zone public {
        interfaces {
            ge-0/0/1.0;
        }
    }
[edit]
user@host# show security address-book
book1 {
    address phone1 10.1.1.3/32;
    address cm-tftp_server 10.1.1.4/32;
    attach {
        zone private;
    }
}
    book2 {
        address phone2 172.16.1.4/32;
        attach {
            zone public;
        }
    }
[edit]
user@host# show security nat
source {
    
    rule-set phones {
        from zone private;
        to zone public;
        rule phone1 {
            match {
                source-address 10.1.1.3/32;
            }
            then {
                source-nat {
                    interface;
                }
            }
        }
    }
}
    static {
        rule-set to-proxy {
            from zone public;
            rule phone2 {
                match {
                    destination-address 172.16.1.2/32;
                }
                then {
                    static-nat prefix 10.1.1.4/32;
                }
            }
        }
    }
    proxy-arp {
        
        interface ge-0/0/1.0 {
            address {
                172.16.1.2/32;
            }
        }
    }
[edit]
user@host# show security policies
from-zone public to-zone private {
    policy in-pol {
        match {
            source-address phone2;
            destination-address cm-tftp_server;
            destination-address phone1;
            application junos-sccp;
        }
        then {
            permit;
        }
    }
}
    from-zone private to-zone public {
        policy out-pol {
            match {
                source-address any;
                destination-address phone2;
                application junos-sccp;
            }
            then {
                permit;
            }
        }
    }
    from-zone private to-zone private {
        policy tftp-pol {
            match {
                source-address any;
                destination-address any;
                application junos-tftp;
            }
            then {
                permit;
            }
        }
    }

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.

content_copy zoom_out_map
user@host> show security nat source rule all
content_copy zoom_out_map
Total rules: 1
Total referenced IPv4/IPv6 ip-prefixes: 3/0
source NAT rule: phone1               Rule-set: phones
  Rule-Id                    : 3
  Rule position              : 2
  From zone                  : private
  To zone                    : public
  Match
    Source addresses         : 10.1.1.3        - 10.1.1.3
    Destination port         : 0               - 0
  Action                        : interface
    Persistent NAT type         : N/A
    Persistent NAT mapping type : address-port-mapping
    Inactivity timeout          : 0
    Max session number          : 0
  Translation hits           : 0
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 phone2 command.

content_copy zoom_out_map
user@host> show security nat static rule phone2
content_copy zoom_out_map
Static NAT rule: phone2               Rule-set: to-proxy
  Rule-Id                    : 1
  Rule position              : 1
  From zone                  : public
  Destination addresses      : 172.16.1.2
  Host addresses             : 10.1.1.4
  Netmask                    : 32
  Host routing-instance      : N/A
  Translation hits           : 0
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.

content_copy zoom_out_map
user@host> show security alg status | match sccp
content_copy zoom_out_map
SCCP     : Enabled
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.

content_copy zoom_out_map
user@host> show security policies
content_copy zoom_out_map
from-zone private to-zone public {
       policy out-pol {
        match {
            source-address any;
            destination-address phone2;
            application junos-sccp;
        }
        then {
            permit;
        }
    }
}
from-zone public to-zone private {
       policy in-pol {
        match {
            source-address phone2;
            destination-address [ cm-tftp_server phone1 ];
            application junos-sccp;
        }
        then {
            permit;
        }
    }
}
from-zone private to-zone private {
    policy tftp-pol {
        match {
            source-address any;
            destination-address any;
            application junos-tftp;
        }
        then {
            permit;
        }
    }
}
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.

content_copy zoom_out_map
user@host> show security alg sccp ?
Possible completions:
  calls                Show SCCP calls
  counters             Show SCCP counters

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.

content_copy zoom_out_map
user@host> show security alg sccp calls 
Possible completions:
  calls                Show SCCP calls
  counters             Show SCCP counters
  endpoints            Show SCCP endpoints

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.

content_copy zoom_out_map
user@host> show security alg sccp calls detail
Client IP address: 11.0.102.91
  Client zone: 7
  Call Manager IP: 13.0.99.226
  Conference ID: 16789504
  Resource manager group: 2048
  SCCP channel information:
    Media transmit channel address (IP address/Port): 0.0.0.0:0
    Media transmit channel translated address (IP address/Port): 0.0.0.0:0
    Media transmit channel pass-through party ID (PPID): 0
    Media transmit channel resource ID: 0
    Media receive channel address (IP address/Port): 11.0.102.91:20060
    Media receive channel translated address (IP address/Port): 25.0.0.1:1032
    Media receive channel pass-through party ID (PPID): 16934451
    Media receive channel resource ID: 8185
    Multimedia transmit channel address (IP address/Port): 0.0.0.0:0
    Multimedia transmit channel translated address (IP address/Port): 0.0.0.0:0
    Multimedia transmit channel pass-through party ID (PPID): 0
    Multimedia transmit channel resource ID: 0
    Multimedia receive channel address (IP address/Port): 0.0.0.0:0
    Multimedia receive channel translated address (IP address/Port): 0.0.0.0:0
    Multimedia receive channel pass-through party ID (PPID): 0
    Multimedia receive channel resource ID: 0
Total number of calls = 1

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.

content_copy zoom_out_map
user@host> show security alg sccp ounters
SCCP call statistics:
  Active client sessions         : 0
  Active calls                   : 0
  Total calls                    : 0
  Packets received               : 0
  PDUs processed                 : 0
  Current call rate              : 0
Error counters:
  Packets dropped                     : 0
  Decode errors                       : 0
  Protocol errors                     : 0
  Address translation errors          : 0
  Policy lookup errors                : 0
  Unknown PDUs                        : 0
  Maximum calls exceeded              : 0
  Maximum call rate exceeded          : 0
  Initialization errors               : 0
  Internal errors                     : 0
  Nonspecific error                   : 0
  No active calls to delete           : 0
  No active client sessions to delete : 0
  Session cookie create errors        : 0
  Invalid NAT cookie detected         : 0

Meaning

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

  • SCCP call statistics

  • Error counters

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
12.1X46-D10
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.
footer-navigation