H.225/Q.931 Call Signaling

Assuming a slow start connection procedure, the H.225 protocol defines the two important stages of call setup: Call signaling and RAS. Call signaling describes standards for call setup, maintenance and control, and teardown. A subset of Q.931 call signaling messages are used to initiate connections between H.323 endpoints, over which real-time data can be transported. The signaling channel is opened between an endpoint-gateway, a gateway-gateway, or gateway-gatekeeper prior to the establishment of any other channels. If no gateway or gatekeeper is present, H.225 messages are exchanged directly between the endpoints.

What Is the Difference Between QSIG and Q.931?

Initially, PBXs only connected via trunk lines to the PSTN. Then, people begin connecting PBXs with other PBXs over private leased lines (tie-lines) in order to save toll charges. This worked so well that these same people decided to form a single logical PBX out of a number of smaller switches. In order to provide all the extra features that callers had come to expect, supplementary signaling functionality was added to the protocols used to connect the switches. DPNSS describes this signaling. DPNSS is an industry standard interface defined between PBXs.

Q.931, also a standard, is designed to work between the PSTN and a PBX. It does not support the same features and services as DPNSS. QSIG (Q Signaling) is the European Computer Manufacturers’ Association standard for PBX-to-PBX connections based on ISDN PRI. It’s largely Q.931, with extensions for additional PBX features. QSIG is based on, and also supports many of the same features and services as DPNSS. QSIG is used to tunnel PSTN signaling messages over H.323 to another PSTN network transparently, as if the two PSTN networks were one and the same.

H.225 messages are encoded in binary ASN.1 PER (Packed Encoding Rules) format. Although the H.225.0 signaling channel may be implemented on top of UDP, all entities must support signaling over TCP port 1720.

Note

Signaling traffic is binary encoded using ASN.1 (Abstract Syntax Notation One) syntax and per encoding rules. ASN.1 is not a programming language. It is a flexible notation that allows one to define a variety of data types. ASN.1 theoretically allows two or more dissimilar systems to communicate in an unambiguous manner. Frankly, this aim is more difficult than it might seem at first. ASN.1 encoding rules are sets of rules used to transform data specified in the ASN.1 language into a standard format that can be decoded on any system that has a decoder based on the same set of rules. The H.323 family of protocols is compiled into a wire-line protocol using PER. PER (Packed Encoding Rules), a subset of BER, is a compact binary encoding that is used on limited-bandwidth networks. PER is designed to optimize the use of bandwidth, but the tradeoff is complexity—decoding PER PDUs has led to problems due to a number of factors including issues with octet alignment (PER encoding can be aligned or unaligned), integer precision (at times, a PER value may not contain a length field), and unconstrained character strings.

The H.225 protocol also defines messages used for endpoint-gatekeeper and gatekeeper-gatekeeper communication—this part of H.225 is known as RAS (Registration, Admission, Status), and unlike call signaling, runs over UDP. RAS is used to perform registration, admission control, bandwidth status changes, and teardown procedures between endpoints and gatekeepers. A RAS channel, separate from the call setup signaling channel, is used to exchange RAS messages. This second signaling channel is opened between an endpoint and a gatekeeper prior to the establishment of additional channels.

Establishing a call between two endpoints requires a different connection schedule depending upon what entities are involved in the session. For direct connections between endpoints, two TCP channels are set up between the endpoints: one for call setup (Q.931/H.225 messages) and one for capabilities exchange and call control (H.245 messages). First, an endpoint initiates an H.225/Q931 exchange on a TCP well-known port (TCP 1720) with another endpoint. Several H.225/Q.931 messages are exchanged, during which time the called phone rings. Successful completion of the call results in an end-to-end reliable channel that supports the first of a number of H.245 messages. At the end of this exchange the called party picks up the receiver.

Note that the first of these signaling messages, the H.225.Q.931 Call Setup message (see Figure 1), has been the focus of extensive security vulnerability studies by the Oulu Secure Programming Group.

Figure 1: H.225/Q.931 Signaling

Notes from the Underground…PROTOS Suite

In 2001–2002, The University of Oulu Secure Programming Group (OUSPG) tested the effects of sending modified Setup-PDUs to a number of differing vendor H.323 implementations. The H.225 Setup-PDU is an excellent test candidate for several reasons. The Setup-PDU contains many information elements, whose length and type are variable; the Setup PDU is normally the first packet exchanged during H.323 communication; and affected systems can be quickly rebooted for additional testing. OUSPG prepared a test suite containing approximately 4500 modified Setup-PDUs, and fed these to each tested H.323 device. They found that many systems that implement H.323 are vulnerable to one or more of these malformed PDUs.

These failures result from insufficient bounds checking of H.225 messages as they are parsed and processed by affected systems. These errors are due primarily to problems in low-level byte operations with vendor ASN.1 PER/BER PDU decoders, as mentioned earlier. Depending upon the affected system and implementation, these attacks result in system crash and reload (DoS), or in the case of systems that filter these data (such as Microsoft ISA server), execution of code within the context of the security service. The developers of the PROTOS suite have moved on to form a company called Codenomicon and have expanded their suite to cover more use cases and more protocols.

If a gatekeeper is present between the endpoints (a more common scenario), then H.225 RAS signaling precedes the Q.931 signaling and abides by the sequence diagram shown in Figure 2.

Figure 2: H.225/Q.931 RAS

These messages are used to register with a gatekeeper and to request permission to initiate the call:

• Gatekeeper Request (GRQ) The GRQ packet is unicast in order to discover whether any gatekeepers exist. This requires that the gatekeepers IP address is configured on the endpoint. If this is not configured, the endpoint can fall back to multicast discovery of the gatekeeper.
• Gatekeeper Confirm or Reject (GCF/GRJ) Reply from the gatekeeper to endpoint that rejects the endpoint’s registration request. Often due to configuration problems.
• Registration Request (RRQ) Request from a terminal or gateway to register with a gatekeeper.
• Registration Confirm or Reject (RCF/RRJ) Gatekeeper either confirms or rejects.
• Admission Request (ARQ) Request for access to packet network from terminal to gatekeeper.
• Admission Confirm or Reject (ACF/ARJ) Gatekeeper either confirms or rejects. If confirmed, the transport address and port to use for call signaling are included in the reply.

There are supplementary messages defined in the H.225/RAS specification that are used to request changes in bandwidth allocation, to reset timers, and for informational purposes. After the gatekeeper confirms the admission request, call signaling can begin. Signaling proceeds in the same manner as in Figure 2.

Note

We have found privately that flooding multiple, malformed GRQ (Gatekeeper Request) packets to the gatekeeper results in the disconnection of a number of vendor’s IP phones.