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...)
jimt.
At 11:38 AM 1/21/99 -0800, you wrote:
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.
Always use the first, ignore the rest.Respond with ARJ if more than one alias.Respond with ACF only if all aliases are registered to the sameendpoint. 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.
+1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41