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 elements?
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.
Regards,
Douglas