Documents from SG16 meeting in Geneva

[Terry L Anderson]

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