Multiple aliases in ARQ destinationInfo

[Chris Purvis]

> 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 at madge.com