SGCP: Frequently Asked Questions
- Could you not just use H.323?
That was in fact our initial idea. But we found circumstances, where a
structure based on a call agent was more adequate. This is in particular
the case of long distance services.
- Do you intend to replace H.323 ?
Definitely not. Just look at the picture above, which shows the
relaying of a call between an SGCP controlled gateway and an H.323 agent.
The combination of gateways plus call agent forms a distributed H.323 system,
which is perfectly conforming to the H.323 standard. Click
for a detailed study of the interconnection.
- If not H.323, why not SIP, then?
In fact, when we realized that we could not use H.323 between
the call agent and the gateways, we tried to base the design of SGCP on SIP.
But we stumbled on the fact that SIP is a peer to peer protocol, while we
needed a master slave protocol. However, interworking between SIP and SGCP is very easy, as shown in this study
- You relay the call through the Call Agent, and then you use SGCP to
remote control the gateway. Doesn't this results in a lot of messaging,
and very slow response times?
We have studied this in great detail, and the basic answer is no. In
fact, even in a fully distributed solutions, the gateways have to get help
from a third party, a gatekeeper in H.323. Our study shows that we can
set up calls as fast or faster than H.323, even if the version "fast start"
procedure is used, and that it is much easier to introduce additional
service. Click here to look at the details.
- Why are you using UDP, rather than TCP?
The short answer is delays, scalability and failover.
- OK, we use UDP. So packets can be transmitted out of order.
Don't we risk to loose synchronisation?
No. We actually studied that in great detail. The Notification
Request and Notify command are designed to entirely eliminate
this risk.
- Why do you use text encodings, rather than binary encodings?
The are definitely two schools in network protocol design. Binary
transmission supposedly results in better performance. Text based protocols
are easier to debug, to extend and to maintain. In fact, we have some
evidence that the performance loss of text transmission is minimal, based on
several years of research.
- Can we used SGCP to control voice over packet, not just voice over IP?
Sure! In fact, there are already some studies on how to extend SGCP to control voice over ATM gateways.
- How can we perform continuity tests?
We have several provisions in SGCP for performing two kinds of
continuity tests. This can be done either at the request of an adjacent switch,
or at the initiative of teh call agent. As in ISUP, continuity test can be
intertwined with the call set-up.
- What if the signalling is not ISUP?
The short answer is that you have to bring the signalling to the
call agent, which has indeed to be programmed with adequate software. If the
call agent understands, for example, Q.931, it can use SGCP to
program the handling of trunks according to Q.931 signalling. The gateway
does not even have to know that whether the signalling was Q.931 or ISUP.
- A single call agent for an entire network? You must be kidding!
Well, even in the most bell-shaped dreams, nobody really thinks that
a single server can control the whole telephone network. The call agent
can indeed be implemented as a distributed system, using proprietary
solutions. There is no standard yet for CA-CA communication. One can however
use H.323 or SIP.
- Could we support multimedia terminals?
Yes. SGCP uses the Session Description Protocol standard to document
the characteristics of a connection. The current gateways are strictly for
telephony and only use the audio components of SDP. But SDP was designed to
support multimedia communciations, a feature that multimedia gateways could
easily use. SDP is specified in RFC 2327..
- Can we use SGCP for controlling Remote Access Servers?
Not the current version. But we are definitely interested by SGCP extensions for Remote Access Server.
Back to the SGCP page
|
