Multiple aliases in ARQ destinationInfo

[Douglas Clowes]

At 17:05 1999-01-21 -0500, Santo Wiryaman wrote:
>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..
>

Can anyone remember the situation for the destAlternatives in ARQ and the
alternateEndpoints in the ACF?

One might suspect that the aliases in the message body all relate to the
"primary" contact, and the aliases in the destAlternatives relate to
alternative contacts.

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

What if the call originator wnts to "line hunt" across the possible addresses?

What if the destinationInfo in the ACF is a sequence of transport addresses?

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


The standard documents give (IMHO) too little information on the intention,
and expected use, of many of the elements. It's not surprising that they
change between implementors, or over time.

Does anyone remember the APC-xxxx for these elements?

Douglas