From: Santo Wiryaman [SMTP:swiryaman@VIDEOSERVER.COM] Personally, my preference is for #1. Keep it simple. The reason is that an ACF from a GK does not necessarily mean that the endpoint is registered with the GK. In other words, when a GK receives an ARQ and does not find the alias registered, it has to look somewhere else: other GK's (using LRQ), some GK's lookup in ILS servers, DNS, etc..

When the ARQ has an ordered list of aliases, what should the GK do? What if alias #1 is found in a different zone2, alias #2 is found in zone3, and alias #3 is registered locally in zone1? Which IP address should the GK return in the ACF? Further more, the LRQ process (and other address lookup procedures) are asynchronous. The LCF for alias #2 might come back before the LCF from alias #1. Having the LCF for alias #2, does the GK have to wait around for the LCF of alias #1 (which may never arrive).

Simple, return the transport address of the first resolved alias. What's wrong with that? The ordered list of aliases indicates a _preferred_ search order. In practice, I doubt whether users will consciously place aliases in a particular order, so returning the address of any alias will most likely be satisfactory. This could be a quality-of-implementation issue, too. A GK could be configured to delay admission a bit in an attempt to return the address of the earliest-possible alias in the list.

In practice, could you tell us an example of a widely deployed communication system where you can "dial" multiple destinations (e.g. home phone, work phone, cell phone, fax number, emailID) at once and "it" will get you the most suitable destination?

Hey, it's a brave new world out there. :-) How about a universal mailbox?

I think having multiple types of aliases (e164, h323-ID, url-ID, transportID, email-ID, partyNumber(publicNumber, privateNumber,nationalStandardPartyNumber) ) is confusing enough. Placing multiple aliases in an ARQ would further complicate matters.

The facility is already in the Recommendation for this. We can't take it out. EP and GK vendors can decide what makes sense to them. If you only want to look at the first alias, go ahead.

If I am not mistaken, the original reason for defining destinationInfo in ARQ as a sequence of aliases is to convey two (or more) phonenumbers to use for a single call. For example, to make an H.323 to an H.320 call via an ISDN GW using 2B lines, there can be two aliases: "918005551212" and "918005551213". Therefore, all aliases in the field are used for the same call; it is not a list of alternative aliases in prefered order.

I believe you are mistaken. The second alias goes in the ARQ's destExtraCallInfo field:

7.11.1/H.225.0v2: "destExtraCallInfo - contains external addresses for multiple calls."

The field of the same name in the Setup message is used for the same thing:

7.3.10/H.225.0v2: "destExtraCallInfo - needed to make possible additional channel calls, i.e. for a 2*64 Kbps call on the WAN side. Shall only contain E.164 addresses and shall not contain the number of the initial channel."

As a side note, some H.323 systems (e.g. an MCU, a GK-routed GK) look into the destinationAddress field in the SETUP message to see where to further route the call. Presumably, if there is a list of aliases in the ARQ, there would also be a list of aliases in the SETUP. How should these systems interpret the list of aliases?

Is an EP required to use the exact same alias list in the Setup that it used in the ARQ? I don't think so. Sounds like it should use the alias list sent back in the ACF's destinationInfo field, which would presumably contain only the alias(es) that resolved into the provided transport address. Good point, though. Needs more thought. What if more than one alias resolved into the same address and the GK returned all of the resolved aliases? But then, maybe we're trying to over-engineer the problem. Maybe it just makes good sense to the users in these situations to provide a single alias, and everything just works... :-)

Paul Long Smith Micro Software, Inc.