alternateEndpoints, srcAlternatives, and destAlternatives

Douglas Clowes dclowes at OZEMAIL.COM.AU
Tue Sep 1 02:49:54 EDT 1998

_Somebody must_ know the answers to this!

I have been looking at the source and destination address information in
H.323 version 2, and am feeling a little confused.

Perhaps someone can point me to something that will clarify the position.

Version 1 had a number of addressing fields, for both the source and
destination. Version 2 extends that in a number of areas, both as
additional fields for what I'll call the primary address, but also as
sequences of source and destination alternatives. It also introduces the
Endpoint IE, which contains a number of OPTIONAL address structures.

Referring to the Endpoint first, I notice that it contains both an
aliasAddress, and a destinationInfo. The descriptions for these elements do
not seem convincingly right. If the Endpoint refers to a destination,
presumably both (this endpoint and destination) are the same.

I also notice that Endpoint does not contain the new element
remoteExtensionAddress which has been added, as destination address
information, to both ACF and SETUP messages. If this is the number to be
dialled from a remote gateway, may it not be different for different
destination gateways? I think it could be, and so should also appear in the
Endpoint IE. I think that it should be an optional element in the ARQ as
well, if the source endpoint knows this information.

I also see that remoteExtensionAddress is a SEQUENCE OF in the ACF, but
only a single AliasAddress in the SETUP message. Why?

I assume that alternateEndpoints, in the ACF message, are alternates to be
tried in the event that the endpoint specified in the dest* elements
(priority 0) is not successful.

It gets more difficult when I look at the ARQ message. Can someone please
tell me what is the intention of the srcAlternatives and destAlternatives

If the purpose of srcAlternatives, in ARQ, is to allow for an endpoint that
has multiple possible identities, shouldn't ACF specify which identity is
confirmed, and which alternative to use in the SETUP message? To include an
OPTIONAL sourceAddress Endpoint in the ACF, would also allow a gatekeeper
to override or add source address information for the call.

On the subject of where authorisation tokens between source and destination
could be included in call setup, has anything been discussed or decided? By
that I mean a token of some kind, generated by the source gatekeeper and to
be relayed through the setup process to the destination gatekeeper, as
input to the destination admission determination.



More information about the sg16-avd mailing list