Owens, Peter powens at ABATISSYS.COM
Mon Jan 25 12:38:17 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:

        >2. Jim Toga envisions an endpoint that would send a call request,
        >MULTIPLE aliases to the GK.  These aliases all match to a single
        >The GK would find the device and the call would get connected.  The
        >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

        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
        case the EP cannot tell what happend from a protocol point of view.
        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)

        +1-503-264-8816(voice)              Intel - Hillsboro, OR
         mailto:jim.toga at         mailto:james.toga at
         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