Hi Chris, Yes, we do need an agreement. On the WHAT part, may I suggest the following: how should a GK treat multiple aliases in an ARQ?

The answer should consider the following (and some others which I might have missed): 1. ARQ from the caller (this is the main topic for the question) 2. SETUP. In a GK-routed, pre-granted situation, the GK does not get the ARQ so the SETUP may contain multiple aliases 3. ARQ from the callee. Would this ARQ contain multiple alias, too? If so, what does it mean? 4. ARQ from the caller contain multiple aliases and destCallSignalAddress What ought the GK do? 5. What should be returned in the ACF? 6. What to do with LRQ's (rules for sending, receiving)?

Here is my vote: 1. At a minimum, a GK shall do interpretation #1: use the first alias and ignore the rest 2. The GK may optionally look at the other aliases. The interpretation of these multiple aliases shall be determined by the particular site / administrative domain.

Incidentally, I just realized that these discussions were on the SG-16 mailing list and not on the h323Implementors list. I wonder if that might be a reason for not hearing from other folks?

I also have a question on what you mean by consistency check of the GK dbase during the ARQ. What are you trying to detect in this case? I re-read your previous email and got the following:

Hence what I believe SHOULD happen is that the gatekeeper

1. If it can match anything within its zone, should ensure that different

aliases in the ARQ do not point to different destinations within the zone. If there is such disagreement, the GK should return ARJ.

It seems that the above check would prevent Paul Long from doing what he was suggesting, i.e. call "#@home, #@work, #@mobile_phone, #ofFaxMachine", because more than one of those devices may be in the same zone.

Regards,

-santo

-----Original Message----- From: Chris Purvis [SMTP:CPurvis@MADGE.COM] Sent: Tuesday, January 26, 1999 5:05 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Multiple aliases in ARQ destinationInfo

...

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