From the various views expressed in this thread, I think it is clear that

until at least a consensus is formed on the semantics of multiple aliases in ARQ's destinationInfo, an EP had better send a single alias if the user has any hope of predictable--not necessarily deterministic--behavior. As with many things H.323, _caveat transmittor_.

Paul Long Smith Micro Software, Inc.

-----Original Message----- From: Jim Toga [SMTP:jim.toga@INTEL.COM] Sent: Friday, January 22, 1999 4:15 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Multiple aliases in ARQ destinationInfo

At 06:40 PM 1/22/99 -0500, Dr SantoW wrote: >[SNIP]

>2. Jim Toga envisions an endpoint that would send a call request, specifying >MULTIPLE aliases to the GK. These aliases all match to a single device. >The GK would find the device and the call would get connected. The two >devices would then negotiate what kind of call it is (audio only vs. >multimedia) by way of evaluating the aliases in the order they were >specified. >

Note quite what I meant to imply.....

The client _MAY_ present multiple aliases to the GK. These aliases MAY or _MAY-NOT_ match to a single device. The question point is:

a) Does the GK return the first match? b) If not, what happens on an exhaustive search that returns different transport addresses?

In either case the GK can only return one address in the ACF. In either case the EP cannot tell what happend from a protocol point of view. There may be a _big_ difference from a service point of view however.

It should definitely be a policy/configuration widget on the GK. The question in my mind is should the EP explicitly request one behavior or the other? (similar to the GK-routing flag)

jimt. +1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41