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