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_.

Do we really think this is acceptable? Frankly I'll happily ensure that the Madge gatekeeper does any of the sensible options in the interests of predictable behaviour! My vote would be for checking consistency of aliases within the GK's database (because it really ought to enable endpoints to give the user more meaningful error messages than a wrong number), but we can go with first past the post if we can reach concensus that way.

We COULD make it configurable, but I have a bad feeling about that. 1. What does it gain anybody over specifying something (except even more user-confusion)? 2. Assuming we want to define the same behaviour for LRQs in a multiple gatekeeper environment (which seems sensible), people may get results that surprise them due to different gatekeepers being differently configured.

Can we start by agreeing over whether we need agreement (I say we do), and then, if we DO think we need agreement, agree on WHAT?

Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis@madge.com