Multiple aliases in ARQ destinationInfo

Paul Long Plong at SMITHMICRO.COM
Thu Jan 21 14:38:37 EST 1999


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
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.

More information about the sg16-avd mailing list