Xref: utzoo comp.protocols.misc:218 comp.protocols.iso:31
Path: utzoo!mnetor!uunet!cos!rob
From: rob@COS.COM (Rob Clark)
Newsgroups: comp.protocols.misc,comp.protocols.iso
Subject: Re: AUSTPAC/TRANSPAC internetwork problems: have you seen this?
Message-ID: <947@cos.COM>
Date: 5 Feb 88 14:49:46 GMT
References: <284@ditmela.oz>
Organization: Corporation for Open Systems, McLean, VA
Lines: 50

In article <284@ditmela.oz>, george@ditmela.oz (George michaelson) writes:
> 
> 	We have discovered a problem with our local X25 switch 
> 	being used with AUSTPAC/OTC/{other x25 network} which you
> 	may be interested in. 
> 

I had a chat with our X.25 guru who has had experience of transpac-type
networks, and we came up with the following:

I would agree that if the network provider (austpac) is going to
strip the called address (except the subaddress if present) from
incoming call packets, then it should do the converse,  thereby
injecting the network address in that same field (appending intact the
subaddress which is returned by the switch which is interposed
between the network provider and the one or more x25 hosts).

I would think, though, that the interposed switch should be capable
of creating a proper full x121 called address in the
extended accept packet. It really should be its responsibility to act
as the network interface to all of its attached DTEs.  (Although it
appears that not even the network provider is doing this detail correctly.)

I know, however, that all equipment does not work this way. For example,
Dynapac's model 8 (8 port) switch does just what is described in
the message, ie, if it has been optioned to create extended call
accept packets for an attached DTE that cannot do so, it will
take the called address as it saw it and recreate it in the
extended accept packet.  So, no help there, I'm afraid.

In such cases where the calling DTE's software (or the DCE node that
it's connected to) compares the called address in the call request
packet to the called address in the extended call accept packet,
then extended call accept packets have to be disabled at the called
end (since we know that the normal short form of the call accept
packet is acceptable [normally] by all).  

This is, of course, unfortunate since one shouldn't have to disable a
possibly desirable feature because there are certain networks or
pieces of equipment that don't support them.

C'est la vie!

chris 	(Chris Rohrer @ Corporation for Open Systems)
rob 	(Rob Clark @ Corporation for Open Systems)
	-- X@cos.com
	-- X%cos.com@uunet.uu.net
	-- {uunet, sundc, decuac, hqda-ai, hadron}!cos!X

	where X = "chris" or "rob"