Santo, Well let's forward it to the implementers' list and see if that adds to the breadth of the discussion. I may be being naive in expecting a large intersection of subscribers... More comments of mine inline. Regards, Chris

-----Original Message----- From: Santo Wiryaman [mailto:swiryaman@VIDEOSERVER.COM] Sent: 26 January 1999 4:18 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Multiple aliases in ARQ destinationInfo

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)?

I'll agree with all of those.

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.

I would prefer to standardise what happens in 2, because of problems across multiple zones/sites/administrative domains.

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?

There's only one way of finding out!

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.

What I meant was that if a user's home AND work numbers are specified in an ARQ, a sufficiently clever, sufficiently configured gatekeeper may be able to work out that they refer to the same people and work out what best to do with the request (if, for instance, it knows that currently the only way to get hold of this person is via their mobile phone, this is what it will return in an ACF). If on the other hand two numbers in an ARQ specify different people (Fred and Joe's separate work phone numbers) I would consider the most sensible behaviour to be to reject the request with a useful (TBD) error code. There are arguments against this: What do you do with an ARQ containing one number you've heard of and one you haven't? If you accept this (which seems sensible with regard to gateways for example), there is the problem of what happens when the number you used not to have heard of suddenly appears on the system? The answer is that now the user who used to get a sensible result when he tried to make a call from his address book doesn't any more. Is this acceptable? Maybe best would be to specify in the implementer's guide that only one alias is to be used in the ARQ? I don't like this though, because I'd like to be able to use gateways without complicated prefixes (maybe this is never going to be possible). Regards, Chris

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