H.323 ALG

 

The H.323 Application Layer Gateway (ALG) consist of a suit of H.225.0 and H.245 protocols to provide audio-visual communication session on any network. The H.323 ALG provides a secure communication between terminal hosts, such as IP phones and multimedia devices.

Understanding H.323 ALG

The H.323 standard is a legacy voice-over-IP (VoIP) protocol defined by the International Telecommunication Union (ITU-T). H.323 consists of a suite of protocols (such as H.225.0 and H.245) that are used for call signaling and call control for VoIP.

H.323 uses the ASN.1 coding format. It sets up the dynamic links for data, video, and audio streams, following the protocols Q.931 (with port number 1720) and H.245. There are three major processes in H.323:

  • Gatekeeper Discovery—An endpoint finds its gatekeeper through the gatekeeper discovery process, via broadcast or unicast to a known IP and the well-known UDP port 1719. Note that Junos OS only supports unicast discovery.

  • Endpoint Registration, Admission, and Status—An endpoint registers to a gatekeeper and asks for its management. Before making a call, an endpoint asks its gatekeeper for permission to place the call. In both registration and admission phases, the Registration, Admission, and Status (RAS) channel is used. The Transport Service Access Point (TSAP) can utilize either the well-known UDP port (1719) or a dynamically assigned port from the discovery or registration phase and an IP address.

  • Call Control and Call Setup—Calls can be established within a zone or across two zones, or even across multiple zones (multipoint conference). The call setup and tear down is performed through the call signaling channel whose TSAP is the well-known TCP port (1720). The call control, including opening/closing media channels between two endpoints, is performed through the call control channel whose TSAP is dynamically assigned from the previous call signaling process. H.245 messages are used in the call control channel, and are encoded using ASN.1.

    Note

    Detailed information on H.323 can be found in ITU-T Recommendation H.323.

The H.323 Application Layer Gateway (ALG) of the device lets you secure VoIP communication between terminal hosts, such as IP phones and multimedia devices. In such a telephony system, the gatekeeper device manages call registration, admission, and call status for VoIP calls. Gatekeepers can reside in the two different zones or in the same zone. (See Figure 1.)

Figure 1: H.323 ALG for VoIP Calls
H.323 ALG for VoIP Calls
Note

The illustration uses IP phones for illustrative purposes, although it is possible to make configurations for other hosts that use VoIP, such as Microsoft NetMeeting multimedia devices.

Starting with Junos OS Release 17.4R1, the gateway-to-gateway call feature is supported on the H.323 Application Layer Gateway (ALG). This feature introduces one-to-many mapping between an H.225 control session and H.323 calls as multiple H.323 calls go through a single control session.

Starting with Junos OS Release 17.4R1, the H.323 Application Layer Gateway (ALG) supports NAT64 rules in an IPv6 network.

H.323 ALG Configuration Overview

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

  1. Specify how long an endpoint registration entry remains in the Network Address Translation (NAT) table. For instructions, see Example: Setting H.323 ALG Endpoint Registration Timeouts.

  2. Enable media traffic on a narrow or wide range of ports. For instructions, see Example: Setting H.323 ALG Media Source Port Ranges.

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

  4. Enable unknown messages to pass when the session is in NAT mode and route mode. For instructions, see Example: Allowing Unknown H.323 ALG Message Types.

Understanding the Avaya H.323 ALG

The H.323 standard is a legacy voice-over-IP (VoIP) protocol defined by the International Telecommunication Union (ITU-T). H.323 consists of a suite of protocols (such as H.225.0 and H.245) that are used for call signaling and call control for VoIP. The processes for configuring the H.323 standard Application Layer Gateway (ALG) and the proprietary Avaya H.323 ALG are the same.

However, Avaya H.323 ALG has some special features. To understand and configure the Avaya H.323-specific features listed here, see the Administrator Guide for Avaya Communication Manager, Avaya IP Telephony Implementation Guide, and Avaya Application Solutions IP Telephony Deployment Guide at http://support.avaya.com.

This topic contains the following sections:

Avaya H.323 ALG-Specific Features

Avaya H.323-specific features are as follows:

  • H.323 Fast Connect

  • H.323 asymmetric media

  • Call waiting

  • Call forwarding

  • Voice mail

  • Call identification

  • Conference calling

Call Flow Details in the Avaya H.323 ALG

  • Connecting the Phone into the Network—Avaya performs the Q.931 Setup/Connect negotiation when the phone is wired into the network rather than when a call is being initiated.

  • Making a call—When a call is made, because the PBX has already stored the capabilities for each phone when the phone is connected to the network, no further Q.931 and PBX negotiations are required to set up the call. It no longer exchanges Q.931 Setup and Connect messages with the PBX. The phone and the PBX exchange H.323 Facility messages to set up the call.

  • Registering with a CM—When a call has been made, Avaya H.323 registers with the Avaya Communication Manager (CM). The registration process is similar to a generic H.323 standard registration process.

    Note

    The direct mode and tunnel mode are not defined by Avaya H.323 ALG.

    For a call to work, the CM must be deployed with Avaya Endpoints. During the call, RAS and Q.931 messages are exchanged between the CM and the Avaya Endpoints.

    Note

    For Avaya H.323 with a source Network Address Translation (NAT) pool, the registration process allows only one IP address in the pool.

  • Setting up Real-Time Transport Protocol (RTP)/Real-Time Control Protocol (RTCP) ports—The Q.931 Setup, Facility and Information messages are used to set up RTP/RTCP ports. The hierarchy for an Avaya H.323 session is Q.931, RTP/RTCP, Parent, and then Child.

    Note

    H.245 ports are not used in an Avaya call flow process.

  • Using Avaya H.323 counters—The counters for calls and active calls are not applicable to the Avaya H.323 ALG. The call creation and tearing down is done by Facility messages afterward. When resources are allocated for a call, all counters for calls and active calls increment. If resources are allocated for a call multiple times, messages belonging to the same call that pass the firewall multiple times will trigger multiple increments of the counters. In other words, messages that belong to the same call and pass the firewall multiple times might trigger multiple increments of the counters if the resource for a call needs to be allocated multiple times.

    For example, in the two-zone case, the setup and connect message pair allocates one call resource. The active call counter is increased once. Each time the setup and connect message pair passes the firewall, a different call resource with unique interfaces and NAT is allocated. Therefore, the counter increments twice in a three-zone scenario.

Example: Passing H.323 ALG Traffic to a Gatekeeper in the Private Zone

This example shows how to set up two policies that allow H.323 traffic to pass between IP phone hosts and a gatekeeper in the private zone, and an IP phone host (2.2.2.5/32) in the public zone.

Requirements

Before you begin:

  • Understand and configure any Avaya H.323-specific features. See the Administrator Guide for Avaya Communication Manager, Avaya IP Telephony Implementation Guide, and Avaya Application Solutions IP Telephony Deployment Guide at http://support.avaya.com.

  • Configure security zones. See Understanding Security Zones.

Overview

This example shows how to set up two policies that allow H.323 traffic to pass between IP phone hosts and a gatekeeper in the private zone, and an IP phone host (2.2.2.5/32) in the public zone. The connection to the device can either be with or without NAT. See Figure 2.

Figure 2: H.323 Gatekeeper in the Private Zone
H.323 Gatekeeper
in the Private Zone

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 the device to pass H.323 ALG traffic to a gatekeeper in the private zone:

  1. Configure two address books.
  2. Configure policy P1 from the private zone to the public zone.
  3. Configure policy P2 from the public zone to the private zone.

Results

From configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

For brevity, this show output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (...).

[edit]


user@host# show security policies

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

Verification

To confirm that the configuration is working properly, perform this task:

Verifying H.323 ALG Configurations

Purpose

Display information about active calls.

Note

H.323 counters for calls and active calls in the output to this show security command do not apply to the proprietary Avaya implementation of H.323. This is because Q.931 setup and connect messages are exchanged right after the phone is powered up and call creation and tear down is done by Facility messages.

Counters for calls and active calls are increased when the resources allocated for calls are increased—that is, messages belonging to the same call and that pass the firewall multiple times increment the counters. This applies when resources for a call need to be allocated multiple times. For example, in a two-zone scenario the setup and connect message pair allocates one call resource, and the active call counter is increased by one. But in a three-zone scenario the setup and connect message pair passes the firewall twice, each time allocating different call resources. In this case, the counter is incremented.

Action

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

Counters for H.245 messages received also will not be accurate in the case of H.245 tunneling. Because H.245 messages are encapsulated in Q.931 packets, the counter for H.245 messages received will remain zero even when there are H.245 messages. The Other H245 counter will, however, reflect these packet transmissions.

[edit]


user@host> show security alg h323 counters

Example: Passing H.323 ALG Traffic to a Gatekeeper in the External Zone

This example shows how to set up two policies to allow H.323 traffic to pass between IP phone hosts in the internal zone, and the IP phone at IP address 2.2.2.5/32 (and the gatekeeper) in the external zone.

Requirements

Before you begin:

  • Understand and configure any Avaya H.323-specific features. See the Administrator Guide for Avaya Communication Manager, Avaya IP Telephony Implementation Guide, and Avaya Application Solutions IP Telephony Deployment Guide at http://support.avaya.com.

  • Configure security zones. See Understanding Security Zones.

Overview

Because route mode does not require address mapping of any kind, a device configuration for a gatekeeper in the external, or public, zone is usually identical to the configuration for a gatekeeper in an internal, or private, zone. This example shows how to set up two policies to allow H.323 traffic to pass between IP phone hosts in the internal zone, and the IP phone at IP address 2.2.2.5/32 (and the gatekeeper) in the external zone. The device can be in transparent or route mode. See Figure 3.

Figure 3: H.323 Gatekeeper in the External Zone
H.323 Gatekeeper
in the External Zone

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 the device to pass H.323 ALG traffic to a gatekeeper in the external zone:

  1. Configure two address books.
  2. Configure policy P1 from the internal zone to the external zone.
  3. Configure policy P2 to allow traffic between the internal zone and the gatekeeper in the external zone.
  4. Configure policy P3 to allow traffic between phones in the internal zone and the external zone.
  5. Configure policy P4 to allow traffic between phones in the internal zone and the gatekeeper in the external zone.

Results

From configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

For brevity, this show output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (...).

[edit]

user@host# show security policies

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

Verification

To confirm that the configuration is working properly, perform this task:

Verifying H.323 ALG Configurations

Purpose

Display information about active calls.

Note

H.323 counters for calls and active calls in the output to this show security command do not apply to the proprietary Avaya implementation of H.323. This is because Q.931 setup and connect messages are exchanged right after the phone is powered up and call creation and tear down is done by Facility messages.

Counters for calls and active calls are increased when the resources allocated for calls are increased—that is, messages belonging to the same call and that pass the firewall multiple times increment the counters. This applies when resources for a call need to be allocated multiple times. For example, in a two-zone scenario the setup and connect message pair allocates one call resource, and the active call counter is increased by one. But in a three-zone scenario the setup and connect message pair passes the firewall twice, each time allocating different call resources. In this case, the counter is incremented.

Action

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

Counters for H.245 messages received also will not be accurate in the case of H.245 tunneling. Because H.245 messages are encapsulated in Q.931 packets, the counter for H.245 messages received will remain zero even when there are H.245 messages. The Other H245 counter will, however, reflect these packet transmissions.

[edit]


user@host> show security alg h323 counters

Example: Using NAT with the H.323 ALG to Enable Incoming Calls

This example shows how to configure NAT with the H.323 ALG to enable calls from a public to a private network.

Requirements

Before you begin, understand H.323 ALGs. See Understanding H.323 ALG.

Overview

In a two-zone scenario with a server in the private zone, you can use NAT for incoming calls by configuring a NAT pool on the interface to the public zone.

In this example (see Figure 4), IP-Phone1 and a server called gatekeeper are in the private zone, and IP-Phone2 is in the public zone. You configure a static nat rule set and a source NAT pool to do NAT. You also create two policies, private-to-public and public-to-private, to permit ALG H.323 traffic from and to the private and public zones.

Topology

Figure 4 shows NAT with the H.323 ALG incoming calls.

Figure 4: NAT with the H.323 ALG—Incoming Calls
NAT with the H.323 ALG—Incoming
Calls

In this example, you configure source NAT as follows:

  • Create a static NAT rule set called gatekeeper with a rule called gatekeeper to match packets from the public zone with the destination address 1.1.1.25/32. For matching packets, the destination IP address is translated to the private address 10.1.1.25/32.

  • Define a source NAT pool called h323-nat-pool to contain the IP address range from 1.1.1.30/32 through 1.1.1.150/32.

  • Create a source NAT rule set called h323-nat with rule h323-r1 to match packets from the private zone to the public zone with the source IP address 10.1.1.0/24. For matching packets, the source address is translated to the IP address in h323-nat-pool.

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

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 with H.323 ALG to enable calls from a public to a private network:

  1. Configure interfaces.
  2. Configure zones and assign addresses to them.
  3. Create a static NAT rule set.
  4. Configure proxy ARP.
  5. Configure a source NAT rule set.
  6. Configure policies for outgoing traffic.
  7. Configure policies for incoming traffic.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show security zones, 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 H.323 ALG Status

Purpose

Verify that H.323 ALG is enabled on your system.

Action

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

user@host> show security alg status

Meaning

The output shows the H323 ALG status as follows:

  • Enabled—Shows the H323 ALG is enabled.

  • Disabled—Shows the H323 ALG is disabled.

Verifying Security ALG H.323 Counters

Purpose

Verify that there is a security counters for ALG H323.

Action

From operational mode, enter the show security alg h323 counters command.

Meaning

The sample output gives the rundown of security ALG H.323 counters expressing that, there are security counters for ALG H323.

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. View the Translation hits field to check for traffic that matches the rule.

user@host> show security nat source rule all

Meaning

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

Example: Using NAT with the H.323 ALG to Enable Outgoing Calls

This example shows how to configure static NAT with H.323 ALG to enable calls from a private to a public network.

Requirements

Before you begin, understand the H.323 ALG and its processes. See Understanding H.323 ALG.

Overview

In this example (see Figure 5), IP-Phone 1 and a server called gatekeeper are in the private zone and IP-Phone2 is in the public zone. You configure static NAT to enable IP-Phone1 and gatekeeper to call IP-Phone2 in the public zone. You then create a policy called public-to-private to allow ALG H.323 traffic from the public zone to the private zone and a policy called private-to-public to allow ALG H.323 traffic from the private zone to the public zone.

Topology

Figure 5 shows NAT with the H.323 ALG outgoing calls.

Figure 5: NAT with the H.323 ALG—Outgoing Calls
NAT with the H.323 ALG—Outgoing
Calls

In this example, you configure static NAT as follows:

  • Create a static NAT rule set called ip-phones with a rule called phone1 to match packets from the public zone with the destination address 1.1.1.5/32. For matching packets, the destination IP address is translated to the private address 10.1.1.5/32.

  • Define a second rule called gatekeeper to match packets from the public zone with the destination address 1.1.1.25/32. For matching packets, the destination IP address is translated to the private address 10.1.1.25/32.

  • Create proxy ARP for the addresses 1.1.1.5/32 and 1.1.1.25/32 on interface ge-0/0/1. This allows the system to respond to ARP requests received on the specified interface for these addresses.

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 static NAT with the H.323 ALG to enable calls from a private to a public network:

  1. Configure interfaces.
  2. Create zones and assign addresses to them.
  3. Configure static NAT rule set with rules.
  4. Configure proxy ARP.
  5. Configure a security policy for incoming traffic.
  6. Configure a security policy for outgoing traffic.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show security zones, 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 H.323 ALG Status

Purpose

Verify that H.323 ALG is enabled on your system.

Action

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

user@host> show security alg status

Meaning

The output shows the H323 ALG status as follows:

  • Enabled—Shows the H323 ALG is enabled.

  • Disabled—Shows the H323 ALG is disabled.

Verifying Security ALG H.323 Counters

Purpose

Verify that there is a security counters for ALG H323.

Action

From operational mode, enter the show security alg h323 counters command.

Meaning

The sample output gives the synopsis of security ALG H.323 counters expressing that there are security counters for ALG H.323.

Example: Setting H.323 ALG Endpoint Registration Timeouts

This example shows how to specify the endpoint registration timeout.

Requirements

Before you begin, understand and configure any Avaya H.323-specific features. See the Administrator Guide for Avaya Communication Manager, Avaya IP Telephony Implementation Guide, and Avaya Application Solutions IP Telephony Deployment Guide at http://support.avaya.com.

Overview

In Network Address Translation (NAT) mode, when endpoints in the protected network behind the Juniper Networks device register with the H.323 gatekeeper, the device adds an entry to the NAT table containing a mapping of the public-to-private address for each endpoint. These entries make it possible for endpoints in the protected network to receive incoming calls.

You set an endpoint registration timeout to specify how long an endpoint registration entry remains in the NAT table. To ensure uninterrupted incoming call service, set the endpoint registration timeout to a value equal to or greater than the keepalive value the administrator configures on the gatekeeper. The range is 10 to 50,000 seconds, the default value is 3600 seconds.

Configuration

GUI Step-by-Step Procedure

To specify the H.323 ALG endpoint registration timeout:

  1. Select Configure>Security>ALG.
  2. Select the H323 tab.
  3. In the Timeout for endpoints box, type 5000.
  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

  1. If you are done configuring the device, commit the configuration.

Verification

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

Example: Setting H.323 ALG Media Source Port Ranges

This example shows how to enable the H.323 ALG media source port feature.

Requirements

Before you begin, understand and configure any Avaya H.323-specific features. See the Administrator Guide for Avaya Communication Manager, Avaya IP Telephony Implementation Guide, and Avaya Application Solutions IP Telephony Deployment Guide at http://support.avaya.com.

Overview

The media source port feature enables you to configure the device to allow media traffic on a narrow or wide range of ports. By default, the device listens for H.323 traffic on a narrow range of ports. If your endpoint equipment allows you to specify a sending port and a listening port, you might want to narrow the range of ports the device allows media traffic on. This enhances security by opening a smaller pinhole for H.323 traffic. This example shows how to configure the device to open a wide gate for media traffic by enabling the media source port feature.

Configuration

GUI Step-by-Step Procedure

To enable the H.323 ALG media source port feature:

  1. Select Configure>Security>ALG.
  2. Select the H323 tab.
  3. Select the Enable Permit media from any source port check box.
  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 enable the H.323 ALG media source port feature:

  1. Set a narrow gate for media traffic by disabling the media source port for the H.323 ALG.
  2. If you are done configuring the device, commit the configuration.

Verification

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

Example: Configuring H.323 ALG DoS Attack Protection

This example shows how to configure the H.323 ALG DoS attack protection feature.

Requirements

Before you begin, understand and configure any Avaya H.323-specific features. See the Administrator Guide for Avaya Communication Manager, Avaya IP Telephony Implementation Guide, and Avaya Application Solutions IP Telephony Deployment Guide at http://support.avaya.com.

Overview

You can protect the H.323 gatekeeper from denial-of-service (DoS) flood attacks by limiting the number of Registration, Admission, and Status (RAS) messages per second it will attempt to process. Incoming RAS request messages exceeding the threshold you specify are dropped by H.323 Application Layer Gateway (ALG). The range is 2 to 50,000 messages per second, the default value is 1000.

Configuration

GUI Step-by-Step Procedure

To configure the H.323 ALG DoS attack protection feature:

  1. Select Configure>Security>ALG.
  2. Select the H323 tab.
  3. In the Message flood gatekeeper threshold box, type 5000.
  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 the H.323 ALG DoS attack protection feature:

  1. Configure the gatekeeper for the H.323 ALG and set the threshold.
  2. If you are done configuring the device, commit the configuration.

Verification

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

Understanding H.323 ALG Known Message Types

The H.323 standard is a legacy voice-over-IP (VoIP) protocol defined by the International Telecommunication Union (ITU-T). H.323 consists of a suite of protocols (such as H.225.0 and H.245) that are used for call signaling and call control for VoIP. There are three major processes in H.323:

  • Gatekeeper Discovery—An endpoint finds its gatekeeper through the gatekeeper discovery process, through broadcast or unicast (to a known IP and the well-known UDP port 1719).

  • Endpoint Registration, Admission, and Status—An endpoint registers to a gatekeeper and asks for its management. Before making a call, an endpoint asks its gatekeeper for permission to place the call. In both registration and admission phases, the Registration, Admission, and Status (RAS) channel is used.

  • Call Control and Call Setup—Calls can be established within a zone or across two zones, or even across multiple zones (multipoint conference). The call setup and tear down is performed through the call signaling channel whose TSAP is the well-known TCP port (1720). The call control, including opening/closing media channels between two endpoints, is performed through the call control channel whose TSAP is dynamically assigned from the previous call signaling process. H.245 messages are used in the call control channel, and are encoded using ASN.1.

H.225 RAS Signaling: Gatekeepers and Gateways

Registration, Admission, and Status (RAS), as described in the (ITU-T) H.323 standard, is the signaling protocol used between gateways or endpoints. The gatekeepers provide address resolution and admission control services.

RAS is the process by which H.323 gateways discover their zone gatekeepers. RAS communication is carried out through a UDP datagram on port 1718 (multicast) and 1719 (unicast). Endpoints use the RAS protocol to communicate with a gatekeeper. If an H.323 endpoint does not know its gatekeeper, then it can send a Gatekeeper Request (GRQ) message to seek the gatekeeper’s response. One or more gatekeepers might answer the request with either a Gatekeeper Confirmation (GCF) message or a Gatekeeper Reject (GRJ) message. A reject message contains the reason for rejection.

Table 1 lists the supported RAS gatekeeper messages.

Table 1: Gatekeeper Messages

Message

Description

GRQ (Gatekeeper_Request)

A message sent from an endpoint to a gatekeeper to "discover" gatekeepers willing to provide service.

GCF (Gatekeeper_Confirm)

A reply from a gatekeeper to an endpoint that indicates the acceptance to communicate with the gatekeeper’s RAS channel.

GRJ (Gatekeeper_Reject)

A reply from a gatekeeper to an endpoint that rejects the endpoint request.

RAS Registration and Unregistration

Registration is the process by which the gateways, terminals, and multipoint control units (MCUs) join a zone and inform the gatekeeper of their IP and alias addresses. Every gateway can register only one active gatekeeper.

The registration takes place after the endpoint determines and confirms the gatekeeper to communicate, by sending a Registration Request (RRQ) message. The gatekeeper then responds with a Registration Confirm (RCF) message, thereby making the endpoint known to the network.

Table 2 lists the supported RAS registration and unregistration messages.

Table 2: Registration and Unregistration Messages

Message

Description

RRQ (Registration_Request)

A message sent from an endpoint to a gatekeeper. Registration requests are predefined in the system’s administrative setup.

RCF (Registration_Confirm)

A reply from a gatekeeper that confirms an endpoint’s registration in response to an RRQ message.

RRJ (Registration_Reject)

A reply from a gatekeeper that rejects an endpoint’s registration.

URQ (Unregister_Request)

A message sent from an endpoint or a gatekeeper requesting to cancel a registration.

UCF (Unregister_Confirm)

A reply sent from an endpoint or a gatekeeper to confirm that the registration is canceled.

URJ (Unregister_Reject)

A message that indicates that the endpoint is not preregistered with the gatekeeper.

RAS Admissions

Admission messages between endpoints and gatekeepers provide the basis for call admissions and bandwidth control. The gatekeeper then resolves the address either with confirmation or rejection of an admission request.

Table 3 lists the supported RAS admission messages.

Table 3: Call Admission Messages

Message

Description

ARQ (Admission_Request)

An attempt by an endpoint to initiate a call.

ACF (Admission_Confirm)

A positive response from a gatekeeper that authorizes an endpoint to participate in a call.

ARJ (Admission_Reject)

A message sent from a gatekeeper rejecting the ARQ message that initiates a call.

RAS Location

Location Request (LRQ) messages are sent by either an endpoint or a gatekeeper to an interzone gatekeeper to get the IP addresses of different zone endpoints.

Table 4 lists the supported RAS location request messages.

Table 4: Location Request Messages

Message

Description

LRQ (Location_Request)

A message sent to request a gatekeeper for contact information of one or more addresses.

LCF (Location_Confirm)

A response sent by a gatekeeper that contains call signaling channel or RAS channel addresses.

LRJ (Location_Reject)

A response sent by gatekeepers that received an LRQ for which the requested endpoint is not registered.

RAS Bandwidth Control

Bandwidth control is invoked to set up the call, and is initially managed through the admission messages (ARQ/ACF/ARJ) sequence.

Table 5 lists the supported RAS bandwidth control messages.

Table 5: Bandwidth Control Messages

Message

Description

BRQ (Bandwidth_Request)

A request sent by an endpoint to a gatekeeper to increase or decrease call bandwidth.

BCF (Bandwidth_Confirm)

A response sent by a gatekeeper to confirm the acceptance of a bandwidth change request.

BRJ (Bandwidth_Reject)

A response sent by a gatekeeper to reject a bandwidth change request.

RAS Status Information

A gatekeeper uses an Information Request (IRQ) message to determine the status of an endpoint. The RAS protocol is used to determine whether the endpoints are online or offline.

Table 6 lists the supported RAS status information messages.

Table 6: Status Information Messages

Message

Description

IRQ (Information_Request)

A message sent from a gatekeeper to request status information of its recipient endpoints.

IRR (Information_Request_Response)

A response sent by endpoint to a gatekeeper in response to an IRQ message. It determines whether the endpoints are online or offline.

IACK (Info_Request_Acknowledge)

A message sent by a gatekeeper to acknowledge the receipt of an IRR message from an endpoint.

INACK (Info_Request_Neg_Acknowledge)

A message sent a gatekeeper if an information request message is not understood.

RAS Disengage Information

An endpoint sends a Disengage Request (DRQ) message to a gatekeeper in the event of a call drop.

Table 7 lists the supported RAS disengage messages.

Table 7: Disengage Request Messages

Message

Description

DRQ (Disengage_Request)

A status request sent from an endpoint to a gatekeeper when a call ends.

DCF (Disengage_Confirm)

A message sent by a gatekeeper to confirm receipt of the DRQ message from an endpoint.

DRJ (Disengage_Reject)

A message sent by a gatekeeper that rejects a disengage confirmation request from an endpoint.

H.225 Call Signaling (Q.931)

H.225 is used to set up connections between H.323 endpoints. The (ITU-T) H.225 recommendation specifies the use and support of Q.931 messages.

H.225 call signaling supports the following messages:

  • Setup and Setup Acknowledge

  • Call Proceeding

  • Connect

  • Alerting

  • User Information

  • Release Complete

  • Facility

  • Progress

  • Status and Status Inquiry

  • Notify

H.245 Media Control and Transport signaling

H.245 handles end-to-end control messages between H.323 endpoints. This control channel protocol establishes the logical channels for transmission of audio, video, data, and control channel information.

H.245 supports the following messages:

  • Request

  • Response

  • Command

  • Indication

Understanding H.323 ALG Unknown Message Types

Unknown H.323 message type feature enables you to specify how unidentified H.323 messages are handled by the device. The default is to drop unknown (unsupported) messages.

You can protect the H.323 gatekeeper from denial-of-service (DoS) flood attacks by limiting the number of Registration, Admission, and Status (RAS) messages per second it will attempt to process. Incoming RAS request messages exceeding the threshold you specify are dropped by the H.323 Application Layer Gateway (ALG). The range is 2 to 50,000 messages per second, the default value is 1000.

We do not recommend permitting unknown messages because they can compromise security. However, in a secure test or production environment, unknown H.323 message type command can be useful for resolving interoperability issues with disparate vendor equipment. Permitting unknown H.323 messages can help you get your network operational, so that you can analyze your voice-over-IP (VoIP) traffic to determine why some messages were being dropped. The unknown H.323 message type feature enables you to configure the device to accept H.323 traffic containing unknown message types in both Network Address Translation (NAT) mode and route mode.

Note

Unknown H.323 message type option 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.

Example: Allowing Unknown H.323 ALG Message Types

This example shows how to configure the device to allow unknown H.323 message types in both route and NAT modes.

Requirements

Before you begin, understand and configure any Avaya H.323-specific features. See the Administrator Guide for Avaya Communication Manager, Avaya IP Telephony Implementation Guide, and Avaya Application Solutions IP Telephony Deployment Guide at http://support.avaya.com.

Overview

This feature enables you to specify how unidentified H.323 messages are handled by the device. The default is to drop unknown (unsupported) messages. The Enable Permit NAT applied option and the permit-nat-applied configuration statement specify that unknown messages be allowed to pass if the session is in NAT mode. The Enable Permit routed option and the permit-routed configuration statement specify that unknown messages be allowed to pass if the session is in route mode. (Sessions in transparent mode are treated as route mode.)

Configuration

GUI Step-by-Step Procedure

To configure the device to allow unknown H.323 message types in both route and NAT modes:

  1. Select Configure>Security>ALG.
  2. Select the H323 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 device to allow unknown H.323 message types in both route and NAT modes:

  1. Specify that unknown messages be allowed to pass if the session is in NAT mode.
  2. Specify that unknown messages be allowed to pass if the session is in route mode.
  3. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show security alg h323 command and the show security alg h323 counters command.

Release History Table
Release
Description
Starting with Junos OS Release 17.4R1, the gateway-to-gateway call feature is supported on the H.323 Application Layer Gateway (ALG).
Starting with Junos OS Release 17.4R1, the H.323 Application Layer Gateway (ALG) supports NAT64 rules in an IPv6 network.