APC request

[Sakae OKUBO]

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 at MADGE.COM]
> Sent: Tuesday, January 26, 1999 5:05 AM
> To:   ITU-SG16 at 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 at madge.com