Multiple aliases in ARQ destinationInfo

[Chris Purvis]

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 at VIDEOSERVER.COM]
> Sent: 26 January 1999 4:18
> To: ITU-SG16 at 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 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
>