Rec. H.501 and "GEF" parameter repository

[Horvath Ernst]

Guys,

A little late, yet, my $0.02.

Having available a selection of destinations is like having available a
selection of routes in traditional (circuit switched) telephony. The Basic
Call Model provides for the obtaining of the route list (from Number
Analysis if I remember) and the placing of the call on a selected route.
The result of the call attempt may cause the call to be aborted (e.g. cause
= BUSY) or an alternate route selected (e.g. cause = Network Congestion)
and retried. This process is defined elsewhere (q.76x, Q.1224, ETSI 3xx
xxx) however, there are H.323 specific instances (e.g. reason = Gateway
Resourses).

Text might be added to refer to the "specified elsewhere" places, and to
spell out the H.323 specific instances.

Of course, time may alter the process, such as if failure to establish a
TCP connection is by timeout (which can be quite long) might result in
timer expiry for call establishment.

Douglas

At 02:28 04/03/2002 -0500, Paul E. Jones wrote:
>Terry,
>
>> > H.225 v4 contains this text:
>> > "7.11.2       AdmissionConfirm (ACF)
>> > ... alternateEndpoints - A sequence of prioritized endpoint alternatives
>> > for destCallSignalAddress or destinationInfo."
>> >
>> > The feature seems intended to support robustness through redundancy in
>> > large networks,
>> > where there may be more than one media gateway capable of serving the
>same
>> > AdmissionRequest (ARQ).
>
>Alternate endpoints are Gateways that may be able to terminate the same
>call.
>
>> > This would accord with the support for alternate gatekeepers in H.323
>v4:
>> > "7.2.6        Alternate gatekeeper procedures
>> > For the purposes of ensuring system availability, redundancy, and
>> > scalability, the Gatekeeper may provide the RAS signalling function by
>> > utilizing multiple physical or logical devices, referred to as Alternate
>> > Gatekeepers. If the endpoint supports the Alternate Gatekeeper
>procedures
>> > defined in this section, it should include the supportsAltGK field in
>the
>> > GRQ and RRQ messages.
>> > When an endpoint initiates communication with the Gatekeeper, it may be
>> > provided with a list of Alternate Gatekeepers via the GCF message. If
>the
>> > Gatekeeper does not respond to the subsequent RRQ, the endpoint shall
>> > attempt to register with the Gatekeeper using the list of Alternate
>> > Gatekeepers provided in the GCF. If no Alternate Gatekeeper responds,
>the
>> > endpoint shall reinitiate the Gatekeeper discovery process."
>> >
>> > The problem is that there are no procedures specified for the use of
>> > alternateEndpoints.
>
>You're right... and we should probably add such text.
>
>> > What is it that causes a caller to terminate its Setup attempt to one
>> > destination and to initiate a Setup attempt to the next destination in
>> > priority order?
>
>The causes may be anything from the inability to reach the destination GW to
>rejection of the call with specific reasons.  Of course, this is not
>defined, but should be.
>
>> > Can we presume that the critical event is receiving a ReleaseComplete?
>
>I think that it's reasonable to assume that we should be able to direct the
>call to another GK based on a ReleaseComplete if the reasons match a certain
>set.  We would not want to re-route the call for every reasons (such as
>security denial), but some failure codes should result in a re-route.
>
>> > Then how do we determine whether the release reason or cause code is
>final
>> > (no further Setup should be sent) or not (try another destination)?
>
>This needs to be defined.
>
>> > Some calls should end after an announcement is played, eg. "The number
>you
>> > are calling has been disconnected",
>> > and will never succeed no matter how many alternative endpoints are
>> > attempted.
>> >
>> > If the intention of alternateEndpoints has already been clarified
>> > somewhere, please point me to it and excuse my ignorance.
>
>I think we do need clarification in this area and would invite you to
>provide such clarification.  Another question that should be addressed is
>whether the GW should send an DRQ and another ARQ before attempting to place
>a call to the alternate endpoint.  I don't think that is specified, but my
>feeling on that is "no, it should not."
>
>Paul
>