Multiple aliases in ARQ destinationInfo
Plong at SMITHMICRO.COM
Thu Jan 21 18:15:30 EST 1999
From: Santo Wiryaman [SMTP:swiryaman at VIDEOSERVER.COM]
Personally, my preference is for #1. Keep it simple. The reason is
ACF from a GK does not necessarily mean that the endpoint is
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?
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
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
7.11.1/H.225.0v2: "destExtraCallInfo - contains external addresses for
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
Smith Micro Software, Inc.
More information about the sg16-avd