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.