🚀 go-pugleaf

	We have discovered a problem with our local X25 switch 
	being used with AUSTPAC/OTC/{other x25 network} which you
	may be interested in. 

	this problem may be seen by anyone who is on a TRANSPAC-like
	X25 network being called from any other X25 network eg IPSS
	in the UK. it is caused by differences in the use & interpretation
	of X.121 addresses at each DTE, and propagated by X25 gateway and
	network provider behaviour.

	PROBLEM:
		Calls in to local host using subaddress routing are accepted
		but clear at once, possibly with error code 05 a7.
		Remote host may not see call connecting but local host
		does. 

		-further problem: diagnostic a7 is referred to international
		provider and/or remote DTE ie no human readable form available
		locally to decode the problem!

	SEE WITH:
		smartnet 3000 series X25 switch and possibly
		any similar box doing sub-address routing from one X25 DCE
		to several hosts. Any host receiving calls off the address
		with no subaddress will function normally. any routing
		ignoring sub-address may function normally.

	WHAT HAPPENS:
		The call request packet when received by the local X25 provider
		has the LOCAL DTE stripped out, leaving the subaddress part
		only.  This is perceived as a feature on certain nets.

		The switch then routes the CR packet to the correct host using 
		its tables.  The host accepts the call.

		The switch sends back a Connect Accept packet *WITH THE LOCAL
		SUBADDRESS IN IT BUT NOT THE FULL LOCAL DTE* as received from
		the local provider.

		The local provider does NOT re-insert the local DTE but passes
		this packet transparently to the gateway, which also passes
		direct to the remote X25 network.

		The remote network and/or DTE checks the CC packet, finds
		a DTE which (a) does not match the called address (b) does not
		conform to *its* idea of X.121 address format, and clears the
		call 05 (network congestion or other problem) a7 (DTE incorrect
		length)

	WHO IS TO BLAME?

		Well... clearly the switch could do better, but you can argue
		that if the network provider strips addresses on incoming 
		calls they should be replaced in all packets going out during
		the connect phase.  In our case we are using a box with
		little support and little configuration for this area. You
		should look carefully at any product & make sure you have
		full control over all fields of all packets if possible.

	FIX:
		(1)	get a switch which you can tailor enough to specify
			ALL fields in ALL packets and write a valid address
			into your CC packet before sending.

		(2)	discuss this feature with your network provider
			they *may* be able to switch it off, or insert full
			DTE into all connect-phase packets instead of leaving
			the CC alone.

		(3)	use other routing mechanisms as a temporary bridge:
			PID or cudf can be used with DTE minus subaddress
			to select several hosts, if the hosts support this
			option:	(the crucial one of ours claims to but the
			kernel crashes in this mode- the option is thus not
			available)

	I suspect this problem may be being seen by many people but ignored.
	At our site calls to some hosts worked ok, due to the default routing
	on no subaddress creating a CC with no arguments, which was accepted
	by everyone. Local tests fail to cause the problem, even loop-back
	through international gateway may fail to show problem, only a
	genuine call in from some remote net which also checks the DTE on
	all connect phase packets will cause rejection.

	Thanks to OTC and PSS engineers who helped track down this
	problem for us. (at time of writing we don't yet have fix working 
	locally, there may not *be* a fix!)

	George Michaelson.

-- 
ACSnet:	G.Michaelson@ditmela.oz.au
Postal:	55 Barry St, Carlton, Vic 3053
Phone:	(03) 347 8644 				Fax:	(03) 347 8987