SGCP: Why not just use H.323
One of the first applications of Internet Telephony that we studied was the
transparent replacement of long distance telephone circuits. In that
application, a call is passed by a switch to a "pseudo switch", in fact a
system composed of SS7 gateways and Trunking Gateways that appears and
acts like a switch. Our original idea was indeed to use a standard solution,
that is H.323. The original designs looked very much like the following
picture:
In this configuration, the telephone switches send signalling information
to an SS7 gateway. The information is somehow relayed to the trunking
gateway, which will then use H.323 to set up a call over the Internet to the
destination gateway.
We tried very seriously to make this work, but we stumbled on a number
of problems:
- There is no established standard for the relaying of SS7/ISUP messages
between the SS7 gateway and the trunking gateway. This pretty much means that
customers must buy both types of equipments from the same vendor, or from a
single vendor coalition.
- The most common solution to the relaying problem involves a conversion
from SS7 to ISDN/Q.931 in the SS7 gateway, then a relay of the Q.931 messages
over a TCP-IP connection to the Trunking Gateway. ISDN/Q.931 is often chosen
because a subset of this protocol is used in H.323/H.225, and also because
gateway manufacturers often support ISDN/PRI interface. This translation,
however, has two draw-backs:
- Using translators and then TCP may add significant delays to the
signalling path.
- Using translation implies a loss of information. Some of the SS7/ISUP
procedures, such as continuity tests, are not supported in Q.931. They can
only be disabled when the telephone switch and the gateways are operated by
the same entity, but this by no means the most common cases. In practice,
the relaying protocol has to be modified to incorporate missing procedures
on top of Q.931.
- The signalling capabilities of H.323 are only a subset of SS7/ISUP. Here,
again, protocol translation leads to a loss of information. For example, the
subset of Q.931 defined in H.323 does not have any provision for continuity
testing, for end to end information exchange or for the suspend/resume
procedure.
- Using H.323, by itself, also adds significant delays on the signalling
path. In a standard operation, the calling gateway has to do a transaction
with a gatekeeper, then set up a TCP-IP connection to the destination, then
transmit the call. The called gateway should also do a transaction with a
gatekeeper prior to accepting the call. This results in a total of
four network transactions.
- Because H.323 is by essence an end-to-end protocol, all the call
models have to be programmed inside the trunking gateways. But, in
practice, trunking gateways are developed on real-time platforms, where
you definitely don't like to port complex telephony software such as SS7/ISUP
or AIN/TCAP.
This analysis leads us to a model were the complex software is developed in a
call agent, using regular computer server platform, as
described in the following picture:
SGCP was developed to organize the dialogue between the call agent and the
gateways. This organization has several advantages:
- The call agent, in a long distance service environment, can simply relay
ISUP messages. Delays are small -- we only need two network transactions to
seize the circuits on both sizes. Because there is no translation, we obtain
complete ISUP transparency.
- With SGCP, the call agent can implement complex signalling procedures,
call models and advanced intelligent network services, while the gateways
can concentrate on a single task, the translation of audio signals from
digital or analog circuits to Internet packets.
Back to the SGCP FAQ
Back to the SGCP page
|
