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