Multiple aliases in ARQ destinationInfo
Paul Long
Plong at SMITHMICRO.COM
Mon Jan 25 12:27:32 EST 1999
>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_.
Paul Long
Smith Micro Software, Inc.
-----Original Message-----
From: Jim Toga [SMTP:jim.toga at INTEL.COM]
Sent: Friday, January 22, 1999 4:15 PM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: Multiple aliases in ARQ destinationInfo
At 06:40 PM 1/22/99 -0500, Dr SantoW wrote:
>[SNIP]
>2. Jim Toga envisions an endpoint that would send a call request,
specifying
>MULTIPLE aliases to the GK. These aliases all match to a single
device.
>The GK would find the device and the call would get connected. The
two
>devices would then negotiate what kind of call it is (audio only vs.
>multimedia) by way of evaluating the aliases in the order they were
>specified.
>
Note quite what I meant to imply.....
The client _MAY_ present multiple aliases to the GK. These aliases
MAY or
_MAY-NOT_ match to a single device. The question point is:
a) Does the GK return the first match?
b) If not, what happens on an exhaustive search that returns different
transport addresses?
In either case the GK can only return one address in the ACF. In
either
case the EP cannot tell what happend from a protocol point of view.
There
may be a _big_ difference from a service point of view however.
It should definitely be a policy/configuration widget on the GK. The
question in my mind is should the EP explicitly request one behavior
or the
other? (similar to the GK-routing flag)
jimt.
+1-503-264-8816(voice) Intel - Hillsboro, OR
mailto:jim.toga at intel.com mailto:james.toga at ties.itu.int
PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41
More information about the sg16-avd
mailing list