APC Numbers: ITU-T Q.11-15 Meeting

Sakae OKUBO okubo at GITI.OR.JP
Thu Jan 21 20:39:19 EST 1999

        From:   Santo Wiryaman [SMTP:swiryaman at VIDEOSERVER.COM]
        Personally, my preference is for #1. Keep it simple.  The reason is
that an
        ACF from a GK does not necessarily mean that the endpoint is
registered with
        the GK.  In other words, when a GK receives an ARQ and does not find
        alias registered, it has to look somewhere else: other GK's (using
        some GK's lookup in ILS servers, DNS, etc..

        When the ARQ has an ordered list of aliases, what should the GK do?
What if
        alias #1 is found in a different zone2, alias #2 is found in zone3,
        alias #3 is registered locally in zone1?  Which IP address should the
        return in the ACF?  Further more, the LRQ process (and other address
        procedures) are asynchronous.  The LCF for alias #2 might come back
        the LCF from alias #1.  Having the LCF for alias #2, does the GK have
        wait around for the LCF of alias #1 (which may never arrive).

Simple, return the transport address of the first resolved alias. What's wrong
with that? The ordered list of aliases indicates a _preferred_ search order.
In practice, I doubt whether users will consciously place aliases in a
particular order, so returning the address of any alias will most likely be
satisfactory. This could be a quality-of-implementation issue, too. A GK could
be configured to delay admission a bit in an attempt to return the address of
the earliest-possible alias in the list.

        In practice, could you tell us an example of a widely deployed
        system where you can "dial" multiple destinations (e.g. home phone,
        phone, cell phone, fax number, emailID) at once and "it" will get you
        most suitable destination?

Hey, it's a brave new world out there. :-) How about a universal mailbox?

        I think having multiple types of aliases (e164, h323-ID, url-ID,
        transportID, email-ID, partyNumber(publicNumber,
        privateNumber,nationalStandardPartyNumber) ) is confusing enough.
        multiple aliases in an ARQ would further complicate matters.

The facility is already in the Recommendation for this. We can't take it out.
EP and GK vendors can decide what makes sense to them. If you only want to
look at the first alias, go ahead.

        If I am not mistaken, the original reason for defining destinationInfo
        ARQ as a sequence of aliases is to convey two (or more) phonenumbers
to use
        for a single call.  For example, to make an H.323 to an H.320 call via
        ISDN GW using 2B lines, there can be two aliases: "918005551212" and
        "918005551213".  Therefore, all aliases in the field are used for the
        call; it is not a list of alternative aliases in prefered order.

I believe you are mistaken. The second alias goes in the ARQ's
destExtraCallInfo field:

7.11.1/H.225.0v2: "destExtraCallInfo - contains external addresses for
multiple calls."

The field of the same name in the Setup message is used for the same thing:

7.3.10/H.225.0v2: "destExtraCallInfo - needed to make possible additional
channel calls, i.e. for a 2*64 Kbps call on the WAN side. Shall only contain
E.164 addresses and shall not contain the number of the initial channel."

        As a side note, some H.323 systems (e.g. an MCU, a GK-routed GK) look
        the destinationAddress field in the SETUP message to see where to
        route the call.  Presumably, if there is a list of aliases in the ARQ,
        would also be a list of aliases in the SETUP.  How should these
        interpret the list of aliases?

Is an EP required to use the exact same alias list in the Setup that it used
in the ARQ? I don't think so. Sounds like it should use the alias list sent
back in the ACF's destinationInfo field, which would presumably contain only
the alias(es) that resolved into the provided transport address. Good point,
though. Needs more thought. What if more than one alias resolved into the same
address and the GK returned all of the resolved aliases? But then, maybe we're
trying to over-engineer the problem. Maybe it just makes good sense to the
users in these situations to provide a single alias, and everything just
works... :-)

Paul Long
Smith Micro Software, Inc.

More information about the sg16-avd mailing list