Multiple aliases in ARQ destinationInfo

Jim Toga jim.toga at INTEL.COM
Thu Jan 21 16:41:02 EST 1999

I would coroborate that door #4 is the winner....

(This might be equal to finding 'John Smith' in the phone book, but
authentication is a separate issue...)


At 11:38 AM 1/21/99 -0800, you wrote:
>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,
>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
>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
>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
>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
>person. It makes sense to me for the gatekeeper to search the aliases in
>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.
+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