[comp.dcom.telecom] Host-to-Switch Interfaces, ANSI T1S1

dgurevic@dhlmis.dhl (David Gurevich) (09/26/90)

It talks about the host-to-switch interfaces. Host being some computer
system, switch - a PBX, CO Switch, etc.

It seems that ANSII T1S1 subcommettee is trying to define a set of
specs called the Switch - to - Computer API (SCAI). SCAI would provide
common ground for any host to communicate to with any switch.

This means that all kinds of applications may be developed on the host
computer that would be able to add to the switch capability/
functionality.  A sophisticated development environment, rich in
labor-saving tools could be provided for this application development.
Data network interfaces could be easily added.

Is there a large market for this kind of a product?

What would be common applications?

Who would buy it?

What are the potential regulatory problems?

vances@xenitec.on.ca (Vance Shipley) (09/27/90)

In article <12606@accuvax.nwu.edu> David Gurevich
<dgurevic@dhlmis.dhl> writes:

>It seems that ANSII T1S1 subcommettee is trying to define a set of
>specs called the Switch - to - Computer API (SCAI). SCAI would provide
>common ground for any host to communicate to with any switch.

Nothern Telecom have an interface of this type now; Meridian Link.
AT&T, Mitel and others have them too.  All are incompatable.

>This means that all kinds of applications may be developed on the host
>computer that would be able to add to the switch capability/
>functionality.  A sophisticated development environment, rich in
>labor-saving tools could be provided for this application development.
>Data network interfaces could be easily added.

IBM have a tool box called CIT (Computer Integrated Telephony) for the
AS/400.  DEC have a similiar offering.

>Is there a large market for this kind of a product?

I think there is.  Today the best way to sell a switch, PBX or CO, is
to be able to fit neatly into the customers business environment.
This usually involves multi-vendor scenarios.  With this new enabling
technology it is possible to do things never before possible.  When a
customer presents a need for a feature that does not exist in the
current switch software it may be possible to implement it on an AP
(Auxiliary or Adjunct Proccessor).  The AP might be a Unix PC or mini
dedicated to the switch or an application running on the corporate
mainframe.

  Five years ago many in this industry were trying to convince us that
the PBX would be the office computer of tomorrow, doing both switching
and business computing!  Consumers were not, and are not, interested
in this.  What they want is equipment that does it's intended function
reliably, economically and integrates with equipment from other
vendors performing their functions.  An AS/400 and a Meridian 1 make a
better platform for office automation than a new ALLINONE by StartUp, Inc.

  The key of course is seamless integration, hopefully on an open
interface (non-proprietary).

>What would be common applications?

  The most often cited application is one in which incoming calls are
routed to ACD (Automatic Call Distribution) agents while customer
profiles are extracted from the computer and sent to the agents
computer screen.  This is based on the availability of the calling
party number, an ISDN feature.  Subsequent transfers to other agents
would cause the computer to forward the customers account to the next
agent's screen.
  
  Some more inventive applications include:

	- Database query from an LCD equipped phone (look up part number,etc.)
	- Display incurred call charges in real time on LCD display
	- E-Mail retreival from LCD phone
	- Enhanced call waiting information (Persons Name)

>Who would buy it?
 
No one without applications.

>What are the potential regulatory problems?

Sorry that's not my problem :-)


Vance Shipley

SwitchView - The Linton Technology Group
180 Columbia Street West   Waterloo, Ontario N2L 3L3
CANADA  (519) 746-4460  vances@ltg.on.ca.UUCP

dgurevic@dhlmis.dhl.com (David Gurevich) (09/28/90)

In article <12606@accuvax.nwu.edu> David Gurevich <dgurevic@dhlmis.
dhl> writes:
X-Telecom-Digest: Volume 10, Issue 679, Message 10 of 11

>It talks about the host-to-switch interfaces. Host being some computer
>system, switch - a PBX, CO Switch, etc.

The beginning of my original posting got cut off somehow.  I was
talking about an article in the September 1990 issue of Data
Communications title: "Host, Switches Announce Engagement, Plan
Nuptials".

koverzin@ntmtv.uucp (Raymond Koverzin) (10/09/90)

In article <12658@accuvax.nwu.edu>, vances@xenitec.on.ca (Vance
Shipley) writes: 

>In article <12606@accuvax.nwu.edu> David Gurevich <dgurevic@
 dhlmis.dhl> writes:

>>specs called the Switch - to - Computer API (SCAI). SCAI would
>>provide common ground for any host to communicate to with any
>>switch. Nothern Telecom have an interface of this type now;
>>Meridian Link. 

>AT&T, Mitel and others have them too.  All are incompatable.

>IBM have a tool box called CIT (Computer Integrated Telephony) for the
>AS/400.  DEC have a similiar offering.

CIT is actually an offering from DEC.  I used to work at Mitel on the
switch-to-computer link Mitel calls, Host Command Interface (HCI).  We
were working with DEC to help them define the application interface
for CIT, which was for their VAX minis.

I believe IBM's version is called Callpath.


Raymond Koverzin