grayt@uunet.uu.net (Tom Gray) (11/02/90)
In article <14225@accuvax.nwu.edu> clark@ssc-vax.boeing.com (Roger Clark Swann) writes: >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? It is surprising that the ISDn telephones do not do this. My CLASS telephone from Bell Canada updates the local clock at each incoming call.
coffland@roxanne (Doug Coffland) (11/03/90)
>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
HWT@bnr.ca (Henry Troup) (11/07/90)
coffland@roxanne (Doug Coffland) writes: > you can querry the network for the date and time I know that some feature of Northern Telecom's systems cannot be used in the U.S. due to (interpretations of) the MFJ's requirement that telcos cannot be 'information providers'. Any chance that this has been applied to date and time information ? Henry Troup - BNR owns but does not share my opinions | uunet!bnrgate!hwt%bwdlh490 HWT@BNR.CA +1 613-765-2337 |