FW: Question about the use of alternateEndpoints in ACF

[Lyons, 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).
> 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.
> 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?
>
> Can we presume that the critical event is receiving a ReleaseComplete?
> 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)?
> 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.
>
> - TLyons at sonusnet.com  +1 732 625-3003 ext 212
>