Hi Paul,

Thanks for bringing up this interesting subject. The original reason for having multiple aliases may have been forgotten by many (more on this). 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).

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? I can imagine a smart phonebook/dialer which would take the addresses and "dial" one number at a time until it gets connected. But the smarts is in the application, not in the "switch" (in our case the GK).

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.

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.

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? Currently, GW's interpret the multiple aliases as the phone numbers to dial out to the ISDN network (to be more precise, the first number is usually in the CalledPartyNumber and the second in the destExtraCallInfo, but that's a different story).

It would be interesting to hear opinions from other implementors.

Regards,

Santo wiryaman VideoServer Inc.

-----Original Message----- From: Paul Long [SMTP:Plong@SMITHMICRO.COM] Sent: Thursday, January 21, 1999 2:39 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Multiple aliases in ARQ destinationInfo

Hello,

At the last interop I noticed that when an endpoint is placing a call, gatekeepers treated the presence of multiple aliases in the ARQ destinationInfo field in the following, different ways.

1.  Always use the first, ignore the rest.
   

2.  Respond with ARJ if more than one alias.
   

3.  Respond with ACF only if all aliases are registered to the same
   

endpoint. 4. Respond with ACF if at least one alias is registered, starting with the first one.

While the Recommendations are silent on the semantics of multiple aliases, and vendors are therefore free to do whatever they want in this regard, I believe that the 4th interpretation is what was intended and should be encouraged. A "should" clause might be added to a future version of H.225.0. The reason that the first two don't make sense is that destinationInfo is after all a _list_ of aliases. That implies there is _some_ meaning to multiple aliases-if only one alias was intended, the ASN.1 component would have been defined as a single alias. The 3rd interpretation is questionable because destinationInfo is a sequence-of and not a set-of aliases. Consider 3.8.46/X.680:

"...each value in the sequence-of type is an _ordered_ list of zero, one or more values of the component type. [emphasis mine]"

I take this to mean that not all aliases in destinationInfo are to be treated equal, and it is obvious to me that the order indicates search order. To reinforce the choice of the 4th interpretation, consider 7.11.1/H.225.0v2:

"destinationInfo - sequence of alias addresses for the destination, such as E.164 addresses or H323_IDs. When sending the ARQ to answer a call, destinationInfo indicates the destination of the call (the answering endpoint). ... "srcInfo - sequence of alias addresses for the source endpoint, such as E.164 addresses or H323_IDs. When sending the ARQ to answer a call, srcInfo indicates the originator of the call."

This means that srcInfo and destinationInfo are swapped when answering a call, relative to placing a call, and that they are therefore probably constructed similarly. Since srcInfo often has multiple aliases with which the caller wishes to be associated (one at a time, not as a single aggregate alias as in #3, above), it makes sense that destinationInfo also contains multiple aliases with which the callee may be associated.

In practice, let's say I want to call someone who has a couple of E.164 aliases, an email alias, and an H.323-id alias, not all of which may be registered at any one time. My phonebook has all four aliases listed for this person, possibly in some meaningful order. As a user, the only thing I'm interested in when I place the call, is that I want the gatekeeper to find the person. It makes sense to me for the gatekeeper to search the aliases in order until it finds one that is registered and then return a call-signaling transport address to which I can connect to establish the call.

I believe that the 4th interpretation is preferred but also that a gatekeeper may allow the administrator to configure this aspect in any number of ways, including the other three presented above.

Paul Long Smith Micro Software, Inc.