Pete,
At 19:21 13/08/98 +0100, Pete Cordell wrote:
This document captures some requirements for inter-gatekeeper
messaging
and proposes some syntax for how this may be implemented. Although it
may be considered premature to propose syntax at this stage, the
syntax
is proposed here so that others developing syntax can view it and take
it into account if they see benefit in doing so. Hopefully this will
ease the process of agreeing on a common syntax.
(smile)
The syntax is based on an ASN.1-erised version of a proposal produced
way back in 1995, hence the ideas are not new. Even so, the ideas do
seem to be still valid.
The message set below is concerned with distributing directory
information for E.164 numbers (the assumption is that for other sorts
of
alias names, the form endpoint@gatekeeper will be used which will
remove
the need for any special infrastructure to support it). The scheme is
more push based than some of the other proposed schemes, and is based
on
directory information being shared with peers. It is assumed that
peering relationships are setup by human administrators and units do
not
automatically start exchanging database information by themselves.
However, multicast distribution of the data does allow for some
automated exchange of data.
Added from the document:
<excerpt>The text does not propose solutions for distributing costing information or the provision of application level QoS.
</excerpt><<<<<<<<
To me, the document seems to be a database distribution protocol, rather than a generic inter-gatekeeper communication protocol, or a specific gateway location protocol.
It also appears, to me, very complex, but I don't come from a PSTN domain with multiple numbering plans and all of the knowledge that I assume that brings. I guess that your prior knowledge helps you to know what to do with it all, and answers the questions that come to my mind.
Since you propose multiple routes, and these are probably not equivalent, I expect a route selection process. Such a selection process must be based on something. I would expect that to be either cost-based, quality-based, or both.
It would also appear that the intention is for the database to be gatekeeper resident. That thought prompts me to ask what memory burden does that place on the gatekeeper? Also, if the information is dynamic, what update rate and traffic burden?
Please pardon my naivety.
Requirements
The following are important requirements for inter-gatekeeper
signalling:
Support of multiple numbering plans,
Why? And, what are they?
Support for mapping the prefixes of numbers,
Why? That may well prompt, and possibly answer, how?
Support for redundant routes,
I presume that you mean 'alternate' routes. How are we to choose between them?
Provision for both direct and gatekeeper routed models,
Naturally, but how does that impact the protocol?
Authentication of who is sending information.
Yes.
Optional Extras
The following are supported by the message set defined below, but are
not considered vital for a first cut release.
Provision for data to be fragmented across multiple packets,
Needed for large databases in packet based systems.
Provision for data distribution over both reliable and
unreliable
connections,
Why?
Provision for incremental update,
And synchronisation confirmation/validation, and resynchronisation.
Provision for data distribution via multicast.
Sounds very dangerous to me, for distribution of a large database over unreliable transport, with incremental updates.
The document is attached, and also available from
ftp://ftp.labs.bt.com/pub/intergk.doc
I had to fetch the document by ftp, as the attachment was broken. So much for 'reliable' transports :-).
You mention LRQ and SETUP. Why not ARQ?
With multiple plans, how are they selected between?
Since many of the characters in your Domain Number alphabet are not permitted in the e164 IE, such as "!", and "+", are they expected to be present in the LRQ/SETUP, and where?
If, as I assume it is, the intent is to use the database for gateway location, what will be the resolved address, how will the dynamic nature of gateway availability be handled, and how will "line-hunt" be handled?
Regards,
Douglas