From: Lars Poulsen <[email protected]> Subject: Re: PBX ISDN-S/T interface application question
>>Is there a demand anywhere in the worldwide market for multi-drop >>capability at this type of PBX/TE--NT1 node? At 02:31 PM 6/13/97 -0700, Stampfli Franz (7-0241) wrote: > - In Germany, you can often see PBX systems which have a bus configuration > on, at least one, of their T ports (PBX - NT1). This is often used as > emergency application (emergency phone or data adapters). I was looking into this when researching for a product recently. The point-to-point configuration is a natural fit for the connection between a PBX and a central office. Typically, you do not connect a fax machine in parallel to the PBX on the trunk between the PBX and the central office. Recognizing this, the ETSI standards allow for point-to-point operation in this application. It is not clear to me what the emergency application described above would consist of. Are you saying that when the PBX is down, you want a handset to answer the incoming calls, with automatic switchover ? > - As far as I know the only IC supplier, which has a chip solution for > bus mode on the T interface is Siemens. The part is called ISAC-S PEB2086 > and supports TE, LT-S and LT-T modes. There should be a data sheet on the > web. The normal configuration of a TE (Terminal Equipment) interface is to get its timing from the NT-1. Indeed, this is required in order to know that there is only one timing source, so that the bus protocol will work nicely. The complication arises when a PBX has multiple BRI lines, and all of them need to be synchronized to a common timing source. One of the links between the central office and the PBX is then designated as the timing master, and aal of the other circuits must then be slaved to this. But most of the S/T transceiver chips lose the ability to perform the bus contention protocol when they get switched from timing slave to timing master. Indeed, the Siemens ISAC-S seems to be the only exception I know of. The practical issue from the user's perspective would seem to be: How acceptable is it if only one port can do the bus contention protocol ? I do not see any problem with this. For my application, it is much easier to claim that no bus contention is allowed on ANY of the ports. / Lars Poulsen [email protected] +1-805-562-3158 OSICOM Technologies (Internet Business Unit) Fax: 805-968-8256 7402 Hollister Avenue Manager of Remote Access Engineering Goleta, CA 93117 Internets designed while you wait
