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
- SCCP Components
- SCCP Transactions
- SCCP Version
- SCCP Control Messages and RTP Flow
- SCCP Messages
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.
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.
#define STATION_REGISTER_MESSAGE |
0x00000001 |
#define STATION_IP_PORT_MESSAGE |
0x00000002 |
#define STATION_ALARM_MESSAGE |
0x00000020 |
#define STATION_OPEN_RECEIVE_CHANNEL_ACK |
0x00000022 |
#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 |
#define STATION_REGISTER_TOKEN_REQ_MESSAGE |
0x00000029 |
#define STATION_MEDIA_TRANSMISSION_FAILURE |
0x0000002A |
#define STATION_OPEN_MULTIMEDIA_RECEIVE_CHANNEL_ACK |
0x00000031 |
#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:
Conserve network resources and maximize throughput. For instructions, see Example: Setting SCCP ALG Inactive Media Timeouts.
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.
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:
Select Configure>Security>ALG.
Select the SCCP tab.
In the Inactive Media Timeout box, enter
90.Click OK to check your configuration and save it as a candidate configuration.
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:
Configure the SCCP ALG inactive media timeout value.
[edit] user@host# set security alg sccp inactive-media-timeout 90
If you are done configuring the device, commit the configuration.
[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:
Select Configure>Security>ALG.
Select the SCCP tab.
Select the Enable Permit NAT applied check box.
Select the Enable Permit routed check box.
Click OK to check your configuration and save it as a candidate configuration.
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:
Allow unknown message types to pass if the session is in either NAT mode or in route mode.
[edit] user@host# set security alg sccp application-screen unknown-message permit-nat-applied permit-routed
If you are done configuring the device, commit the configuration.
[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:
Select Configure>Security>ALG.
Select the SCCP tab.
In the Call flood threshold box, type
500.Click OK to check your configuration and save it as a candidate configuration.
If you are done configuring the device, click Commit Options>Commit.
Step-by-Step Procedure
To configure call flood protection for the SCCP ALG:
Configure the DoS attack protection:
[edit] user@host# set security alg sccp application-screen call-flood threshold 500
If you are done configuring the device, commit the configuration.
[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.
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.
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.
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:
-
Configure interfaces.
[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
-
Create security zones.
[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
-
Create address books and attach zones to them.
[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
[edits security address-book book2] user@host# set address phone2 172.16.1.4/32 user@host# set attach zone public
-
Create a rule set for static NAT and assign a rule to it.
[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
-
Configure proxy ARP.
[edit security nat] user@host# set proxy-arp interface ge-0/0/1.0 address 172.16.1.2/32
-
Configure interface NAT for communication from phone1 to phone2.
[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
-
Configure a policy to allow traffic from the public zone to the private zone.
[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
-
Configure a policy to allow traffic from the private zone to the public zone.
[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
-
Configure a policy to allow traffic from phone1 to the CM/TFTP server.
[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.
[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
- Verifying Static NAT Configuration
- Verifying SCCP ALG
- Verifying the Security Polices of SIP ALG
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.
user@host> show security nat source rule all
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.
user@host> show security nat static rule phone2
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.
user@host> show security alg status | match sccp
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.
user@host> show security policies
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
- Verifying SCCP ALG Calls
- Verifying SCCP ALG Call Details
- Verifying SCCP ALG Counters
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 ? 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
See Also
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 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.
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.
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.