|
|
|
Comparing SGCP and H.323The appended documents provide a description of call set-up scenarios between residential gateways and classic telephones. We developed the same scenarios using either H.323 or SGCP. We made the following hypothesis:
Back to the top of the page Back to the SGCP home page Incoming call set-up: the delay to ring-backThe combination of gateways and gatekeepers should be viewed, from the phone network, as a local switch. This does not only imply that the gateways should have a conformant implementation of standard protocols such as SS7 MTP2, MTP3 and ISUP. It also requires that the gateways respond to SS7 messages such as call initiation requests in a delay that is on par with standard switches. A key element of that delay is the time that elapses between the end of the dialing sequence and the reception of the ring-back tones. If, for an IP telephony network, that delay was consistently longer than that of phone switches, the callers would notice it, and the network would develop a bad reputation. In fact, the connecting switches would raise alarms when this delay exceeds a limit, typically set to 2 seconds. Too many of alarms could lead to contractual difficulties between the Internet Telephony network and the incumbent carriers.The call set-up delays are summarized, for the two configurations, in
the following tables:
The comparison, here, is clearly in favor of SGCP, which requires only 2 network round-trips, versus 4 for the H.323 configuration. In the SGCP case, we have a transaction from the call agent to each of the gateways, while in the H.323 case we have two RAS transactions, one for each gateway, and a Q.931 set-up request, which can only be exchanged after setting up a TCP-IP connection between the gateways. Assuming a network round-trip of 60 ms, and allocating 20 ms for processing in the various nodes, this means that the ACM response will be sent about 150 ms after the arrival of the IAM if we use SGCP, versus 260 ms if we use H.323, above the 200 ms threshold considered as "normal" for responding switches. This is however a best case scenario, which does not take transmission errors into account. If any message is lost, it will have to be repeated. The repetition strategies vary with the different protocols. In the case of both H.323/RAS and SGCP, the exchanges are carried over UDP, and the repetition will be managed by the application software. This software can use arbitrarily short timers, that can be based, for example, on the average round-trip delay observed by the application. An error on an SGCP or RAS message could thus be corrected in about 100 ms, resulting on global delays of 250 or 360 ms, respectively. There are the same numbers of UDP messages in both scenarios, and the exposure is thus equivalent. In addition to 4 UDP messages, the H.323 scenario also features 4 or 5 TCP messages that are not present in the SGCP scenario, depending on whether the initial ACK is or is not piggybacked in the "setup" message. This is a sizeable risk, at least if the gateways use a "standard" implementation of TCP. With such standard implementations, the initial retransmission timer is set to 3 seconds. A single transmission error would then be sufficient to boost the IAM-ACM delay over 3 seconds, which is indeed a very poor service. To summarize, the SGCP scenario uses only half the messages that H.323
requires, the ACM message is returned almost twice faster, and the exposure
to transmission errors and retransmission delays is twice less.
Back to the top of the page Back to the SGCP home page Incoming call set-up: from off-hook to talkingThe phase that we analyzed previously is only the first component of the call set up. Once that phone has started to ring, a variable time will elapse until the ringed party picks the phone - if indeed it decides to do so. The next measure of delay is thus the "call establishment response time", i.e. the time that elapses between the moment when the call user picks the phone and the moment when both parties can start speaking. We have displayed the corresponding actions and exchanges in the following two diagrams.
This diagram clearly shows that the centralized model of SGCP has a cost. During the initial set-up phase, that cost was more than matched by the need in the H.323 case to performed RAS transaction with a centralized server, and also by the need to set up a TCP-IP connection. But in this example, we show that for SGCP the off-hook information must travel to the call agent, and that the call agent must then prepare the trunking gateway before relaying the ANM message. As a consequence, the SGCP example requires one more roundtrip than the H.323 example. Without diving into subtleties, we should point out that this roud-trip
could in fact be avoided if the call agent was willing to perform an "optimistic
call set-up." The purpose of the synchronization event is to place the
trunk termination at the trunking gateway in full duplex mode. In our example,
the sending of the ACM message is immediately followed by a "modify transaction"
that completes the RTP connection between the two gateways but leaves it
in receive only mode. There is no technical difficulty in opening a full
duplex RTP circuit at that stage - there is only a slight chance of letting
the users speak "too soon", i.e. before the call agent has started accounting
for the call.
Back to the top of the page Back to the SGCP home page Internal call set-up: from digits to ring backStudying the set-up of a call exposes some of the features of a decentralized control, with autonomous gateways using H.323, versus a centralized control using SGCP. We have detailed the sequence of events in the following tables:
The impact of a centralized versus decentralized architecture is obvious during the first phase of the scenario, the collection of digits. With autonomous H.323 gateways, all actions are local, while with SGCP we will get a set of explicit interactions:
The H.323 gateways can obviously provide the same functionality and the same services. However, the H.323 standard has been primarily designed to support intelligent terminals equipped with extensive graphical user interfaces. Users of plain old black telephones cannot point and click, or press a "send" button when the number is complete. In order to support plain telephone terminals and RJ11 connectors, the gateways will have to be provisioned with a digit-map to collect the dialed numbers. This provisioning is outside the scope of the existing H.323 standard, which may result in incompatibilities between different solutions. Once the digits have been dialed, SGCP requires 2 round trip delays before the called telephone rings, and 3 round trip delays before the ringing tones are perceived by the calling user. The H.323 case requires 3.5 round trip delays before the phone rings, and 4 delays before the ringing tones are perceived by the calling user. The SGCP solution will result in a faster response time, and also in a lesser variability, as explained in the previous example. When the call party goes off hook, the call is established in 0.5 round trip delays in the H.323 example, and in 1 round trip delay in the SGCP case. There is a small advantage for the H.323 case. That advantage is however mitigated by the characteristic of TCP. Should an error occur, SGCP can repeat using very short timers, while a typical TCP connection would typically use long timers: there were not enough messages exchanged to correctly "train" the round-trip-time estimator. In summary, we show that SGCP uses more messages to perform the acquisition
of signals (16 versus 12 or 13), but sets up connection as fast or faster
than H.323, while providing functionalities that are not covered by the
H.323 standards.
Back to the top of the page Back to the SGCP home page Call release: delays and proceduresCall termination is another part of the user experience. In North-America, the handling of the on-hook event depends on which side hangs up first. If the caller hangs up, the call is terminated immediately. If the called party hangs up first, the call should be suspended. It will be terminated either after a time-out period, or if the caller party hangs up. If the called party hangs down the phone before the timer or the release has occurred, the call is resumed and both party can go on speaking.In the following two tables, we detail the termination procedures for
the H.323 and SGCP scenarios.
The first observation that one can derive from these tables is that H.323 does not support the Suspend/Resume procedure. In our diagram, we assumed that the gateway would simply emulate it by starting a timer when the phone goes on hook, without passing any signalling message. This may or may not be a valid assumption; it depends indeed of local decisions by the implementers of the gateways. They could well choose to immediately release the call when the user goes on-hook, a standard procedure outside of North America. Nothing would break, but the user perception will be changed, probably resulting in a market disadvantage. SGCP does not have this problem: the call agent can issue standard ISUP commands, and fully support the Suspend/Resume procedure. It can also use a "modify connection" request to instruct the TGW to stop sending RTP packets on the suspended connection, thus saving some bandwidth. If the user was to take back the call, the call agent would send the Resume command through SS7, and would also send another "modify connection" request to reactivate the connection. This behavior, however, does not have to be hard-wired in the gateways. In a system deployed in Europe, the call agent could easily be programmed to terminate the call immediately after the phone is hung up. The second observation is that the Release Confirmation comes back almost immediately after reception of the Release request in the H.323 case, while it has to wait one round trip delay in the SGCP case. This is a normal consequence of the architecture: an autonomous gateway can take immediate decisions, while the call agent must synchronize with the gateway to make sure that the resource is released. A single round-trip delay of about 60 ms, however, will not present a major problem: Q.764 specifies that the REL message is repeated if the RLC message is not received before a timer elapses, but the suggested value for that timer is 15-60 seconds. The third observation shows the overall number of messages triggered by the release request. After reception of the REL, SGCP generates four messages, corresponding to two exchanges over UDP. In the H.323 case, we also have 4 messages for two RAS exchanges over UDP, but in order to release the H.225/Q.931 connection we need an additional 3 to 4 messages, depending of whether or not we can piggyback the FIN request on the "Release Complete" message. To summarize, we see on this example that SGCP is more flexible than
H.323, and allows us to properly implement the Suspend/Resume procedure.
The external RLC response is send slightly faster by autonomous H.323 gateways,
but the total message load is lower with SGCP than with H.323.
Back to the top of the page Back to the SGCP home page Three ways calling and call transferModern telephone networks don't just offer basic calling facilities. They also implement additional services such as call waiting, three-ways calling or call transfer. In the following diagram, we will observe how these services could be implemented using the H.323 and SGCP architecture.The sequence of event that we will present will be the same in both cases:
The two diagrams are direct consequences of architecture choices. In the H.323 case, all interactions are local: the response is immediate, and no messages are exchanged. In the SGCP case, the events such as flash-hook have to be transmitted to the call agent, which will then instruct the gateway to provide a dialtone. In our example, the dialtone provision is carried in a connection modification request, which will place the previous connection in inactive mode. A similar command is sent, in parallel, to the other gateway. This ensure that none of these gateways will send any RTP packets while the connection is on hold. Local actions at the H.323 gateway do not provide any such insurance.
It should be possible to use H.245 command to delete the logical channels
that are not active, but this implies the opening of an additional TCP-IP
connection - until now, we had assumed use of the "fast connect" procedures,
when the channel creation requests are piggybacked in the H.225/Q.931 call
set-up requests. A possible implementation could look like the following
diagram:
We will not explore this option any further, in particular because we would not be able to fully examine its impact on the call transfer scenario that we will examine later on. If it was implemented, the advantage of strictly local interaction that we granted to the H.323 scenario in the previous diagram would be lost. After provision of the dialtone, the secondary call is established with
another residential gateway, following the procedures that were described
in the previous section. After talking for some time, the user will issue
a flash-hook command to move to a three-ways calling scenario. The sequence
of actions is described in the following diagrams:
In both cases, we have supposed that the residential gateways is capable of bridging the calls locally, for example by relaying RTP packets. With this hypothesis, the move to three ways call is strictly local in the H.323 case. It requires three transactions in the SGCP architecture: the command must be notified to the call agent, which will then modify the connection that had been placed on hold, changing its mode from "inactive" to "full-duplex." (In the H.323 case, if we had used H.245 delete logical channel commands, we should now issue a create logical channel command.) After some time in three-ways calling mode, the user may wish to get
out of the call, in effect completing a call transfer between the caller
and the third party. The following diagrams detail the handling of the
transfer according to H.323 (using procedures detailed in H.450.2) and
according to SGCP:
Saying that the H.323 diagram looks complex is an understatement. Depending on whether TCP ACKs can or cannot be piggybacked with data packets, the on hook action generates 28 to 32 messages, compared to 10 messages with SGCP. This has consequences on transfer delays: the transferred party can speak after 5 round trip delays in the H.323 case, versus only 2 in the SGCP case. Yet, the H.323 diagram assume that we can use the "fast connect" procedure. If we had used H.245 connections in order to create and delete logical channels, we would see additional messages to terminate these connections. The call transfer example shows very well the advantages of the SGCP architecture. Because gateways are simple, the call agent can modify the calls at will, creating and deleting connections. In our example, it would have been easy to implement a "music on hold" service, by simply redirecting the incoming connection to a music source. In fact, SGCP allows the call agent to implement a number of services that use temporary transfers, for example to an interactive voice response server. The end to end approach of H.323 provide good response times in the simple cases, but generate a high message load when several systems must be synchronized. A large part of the overhead derives from the use of TCP, instead of UDP. We should not that H.323 also allows for "Gatekeeper routed calls,"
an architecture in fact very similar to the "call agent" approach. However,
the use of TCP limits the usefulness of this option. Typical platforms
can only support a limited number of TCP connections, typically a few hundred,
maybe a few thousands. This fails short of the scaling requirements of
large systems, which must support thousands of calls. Moreover, the use
of TCP ties the fate of the call to the fate of the supporting platform.
Should a gatekeeper fail, the established calls will be lost even if a
hot stand by was available, because the underlying TCP connection would
break.
Back to the top of the page Back to the SGCP home page |
| Home | Back | Top of Page | Feedback | www.telcordia.com |
| © 1999 - 2005 Telcordia Technologies, Inc. |