Multiple aliases in ARQ destinationInfo
jim.toga at INTEL.COM
Fri Jan 22 12:45:49 EST 1999
At 10:50 AM 1/22/99 -0500, Santo wrote:
>Of course I am not saying that if it hasn't been done it is a bad thing. I
>am merely suggesting that there may be a better way of doing it (such as the
>system in the UK described by Chris). It was not a rethoric question
>either; I truly wanted to know if Paul knows of any system out there where
>you can "blast" dial with multiple numbers and hope to get connected to one
I would offer as a model both DNS (which allows multiple 'aliases' to point
to a single host) and 'hunt groups' as mentioned by ChrisP which are very
useful in situations other than call centers. To Chris's point, I also
believe that this functionality should be partially (if not completely)
implemented by a Gatekeeper - the multiple aliases simply gives the GK an
Another facet to this is if the aliases have some implied (agreement
between calling and called parties) functionality to them. For example I
might have both and rfc822 alias and an E.164 alias. The implications
might be that they are associated with a multimedia recipient and an
audio-only client respectively. Depending on what the caller wants to do
they might put one 'higher' in the alias array. Note that these are (or
might be) _service_ level capabilities, not the same thing as offered by
With respect to 'errror' conditions or inconsistencies on the GK database
when doing look-ups, it seems as though that would really be a policy
issue. The usual behaviour of 'least astonishment' should be the default.
>I share Chris' concern about such a "blast" dial system which is
>> -----Original Message-----
>> From: Chris Purvis [SMTP:CPurvis at MADGE.COM]
>> Sent: Friday, January 22, 1999 5:33 AM
>> To: ITU-SG16 at mailbag.cps.intel.com
>> Subject: Re: Multiple aliases in ARQ destinationInfo
>> Time for me to wade in on a couple of points here too, I'm afraid...
>> First let me say what we've implemented so far:
>> 4. Respond with ACF if at least one alias is registered, starting
>> the first one.
>> Having said that, I'm not certain that's how things should be. I believe
>> the "right" answer is none of those Paul suggests. My starting point,
>> though, is that at this stage of placing a call, line-hunting is the job
>> the gatekeeper, not the endpoint. If one wants to do line-hunting at the
>> endpoint, one should be sending a number of ARQs - note that there's no
>> reason an endpoint can't have multiple ARQs outstanding at the same time,
>> this should not add significantly to call setup latency.
>> Hence what I believe SHOULD happen is that the gatekeeper
>> 1. If it can match anything within its zone, should ensure that different
>> aliases in the ARQ do not point to different destinations within the zone.
>> If there is such disagreement, the GK should return ARJ.
>> 2a. Repeat the same policy at any other levels of search that it engages
>> (LRQs etc).
>> or (probably "better" from the point of view of call setup times, although
>> less deterministic):
>> 2b. If a search procedure needs to be done outside of the zone, use the
>> first positive reply you get
>> One use I see for these multiple aliases, is to avoid the abomination of
>> dial-prefixes for dialing out through gateways. The first alias should
>> point to a gateway (probably by name rather than number), subsequent
>> in a setup message should tell the gateway what to do. Clever gatekeepers
>> may want to have policy on what outside lines are permitted to certain
>> users, and therefore need to see this information at this stage.
>> Unfortunately nobody seems to use multiple aliases like this...
>> In answer to a couple of other specific points:
>> >In practice, could you tell us an example of a widely deployed
>> >system where you can "dial" multiple destinations (e.g. home phone, work
>> >phone, cell phone, fax number, emailID) at once and "it" will get you the
>> >most suitable destination? I can imagine a smart phonebook/dialer which
>> >would take the addresses and "dial" one number at a time until it gets
>> >connected. But the smarts is in the application, not in the "switch" (in
>> >our case the GK).
>> Are you suggesting that if such a thing hasn't been done before it is not
>> "good" thing to do?
>> Incidentally the start of such a thing does exist, at least in the UK. I
>> have friends for whom I can dial a single number. They tell the server
>> this number where they are at any given time, and when I dial their
>> "personal numebr" I talk to the person, whether they happen to be at home
>> (on their home number), at work (on their work number) or elsewhere (on
>> their mobile phone). We have a huge opportunity to improve users'
>> >Is an EP required to use the exact same alias list in the Setup that it
>> >in the ARQ? I don't think so. Sounds like it should use the alias list
>> >back in the ACF's destinationInfo field, which would presumably contain
>> >the alias(es) that resolved into the provided transport address. Good
>> >though. Needs more thought. What if more than one alias resolved into the
>> >address and the GK returned all of the resolved aliases? But then, maybe
>> >trying to over-engineer the problem. Maybe it just makes good sense to
>> >users in these situations to provide a single alias, and everything just
>> >works... :-)
>> The ACF's destinationInfo field only appears in version 2, but yes this is
>> certainly what you should use where present (if it's absent, you can't do
>> anything other than use what you used in the setup message). Do any
>> endpoints complain when they see extra, superfluous aliases in setup
>> messages addressed to them? I doubt it. Even gateways should surely use
>> what they can make sense of and ignore anything else. The question mark
>> how the destinationInfo, destExtraCallInfo and remoteExtensionAddress
>> in ACF should be mapped to the various fields in the setup message
>> (CalledPartyNumber, CalledPartySubAddress, destinationAddress,
>> DestExtraCallInfo, remoteExtensionAddress). I seem to remember hearing at
>> some point that they should be mapped into the fields of the same name,
>> except that the first destinationInfo that is a phone number is moved into
>> CalledPartyNumber, and CalledPartySubAddress. I believe if implemented
>> is a potential source of incompatibility with TIPHON however, because
>> from memory - no doubt I'll be corrected if I'm wrong!) TIPHON equipment
>> instructed to ignore CalledPartyNumber. Whatever "correct" procedure is,
>> though, it should be agreed and documented.
>> >Simple, return the transport address of the first resolved alias. What's
>> >with that?
>> Possible non-determinism (see 2b above).
>> Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
>> Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks.
>> Phone: +44 1753 661 359 email: cpurvis at madge.com
+1-503-264-8816(voice) Intel - Hillsboro, OR
mailto:jim.toga at intel.com mailto:james.toga at ties.itu.int
PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41
More information about the sg16-avd