Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!bionet!hayes.ims.alaska.edu!accuvax.nwu.edu!nucsrl!telecom-request
From: coffland@roxanne (Doug Coffland)
Newsgroups: comp.dcom.telecom
Subject: Re: AT&T ISDN Set Question
Message-ID: <14267@accuvax.nwu.edu>
Date: 2 Nov 90 21:31:45 GMT
Sender: news@accuvax.nwu.edu
Reply-To: Doug Coffland <coffland@roxanne>
Organization: Computations Department, LLNL, Livermore CA
Lines: 64
Approved: Telecom@eecs.nwu.edu
X-Submissions-To: telecom@eecs.nwu.edu
X-Administrivia-To: telecom-request@eecs.nwu.edu
X-Telecom-Digest: Volume 10, Issue 784, Message 11 of 12


>Here at the Big 'B' most all of the secretarial stations are equipped
>with an ATT ISDN 7505 set. That's the one with the multifuction
>display. Behind these sets are 5ESS switches, everything being
>purchased from and integrated by ATT.  One of the functions of the
>display on the 7505 is a clock/calendar. The recent change from
>daylight time back to standard time brings the following question:

>Why isn't the clock display in the station set slaved off the real
>time clock on the switch (5ESS) such that the stations are updated
>at least once every 24 hours?

This seems like a very valid question and the only explanation that I
can come with is that this is how AT&T chose to implement the set.  In
fact, CCITT Recommendation Q.932 which spells out the Layer 3
Supplementary Services describes a Supplementary Service Element for
Date and Time. i.e. you can querry the network for the date and time
and expect a response.

I'm not completely clear on this, but since this element is one of the
supplementary services, it may not be available with basic ISDN
service.

As I read on into the 5E6 ISDN Basic Rate Interface Specification from
AT&T, I found that this supplementary service is available to
Attendant Consoles.  It is not clear whether it is possible to turn
this service on for other types of instruments in the 5ESS.

After this, I decided to try out our AT&T ISDN Attendant Console and
sure enough they do retrieve the date and time from the switch.  By
the way, the operators immediately jumped on me when they found out
what I was up to and said that the time was about four minutes slow in
our switch.  The switch tech adjusted the switch which, in turn,
updated the consoles.  AT&T ISDN Attendant Consoles work from a Basic
Rate Interface just as do our other 8,000 ISDN sets.

In summary, a set vendor that builds his phones to rely only on the
network for the time may be at risk.  Certainly, more research than I
have done is required.  Investigation into the implementations of
other ISDN Switch builders not to mention the various generics and
translation options in each is a must.

Another possibility may be for a vendor to sell an applications
processor along with his individual sets that provides a central time
source and is querried via X.25 packets across the network.  This may
be a potential suggestion for the North American ISDN User's Forum to
avoid the proprietary nature of an application that would tend to
occur naturally.

Another shortfall is that the time provided across a packet network
whether it originates from a peripheral applications processor or from
the ISDN itself is subject to error equal to packet delay across the
network.

Finally, as you can see, ISDN is only an emerging standard at best.
The type of question presented here is one of many revolving around
this standard.  I feel that comp.dcom.telecom is an excellent forum to
discuss and possibly even resolve these problems and would like to see
more discussion around ISDN in the future.


Douglas R. Coffland
Lawrence Livermore National Laboratory
415-423-7867    coffland@roxanne.llnl.GOV