New subject: Multiple aliases in ARQ destinationInfo

22 Jan 1999


      As a GK developer, I share Paul Long's desire to arrive at some concensus on
how a GK (or a collection of GK's) should treat multiple aliases in an ARQ.
Several suggestions had been offered such as interpretation 1,
interpretation 4, interpretation 4 plus Chris' refinements, and so on.
Before we define how the GK should interpret multiple aliases, I think we
need to find out what the endpoints (or users of those endpoints) mean when
they send multiple aliases in a call.  In this short email discussion of 4
people, there seemed to be multiple opinions on what this means:
1. Paul Long envisions an endpoint that would send a call request,
specifying MULTIPLE aliases to the GK. These aliases match to different
systems (e.g. #@work, #@home, cellphone#, fax#, etc.).  The GK would find a
match to one of these devices and the call would get routed to one of them.
2. Jim Toga envisions an endpoint that would send a call request, specifying
MULTIPLE aliases to the GK.  These aliases all match to a single device.
The GK would find the device and the call would get connected.  The two
devices would then negotiate what kind of call it is (audio only vs.
multimedia) by way of evaluating the aliases in the order they were
specified.
3. Chris Purvis suggested an endpoint that would send a call request,
specifying MULTIPLE aliases to the GK. The first alias would be the GW of
choice. Subsequent alias(es) would contain the address of the "ultimate"
destination.
4. Chris Purvis described an endpoint that would send a call request,
specifying ONE alias to the GK.  This alias is assigned to a person who may
be in different places (i.e different endpoints) at different times. S/he
somehow notifies the system where to route the call.  At the time of the
call, the GK would consult a dBase and route the call to the endpoint where
the person is.  This scenario is not really relevant to the issue at hand
because the endpoint sends ONE alias in the ARQ.  It is mentioned here to
show as an example for how the objectives of scenario 1 can be accomplished
without sending multiple aliases.
5. Santo knows of systems out there (MCU's) that register multiple aliases,
each corresponding to a conference.  Say, MCU1 registers "CONF_A", "CONF_B",
"CONF_C" as its aliases.  When EP1 calls "CONF_A", the GK would return the
address of MCU1.  The SETUP from EP1 would later arrive at MCU1 and the
destination is "CONF_A".  Becuase of this, MCU1 knows that the endpoint
wants to joint "CONF_A" and the call is accepted.  However, if MCU1 receives
a SETUP with multiple destinations such as "CONF_A", "CONF_B", "CONF_C" it
might get confused and drop the call (or use interpretation 1 and therefore
use the first alias only).  This is an example of a potential problems that
can result from multiple aliases, not at the GK but at the destination
endpoint (e.g. an MCU).
I am sure the list above is not comprehensive.  If 3 or more people join in
the discussion they may have half a dozen more uses for multiple aliases.
Some of the multiple alias interpretations (such as #1 - #3 described above)
may all have valid and good reasons behind them.   Since there can be many
interpretations for multiple aliases from the users' point of view (some
perhaps conflicting, e.g. #1 conflicts with #3) , it would be hard to
specify a rule on the GK which can satisfy all the users' requirement.
Some comments to Jim Toga's posting are within the enclosed text.
-santo
...
-----Original Message-----
From: Jim Toga [SMTP:jim.toga@INTEL.COM]
Sent: Friday, January 22, 1999 12:46 PM
To:   ITU-SG16@mailbag.cps.intel.com
Subject:      Re: Multiple aliases in ARQ destinationInfo
At 10:50 AM 1/22/99 -0500, Santo wrote:
[SNIP]
...
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
...
of them.
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
effiecient start.
[Santo Wiryaman]  The DNS analogy is done today by e.g. an MCU
        registering multiple aliases for the same CallSignalAddress.  Even
if a machine
        has multiple DNS names (aliases) such as in:
140.242.112.1  pj , PaulJ, pJones, Paul_Jones
when user applications would "connect" to that system, they would
typically
        use one of them, e.g. :
ping pj
          telnet Paul_Jones.XYZ.com
          ftp PaulJ
What we are dealing here is specifying multiple destinations all at
once.    It is
        like saying:
ftp m1,m2,m3,m4
Which machine should the system connect to?  Perhaps m3 because m1
and
        m2 are on a different domain?
I fully agree with Jim and Chris that routing and hunt-group
functionality should
        be implemented partly if no completely in the GK. I am still having
problem seeing
        how multiple aliases helps the process.  Unless, of course the GK is
setup to use
        the same interpretation rules as specified by the site.  Then this
becomes a site
        configuration issue doesn't it?
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
H.245....
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.
Comments?
jimt.
...
I share Chris' concern about such a "blast" dial system which is
non-determinism.
...
Regards,
-santo
...
-----Original Message-----
From: Chris Purvis [SMTP:CPurvis@MADGE.COM]
Sent: Friday, January 22, 1999 5:33 AM
To:   ITU-SG16@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
with
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
...
...
of
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,
...
...
so
this should not add significantly to call setup latency.
Hence what I believe SHOULD happen is that the gatekeeper

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.
Either:
2a. Repeat the same policy at any other levels of search that it
engages
...
...
in
(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
aliases
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:
[Santo]
...
In practice, could you tell us an example of a widely deployed
communication
...
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
...
...
a
"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
for
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'
experience.
[Paul]
...
Is an EP required to use the exact same alias list in the Setup that
it
...
...
used
...
in the ARQ? I don't think so. Sounds like it should use the alias list
sent
...
back in the ACF's destinationInfo field, which would presumably
contain
...
...
only
...
the alias(es) that resolved into the provided transport address. Good
point,
...
though. Needs more thought. What if more than one alias resolved into
the
...
...
same
...
address and the GK returned all of the resolved aliases? But then,
maybe
...
...
we're
...
trying to over-engineer the problem. Maybe it just makes good sense to
the
...
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
...
...
is
how the destinationInfo, destExtraCallInfo and remoteExtensionAddress
fields
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
this
is a potential source of incompatibility with TIPHON however, because
(again
from memory - no doubt I'll be corrected if I'm wrong!) TIPHON
equipment
...
...
is
instructed to ignore CalledPartyNumber.  Whatever "correct" procedure
is,
...
...
though, it should be agreed and documented.
[Paul]
...
Simple, return the transport address of the first resolved alias.
What's
...
...
wrong
...
with that?
Possible non-determinism (see 2b above).
Regards,
Chris
--
Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks.
ENGLAND
Phone: +44 1753 661 359  email: cpurvis@madge.com
+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

Re: Multiple aliases in ARQ destinationInfo

Santo Wiryaman

Jim Toga

tags (0)

participants (2)