FW: Question about the use of alternateEndpoints in ACF
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@sonusnet.com +1 732 625-3003 ext 212
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
defined in this section, it should include the supportsAltGK field in
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
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,
Alternate endpoints are Gateways that may be able to terminate the same call. procedures the the 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
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
participants (3)
-
Douglas Clowes -
Lyons, Terry -
Paul E. Jones