Paul, Chris:
First, a thank you to Paul for correcting my mistake. You are absolutely
right that the extra phone numbers are to be placed in the destExtraCallInfo
in the ARQ. I apologise for my lapse of memory and for not double checking
the standard.
Second, I agree with Chris that a single "number" that can follow a person
is a very good thing. In the example that Chris gave, though, the user of
the endpoint "dials" a single number. The "network" (in our case the GK)
may provide a dBase search on how to route this number at that particular
time based on some rules consistent with the service being provided. In
this case the ARQ would contain one "number".
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 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(a)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
> 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.
> 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(a)madge.com
