Hi Paul,
Thanks for bringing up this interesting subject. The original reason for
having multiple aliases may have been forgotten by many (more on this).
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 the
alias registered, it has to look somewhere else: other GK's (using LRQ),
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, and
alias #3 is registered locally in zone1? Which IP address should the GK
return in the ACF? Further more, the LRQ process (and other address lookup
procedures) are asynchronous. The LCF for alias #2 might come back before
the LCF from alias #1. Having the LCF for alias #2, does the GK have to
wait around for the LCF of alias #1 (which may never arrive).
In practice, could you tell us an example of a widely deployed communication
system where you can "dial" multiple destinations (e.g. home phone, work
phone, cell phone, fax number, emailID) at once and "it" will get you the
most suitable destination? I can imagine a smart phonebook/dialer which
would take the addresses and "dial" one number at a time until it gets
connected. But the smarts is in the application, not in the "switch" (in
our case the GK).
I think having multiple types of aliases (e164, h323-ID, url-ID,
transportID, email-ID, partyNumber(publicNumber,
privateNumber,nationalStandardPartyNumber) ) is confusing enough. Placing
multiple aliases in an ARQ would further complicate matters.
If I am not mistaken, the original reason for defining destinationInfo in
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 an
ISDN GW using 2B lines, there can be two aliases: "918005551212" and
"918005551213". Therefore, all aliases in the field are used for the same
call; it is not a list of alternative aliases in prefered order.
As a side note, some H.323 systems (e.g. an MCU, a GK-routed GK) look into
the destinationAddress field in the SETUP message to see where to further
route the call. Presumably, if there is a list of aliases in the ARQ, there
would also be a list of aliases in the SETUP. How should these systems
interpret the list of aliases? Currently, GW's interpret the multiple
aliases as the phone numbers to dial out to the ISDN network (to be more
precise, the first number is usually in the CalledPartyNumber and the second
in the destExtraCallInfo, but that's a different story).
It would be interesting to hear opinions from other implementors.
Regards,
Santo wiryaman
VideoServer Inc.
> -----Original Message-----
> From: Paul Long [SMTP:Plong@SMITHMICRO.COM]
> Sent: Thursday, January 21, 1999 2:39 PM
> To: ITU-SG16(a)mailbag.cps.intel.com
> Subject: Multiple aliases in ARQ destinationInfo
>
> Hello,
>
> At the last interop I noticed that when an endpoint is placing a call,
> gatekeepers treated the presence of multiple aliases in the ARQ
> destinationInfo field in the following, different ways.
>
> 1. Always use the first, ignore the rest.
> 2. Respond with ARJ if more than one alias.
> 3. Respond with ACF only if all aliases are registered to the same
> endpoint.
> 4. Respond with ACF if at least one alias is registered, starting
> with
> the first one.
>
> While the Recommendations are silent on the semantics of multiple aliases,
> and
> vendors are therefore free to do whatever they want in this regard, I
> believe
> that the 4th interpretation is what was intended and should be encouraged.
> A
> "should" clause might be added to a future version of H.225.0. The reason
> that
> the first two don't make sense is that destinationInfo is after all a
> _list_
> of aliases. That implies there is _some_ meaning to multiple aliases-if
> only
> one alias was intended, the ASN.1 component would have been defined as a
> single alias. The 3rd interpretation is questionable because
> destinationInfo
> is a sequence-of and not a set-of aliases. Consider 3.8.46/X.680:
>
> "...each value in the sequence-of type is an _ordered_ list of zero, one
> or
> more values of the component type. [emphasis mine]"
>
> I take this to mean that not all aliases in destinationInfo are to be
> treated
> equal, and it is obvious to me that the order indicates search order. To
> reinforce the choice of the 4th interpretation, consider 7.11.1/H.225.0v2:
>
> "destinationInfo - sequence of alias addresses for the destination, such
> as
> E.164 addresses or H323_IDs. When sending the ARQ to answer a call,
> destinationInfo indicates the destination of the call (the answering
> endpoint). ...
> "srcInfo - sequence of alias addresses for the source endpoint, such as
> E.164
> addresses or H323_IDs. When sending the ARQ to answer a call, srcInfo
> indicates the originator of the call."
>
> This means that srcInfo and destinationInfo are swapped when answering a
> call,
> relative to placing a call, and that they are therefore probably
> constructed
> similarly. Since srcInfo often has multiple aliases with which the caller
> wishes to be associated (one at a time, not as a single aggregate alias as
> in
> #3, above), it makes sense that destinationInfo also contains multiple
> aliases
> with which the callee may be associated.
>
> In practice, let's say I want to call someone who has a couple of E.164
> aliases, an email alias, and an H.323-id alias, not all of which may be
> registered at any one time. My phonebook has all four aliases listed for
> this
> person, possibly in some meaningful order. As a user, the only thing I'm
> interested in when I place the call, is that I want the gatekeeper to find
> the
> person. It makes sense to me for the gatekeeper to search the aliases in
> order
> until it finds one that is registered and then return a call-signaling
> transport address to which I can connect to establish the call.
>
> I believe that the 4th interpretation is preferred but also that a
> gatekeeper
> may allow the administrator to configure this aspect in any number of
> ways,
> including the other three presented above.
>
> Paul Long
> Smith Micro Software, Inc.
