TELECOM Digest Sat, 14 Jan 95 08:10:00 CST Volume 15 : Issue 31 Inside This Issue: Editor: Patrick A. Townson CFP: Feature Interactions in Communications Systems (Nancy Griffeth) Satellite / DECNet Problems (Edward B. Toupin) Acronym for "Information Superhighway" (Humor Listserv via Bill Edwards) Modem-Voice Incoming Call Switching (Jan Mandel) Legal Problem Due to Modified Radio (David A. Webb) Old Rotary Service Question (Bill Parrish) Call Overflow Question (Mark Kelly) 360 Degrees of Jumping the Gun (Paul Robinson) FAQs on Campus Connectivity (routers@halcyon.com) Would You Believe More Rain on the Way? (TELECOM Digest Editor) TELECOM Digest is an electronic journal devoted mostly but not exclusively to telecommunications topics. It is circulated anywhere there is email, in addition to various telecom forums on a variety of public service systems and networks including Compuserve and America On Line. It is also gatewayed to Usenet where it appears as the moderated newsgroup 'comp.dcom.telecom'. Subscriptions are available to qualified organizations and individual readers. Write and tell us how you qualify: * telecom-request@eecs.nwu.edu * The Digest is edited, published and compilation-copyrighted by Patrick Townson of Skokie, Illinois USA. You can reach us by postal mail, fax or phone at: 9457-D Niles Center Road Skokie, IL USA 60076 Phone: 708-329-0571 Fax: 708-329-0572 ** Article submission address only: telecom@eecs.nwu.edu ** Our archives are located at lcs.mit.edu and are available by using anonymous ftp. The archives can also be accessed using our email information service. For a copy of a helpful file explaining how to use the information service, just ask. ********************************************************************** *** * TELECOM Digest is partially funded by a grant from the * * International Telecommunication Union (ITU) in Geneva, Switzerland * * under the aegis of its Telecom Information Exchange Services (TIES) * * project. Views expressed herein should not be construed as represent-* * ing views of the ITU. * ********************************************************************** *** Additionally, the Digest is funded by gifts from generous readers such as yourself who provide funding in amounts deemed appropriate. Your help is important and appreciated. A suggested donation of twenty dollars per year per reader is considered appropriate. See our address above. All opinions expressed herein are deemed to be those of the author. Any organizations listed are for identification purposes only and messages should not be considered any official expression by the organization. ---------------------------------------------------------------------- From: nancyg@thumper.bellcore.com (Nancy Griffeth) Subject: CFP Feature Interactions in Communications Systems Organization: Morristown Research and Engineering Date: Fri, 13 Jan 1995 19:55:00 GMT Call for Participation Third International Workshop on Feature Interactions in Telecommunications Software Systems Kyoto, Japan October 11-13, 1995 Description: This workshop is the third in a series, whose mission is to encourage researchers from a variety of computer science specialties (software engineering, enterprise modeling, protocol engineering, distributed artificial intelligence, formal techniques, software testing, and distributed systems, among others) to apply their techniques to the feature interaction problem that arises in building telecommunications software systems (see the back page for a description of the problem). We welcome papers on avoiding, detecting, and/or resolving feature interactions using either analytical or structural approaches. Submissions are encouraged in (but are not limited to) the following topic areas: - Classification of feature interactions. - Modeling, reasoning, and testing techniques for detecting feature interactions. - Software platforms and architecture designs to aid in avoiding, detecting, and resolving feature interactions. - Tools and methodologies for promoting software compatibility and extensibility. - Mechanisms for managing feature interactions throughout the service life-cyle. - Management of feature interactions in PCS, ISDN, and Broadband services, as well as IN services. - Management of feature interactions in various of the operations support functions such as Service Negotiation, Service Management, and Service Assurance. - Feature Interactions and their potential impact on system Security and Safety. - Environments and automated tools for related problems in other software systems. - Management of Feature Interactions in various other enterprises, such as banking, medicine, etc. Format: We hope to promote a dialogue among researchers in various related areas, as well as the designers and builders of telecommunications software. To this end, the workshop will have sessions for paper presentations, including relatively long discussion periods. Panel discussions and tool demonstrations are also planned. The first day of the workshop, October 11, is devoted to tutorials and discussions on areas related to feature interactions. Attendance: Workshop attendance will be limited to 100 people. Attendance will be by invitation only. Prospective attendees are asked to submit either a paper (maximum 5000 words) or a single page description of their interests and how they relate to the workshop. Proposals for tutorials and discussions are also requested (maximum 3000 words). About 16-20 of the attendees will be asked to present talks; a small number of tutorials and/or discussions will also be selected. We will strive for an equal mix of theoretical results and practical experiences. Papers will be published in a conference proceedings. Submissions: Please send five copies of your full original paper or interest description to: Kong Eng Cheng Department of Computer Science Royal Melbourne Institute of Technology GPO Box 2476V Melbourne, Victoria AUSTRALIA 3001 E-mail: kec@cs.rmit.edu.au Tel: +61 3 660 3266 FAX: +61 3 662 1617 Important dates are: February 28, 1995: Submission of contributions. May 15, 1995: Notification of acceptance. June 26, 1995: Submission of camera-ready versions. Workshop Co-chairpersons Tadashi Ohta (ATR, Japan) Nancy Griffeth (Bellcore, USA) Program Committee Co-Chairpersons: Kong Eng Cheng (Royal Melbourne Institute of Technology, Australia) E. Jane Cameron (Bellcore, USA) Jan Bergstra (CWI and University of Amsterdam, The Netherlands) Ralph Blumenthal (Bellcore, USA) Rolv Braek (SINTEF DELAB, Norway) Bernie Cohen (City University of London, UK) Robert France (Florida Atlantic University, USA) Haruo Hasegawa (OKI, Japan) Dieter Hogrefe (University of Bern, Switzerland) Richard Kemmerer (UCSB, USA) Victor Lesser (University of Massachusetts, USA) Yow-Jian Lin (Bellcore, USA) Luigi Logrippo (University of Ottawa, Canada) Jan van der Meer (Ericsson, The Netherlands) Robert Milne (BNR, UK) Leo Motus (Tallinn Technical University, Estonia) Jacques Muller (CNET, France) Jan-Olof Nordenstam (ELLEMTEL, Sweden) Yoshihiro Niitsu (NTT, Japan) Ben Potter (University of Hertfordshire, UK) Henrikas Pranevicius (Kaunas University of Technology, Lithuania) Martin Sadler (HP, UK) Jean-Bernard Stefani (CNET, France) Greg Utas (BNR, USA) Jyri Vain (Institute of Cybernetics, Estonia) Hugo Velthuijsen (PTT Research, The Netherlands) Yasushi Wakahara (KDD R&D Laboratories, Japan) Ron Wojcik (BellSouth, USA) Pamela Zave (AT&T Bell Laboratories, USA) Workshop Statement: The feature interaction problem is a major obstacle to the rapid deployment of new telephone services. Some feature communications system. Telecommunications software is huge, real-time, and distributed; adding new features to a telecommunication system, like adding new functionalities to any large software system, can be very difficult. Each new feature may interact with many existing features, causing customer annoyance or total system breakdown. Traditionally, interactions were detected and resolved on a feature by feature basis by experts who are knowledgeable on all existing features. As the number of features grows to satisfy diverse needs of customers, managing feature interactions in a single administrative domain is approaching incomprehensible complexity. In a future marketplace where features deployed in the network may be developed by different operating companies and their associated vendors, the traditional approach is no longer feasible. How to detect, resolve, or even prevent the occurrence of feature interactions in an open network is now an important research issue. The feature interaction problem is not unique to telecommunications software; similar problems are encountered in any long-lived software system that requires frequent changes and additions to its functionality. Techniques in many related areas appear to be applicable to the management of feature interactions. Software methodologies for extensibility and compatibility, for example, could be useful for providing a structured design that can prevent many feature interactions from occurring. Features are typically design to suit the purposes of a user or business, hence Enterprise modeling will play a role in the identification of certain classes of interaction, in particular the solution of an interaction in one enterprise may not be desired by another. Formal specification, verification, and testing techniques, being widely used in protocol engineering and software engineering, contribute to the detection of interactions. Several causes of the problem, such as aliasing, timing, and the distribution of software components, are similar to issues in distributed systems. Cooperative problem solving, a promising approach for resolving interactions at run time, resembles distributed planning and resolution of conflicting subgoals among multiple agents in the area of distributed artificial intelligence. This workshop aims to provide an opportunity for participants to share ideas and experiences in their respective fields, and to apply their expertise to the feature interaction problem. Workshop Announcement: 3nd International Workshop on Feature Interactions in Telecommunications Software Systems, October 11-13, Kyoto, Japan, Sponsors: IEEE Communications Society. In cooperation with ACM SIGCOMM and ATR, Japan. Contact Tadashi Ohta, ATR, 2-2, Hikari-dai, Seika-cho, Soraku-gun, Kyoto, 619-02, Japan, Tel: +81 7749 5 1230, Fax: +81 7749 5 1208, e-mail: ohta@atr-sw.atr.co.jp. ------------------------------ From: etoupin@toupin.com (Edward B. Toupin) Subject: Satellite / DECNet Problems Date: 13 Jan 1995 15:53:26 GMT Organization: Edward B. Toupin Reply-To: sn=morrison%g=tom%i=p%dda=tel=3536%texaco@mcimail.com, The message is sent for an associate. TOM MORRISON writes: We currently have an application in which DEC VAXStations communicate through DECRouter 2000s. The local area network uses DECNet and the routers that connect disparate local area networks communicate via 56k leased data circuits. The required throughput on these circuits does not exceed 20k. It is our desire to provide a diverse route for data using an X.25 based double hop satellite system. This circuit configuration has approximately 1.5 seconds of processing and propogation delay. In testing the proposed configuration, 56kb modems were connected back to back to conduct 1 megabyte file transfers using X.25. In this configuraton, circuit throughput averaged 45kbps. The modems were then replaced with a satellite circuit which caused the throughput to drop off to 1100 bps! Incidently the satellite system provides local acknowledgements at the X.25 level and no flow control messages were seen. In evaluating the satellite throughput, we have been told that DECNet has a required acknowledgement for either one of four packets generated at the NSP level. This acknowledgement is hard coded into DECNet and can't be changed. These required acknowledgements, coupled with the long propogation time of the satellite system combine to limit throughput. Please provide any insight you may have to the following questions: 1. Are NSP acknowledgements required after each or every fourth packet? 2. We thought that adjusting the buffer sizes in the routers would change packet sizes, however, in monitoring data communication with Trace we didn't see any change in packet size. Can packet sizes be changed (increased)? 3. Has anyone had similar experiences with similar results? 4. Any ideas about how we may increase throughput in the double hop satellite system? Regards, Tom Morrison ------------------------------ Date: Fri, 13 Jan 95 12:53:13 EST From: Bill Subject: Acronym for "Information Superhighway" For the benefit of the readers... Bill Edwards, HUMOR listowner, BEDWARDS@UGA.BITNET (uga.cc.uga.edu) ===================================================================== To leave HUMOR send LISTSERV@UGA.CC.UGA.EDU the command SIGNOFF HUMOR To subscribe send LISTSERV@UGA.CC.UGA.EDU the command SUB HUMOR Call- name FamilyName. A command goes in the 1st line of the message field. -------------Original message-------------- Date: Thu, 12 Jan 1995 19:03:12 -0500 Sender: UGA Humor List From: "Greg V." Subject: Acronym INFORMATION SUPERHIGHWAY: Interactive Network For Organizing, Retrieving, Manipulating, Accessing, and Transferring Information On National Systems, Unleashing Practically Every Rebellious Human Intelligence, Gratifying Hackers, Wiseasses, And Yahoos. Thanks to Kevin Kwaku, who obvoiusly has way too much time on his hands. - Greg V. NYGreg@AOL.COM "Roadkill on the Information Superhighway" ---------------- [TELECOM Digest Editor's Note: Gee, it sounds just like the CB Radio era back in the late 1970's when CB was at its height of popularity. The crazy people ruined CB ... I guess now they will make things so miserable on the Internet large numbers of people will drop out. PAT] ------------------------------ From: jmandel@carbon.cudenver.edu (Jan Mandel) Subject: Modem-Voice Incoming Call Switching Date: 13 Jan 1995 11:31:39 -0700 Organization: University of Colorado at Denver A while ago I have posted a question how to switch incoming calls to an answering machine or a modem. Many have pointed out that incoming modem call is just silence and it is the answering modem that makes the shreeking noise. Thank you all. Consequently to decide if the incoming call is modem or not one would have to subject all callers to the unpleasant shreek. Here is another possible solution: let an answering machine take all calls. If there is silence on the line after the beep (all answering machines can detect this condition), let it time out and switch to the answering modem. Since I need this for my office where after office hours I would dial in or others may call in to leave a message, that úÿ would work for my needs. I'll set the timeout for my calling modem large so that it waits longer for the carrier. I was also looking for a modem setup parameter like "answer only after 60 seconds" for the asnwering side but could find none. Anyone knows what hardware I may need for this? I need to buy an answering machine for the office anyway so I may just as well buy the right one. I already have a pair of Hayes Accura 288 V.FC modems a year old. No, I canot use alternate ring because this is a PBX line. This whole exercise is because of our phone bozos who will not let me have another PBX (=cheap) line in the office once they heard we have modems, for fear I actually might use it. A separate telco line would be too expensive. TIA for any suggestions. Jan Mandel, Center for Computational Math, University of Colorado at Denver jmandel@colorado.edu ------------------------------ From: mudaw@uxa.ecn.bgu.edu (David A. Webb) Subject: Legal Problem Due to Modified Radio Date: 13 Jan 1995 17:55:40 -0600 Organization: Educational Computing Network Dear Moderator, I was rather impressed with your knowledge of FCC regulations. I read that you are an attorney, and I know time is money, but I thought you would be interested in my situation. University police searched my dorm room in November, 1992 after I consented to the search. (Mistake #1) An officer found my 2 meter amateur transceiver, turned it on, and discovered it could transmit on frequencies licensed to the local county police. I was not in my room during the time of the search, so I had no control over its operation. The radio was confiscated, and I had to defend myself in front of the school board. The school did not find me in violation of any rules because I had a statement from a county officer who is also a Ham. The officer wrote he knew my radio was legal for me to possess. I was never accused of using the radio. I was never charged in a court of law concerning the radio. I petitioned the court for the return of personal property. This was December 20, 1994. I didn't take any evidence to support my side (Mistake #2). The States attorney had three witnesses. Witness #1 was the university officer who stated under oath that he used the radio to transmit on county frequencies to verify the modifications. He also stated in his professional capacity that my radio is illegally modified, and therefor illegal to possess. He further stated that he called the FCC and was told my radio is illegal to possess. Witness #2 was the county sheriff. He indicated in his professional capacity that my radio was illegal to own. He also voiced understandable concern for my capability to interfere with his frequencies. Witness #3 was a person who services amateur equipment. He stated that my radio is type accepted, and therefor it is illegal to modify. Illegal modification therefor makes my radio illegal to possess. The University officer must have called the field office in Chicago, because when I called there, I was also told my radio is illegal to possess. I called the Washington office, and the Director of the Private Radio Division is sending me a statement which will say that my radio is legal for anyone to possess, and its use is regulated by the FCC. (unless local laws prohibit a radio which will transmit on police channels) Witness #2 was simply giving an opinion. Witness #3 was wrong about the type acceptance. Amateur equipment transmitters are not type accepted. Its internal receiver it accepted to receive everything it was modified to receive. I tried to submit the county officer/ham's statement, and the states attorney objected because the officer was not present for cross examination. Am I going to run into the same trouble when I try to submit the statement from the Private Radio Division of the FCC? If so, how can I get around this obstacle? I reported the discrepancy of the field office to the FCC's General Councils Office, and they will be investigating the person who gave me the faulty information. Although the university police violated FCC rules, it occurred over a year ago, and therefor time limits on me reporting them has expired. Neither the States Attorney, nor any of his witnesses, presented the judge with any law I *supposedly* violated. The judge ruled to NOT allow me to have my radio back UNLESS I paid to have it unmodified. I filed a motion for the Judge to reconsider his ruling, which is scheduled for February 9. The reason I have opted to do this on my own is that the radio isn't worth more than a few hundred bucks. I am pursuing this on the principal. My radio is legal for me to own, and I am tired of the harassment from university police. Please send your comments to me at mudaw@ecom.ecn.bgu.edu. [TELECOM Digest Editor's Note: First, and most important, I am not an attorney, and you are not my client. I will suggest that depending on how strongly you feel about the principles involved here and getting your equipment returned, you *should* consult an attorney who specializes in communications law, preferably in your community if possible, although quite a few (most?) of those people are in practice in Washington, DC and environs. We do have attornies whose practice is specialized in the area of federal communications law on the Digest mailing list, and perhaps one or more of them will respond to you directly at least once on a pro-bono basis offering some suggestions or help. My feeling is the cost involved for *good* legal representation in this area will be far in excess of the value of the equipment involved. This will have to be your decision in connection with any discussions you have with an attorney who is competent to assist you. I cannot do so. Good luck with this. Perhaps other Digest readers will have suggestions also. PAT] ------------------------------ From: Bill Parrish Subject: Old Rotary Service Question Date: Fri, 13 Jan 95 7:58:32 PST Pat's reply to the thread about scanners and cordless phones dealing with party lines reminded me of something I had always wondered about. In the early 70s, I went to UCSB, and we were serviced by GTE in the dorms. Occasionaly folks would decide to "share" a phone connection by making their own patches into terminal cabinets ... resulting in an illegal but effective party line arrangement. I recall that if the phone had the wrong type of filter in it that you would sometimes get the "pinging" sound rather than a vigorous "ring" when an incoming call came in. But there was a second funny thing about these "extensions" that was rather odd ... you sometimes could not make long distance calls on them ... and that always seemed odd to me. If I recall right, there was some sort of a movable pin on the back of the dial that could be put into one of several (three?) positions, and if you moved the pin, it would enable the long-distance capability. Could someone explain how that worked? (I could be remembering wrong ... it's been a long time, but I always wondered how that worked). Bill Parrish (916) 785-4986 M6KV Hewlett Packard Systems Technology Division 8000 Foothills Blvd. Roseville, CA 95747-5596 HPDesk: Bill_parrish@hp5200.desk.hp.com Unix to Unix: bparrish@hprpcd.rose.hp.com Fax: (916) (or TELNET) - 785-3096 ------------------------------ From: mkelly@gabriel.resudox.net (Mark Kelly) Subject: Call Overflow Question Date: 13 Jan 1995 22:38:58 GMT Organization: Resudox Online Services I have question for the telephony wizards out there. A single number DN #1 has been assigned to a trunk group (say a T1, 24 channels). When all 24 channels are busy, its desirable to route all incoming calls to the DN #1 to another number (DN #2). Can anyone think of a way to do this that doesn't involve adding a extra trunk group at the switch and pointing it to the second number. Any suggestions or hints would be welcome. Mark Kelly Advanced Multi-Point Conferencing 320 March Road, Suite 102 Kanata, Ontario K2L 1Z8 1-800-900-4249 (Reservations) 1-613-592-5752 ------------------------------ Date: Fri, 13 Jan 1995 19:33:42 EST From: Paul Robinson Organization: Tansin A. Darcos & Company, Silver Spring, MD USA Subject: 360 Degrees of Jumping the Gun I decided to check Pat Towson's comments about the 630 area code in Chicago. I first tried 1-700-555-1212 and it told me I have AT&T. I dialed 1-630-555-1212 and when asked what city, I asked the operator if it was the Chicago operator, and she said yes. I realized I really didn't have a reason to call anyone there. So, next I decided to see if the new area codes are in place here, and dialed 1-360-555-1 Oops, the phone times out on me! Now, for the fun part. I dial 611 and explain that I *can* call 1-630 but *can't* call 1-360 and the agent says "It must be in your phone." Yeah, right. I explained that I have dialed the number by going through 1-800-CALL-ATT and using a calling card. I explained that the same thing happens from other phones, on different lines. She put me on hold and when she came back she said that there is a routing problem, and she'll write up a trouble ticket. We'll see what happens. It must have been difficult (knowing my trouble with Bell Atlantic) because I got a return call a few minutes ago, about an hour after I placed the call to 611. According to the person calling me, the "official" date that area code 360 goes into effect isn't until tomorrow, which is why Bell Atlantic is not accepting calls placed to that area code yet. So, if the statment is correct, those places that are accepting calls to the 360 area code are actually "jumping the gun". ------------------------------ From: routers@halcyon.com Subject: FAQs on Campus Connectivity Date: 13 Jan 1995 12:14:06 GMT Organization: Northwest Nexus Inc. NEW ANSWERS FOR FAQs ON CAMPUS NETWORKS AND CONNECTIVITY This posting may be freely distributed to Internet and commercial online sites. Date: January 12, 1994 Keywords: UTP distance standards, campus networks connectivity, ethernet, wireless, LAN, microwave, repeaters, video 1. QUESTION: What is the maximum bandwidth that 4-wire copper UTP can handle in campus environments? ANSWER: ---E-1 up to 2.5 miles (4 km) 2. QUESTION: What is the longest distance that 4-wire copper UTP can transmit at T-1 band width? ANSWER: ---5 miles (8 km), up to 7 miles (11.2 km) with a repeater 3. QUESTION: Can you transmit data, voice, and video across 4-wire UTP at the same time without cross-talk? ANSWER: ---Yes 4. QUESTION: What is the maximum distance that ethernet at 10 Mbps can be extended? ANSWER: ---1500 ft (495 m), up to 3000 ft (990 m) with repeater 5. QUESTION: Is there a wireless solution that would allow a campus to connect all buildings together, and allow any PC or laptop computer on campus to communicate, even if they move about the campus? ANSWER: ---Yes. One solution allows building -to- building connections up to 6 miles (9.6 km), and allows any PC or laptop to be on line. It operates at 2 Mbps, has SNMP, and requires no FCC licence. 6. QUESTION: Are there any wireless solutions at 10 Mbps for LAN-to-LAN connections? ANSWER: ---Yes. A microwave solution allows LANs to connect up to 5 miles (8 km). This same system has options that will allow voice, data, and video at the same time, in either 4 -T1 slots, or 8 -T1 slots. The 8 -T1 version can handle 192 voice-grade circuits. For further information and product data sheets, please contact Router Solutions (routers@halcyon.com), or check our FTP site: ftp.halcyon.com /pub/local/routers ------------------------------ From: TELECOM Digest Editor Subject: Would You Believe More Rain on the Way? Date: Sat, 14 Jan 1995 08:00:00 CST Listening to WNIB on the radio this Saturday morning as I work on this issue ... the eight o'clock news says 'up to six more inches of rain due in California throughout the weekend ... more evacuations probably will be required ...' Well, good luck and my best regards, folks. It seems like the people in California spend all summer burning the place down, then spend all winter enduring mud slides and flooding. We are getting a lot of rain here today also, but the only effect has been to melt all the snow which had accumulated and leave some *huge* puddles of water to navigate at curbs where the street sewers are plugged, etc. Have the floods in California affected telephone service to any extent? PAT ------------------------------ End of TELECOM Digest V15 #31 ***************************** ÿ@FROM :telecom@delta.eecs.nwu.edu Message-ID: <9501141411.AA14245@delta.eecs.nwu.edu> From telecom-request@delta.eecs.nwu.edu Sat Jan 14 10:25:00 1995 Received: from delta.eecs.nwu.edu (delta.eecs.nwu.edu [129.105.5.103]) by coyote.channel1.com (8.6.9/8.6.4) with SMTP id KAA13091; Sat, 14 Jan 1995 10:25:00 -0500 Received: by delta.eecs.nwu.edu (4.1/SMI-4.0-proxy) id AA14253; Sat, 14 Jan 95 08:11:21 CST Received: by delta.eecs.nwu.edu (4.1/SMI-4.0-proxy) id AA14245; Sat, 14 Jan 95 08:11:17 CST Date: Sat, 14 Jan 95 08:11:17 CST From: telecom@delta.eecs.nwu.edu (TELECOM Digest (Patrick Townson)) Message-Id: <9501141411.AA14245@delta.eecs.nwu.edu> To: telecom@eecs.nwu.edu Subject: TELECOM Digest V15 #31 TELECOM Digest Sat, 14 Jan 95 08:10:00 CST Volume 15 : Issue 31 Inside This Issue: Editor: Patrick A. Townson CFP: Feature Interactions in Communications Systems (Nancy Griffeth) Satellite / DECNet Problems (Edward B. Toupin) Acronym for "Information Superhighway" (Humor Listserv via Bill Edwards) Modem-Voice Incoming Call Switching (Jan Mandel) Legal Problem Due to Modified Radio (David A. Webb) Old Rotary Service Question (Bill Parrish) Call Overflow Question (Mark Kelly) 360 Degrees of Jumping the Gun (Paul Robinson) FAQs on Campus Connectivity (routers@halcyon.com) Would You Believe More Rain on the Way? (TELECOM Digest Editor) TELECOM Digest is an electronic journal devoted mostly but not exclusively to telecommunications topics. It is circulated anywhere there is email, in addition to various telecom forums on a variety of public service systems and networks including Compuserve and America On Line. It is also gatewayed to Usenet where it appears as the moderated newsgroup 'comp.dcom.telecom'. Subscriptions are available to qualified organizations and individual readers. Write and tell us how you qualify: * telecom-request@eecs.nwu.edu * The Digest is edited, published and compilation-copyrighted by Patrick Townson of Skokie, Illinois USA. You can reach us by postal mail, fax or phone at: 9457-D Niles Center Road Skokie, IL USA 60076 Phone: 708-329-0571 Fax: 708-329-0572 ** Article submission address only: telecom@eecs.nwu.edu ** Our archives are located at lcs.mit.edu and are available by using anonymous ftp. The archives can also be accessed using our email information service. For a copy of a helpful file explaining how to use the information service, just ask. ********************************************************************** *** * TELECOM Digest is partially funded by a grant from the * * International Telecommunication Union (ITU) in Geneva, Switzerland * * under the aegis of its Telecom Information Exchange Services (TIES) * * project. Views expressed herein should not be construed as represent-* * ing views of the ITU. * ********************************************************************** *** Additionally, the Digest is funded by gifts from generous readers such as yourself who provide funding in amounts deemed appropriate. Your help is important and appreciated. A suggested donation of twenty dollars per year per reader is considered appropriate. See our address above. All opinions expressed herein are deemed to be those of the author. Any organizations listed are for identification purposes only and messages should not be considered any official expression by the organization. ---------------------------------------------------------------------- From: nancyg@thumper.bellcore.com (Nancy Griffeth) Subject: CFP Feature Interactions in Communications Systems Organization: Morristown Research and Engineering Date: Fri, 13 Jan 1995 19:55:00 GMT Call for Participation Third International Workshop on Feature Interactions in Telecommunications Software Systems Kyoto, Japan October 11-13, 1995 Description: This workshop is the third in a series, whose mission is to encourage researchers from a variety of computer science specialties (software engineering, enterprise modeling, protocol engineering, distributed artificial intelligence, formal techniques, software testing, and distributed systems, among others) to apply their techniques to the feature interaction problem that arises in building telecommunications software systems (see the back page for a description of the problem). We welcome papers on avoiding, detecting, and/or resolving feature interactions using either analytical or structural approaches. Submissions are encouraged in (but are not limited to) the following topic areas: - Classification of feature interactions. - Modeling, reasoning, and testing techniques for detecting feature interactions. - Software platforms and architecture designs to aid in avoiding, detecting, and resolving feature interactions. - Tools and methodologies for promoting software compatibility and extensibility. - Mechanisms for managing feature interactions throughout the service life-cyle. - Management of feature interactions in PCS, ISDN, and Broadband services, as well as IN services. - Management of feature interactions in various of the operations support functions such as Service Negotiation, Service Management, and Service Assurance. - Feature Interactions and their potential impact on system Security and Safety. - Environments and automated tools for related problems in other software systems. - Management of Feature Interactions in various other enterprises, such as banking, medicine, etc. Format: We hope to promote a dialogue among researchers in various related areas, as well as the designers and builders of telecommunications software. To this end, the workshop will have sessions for paper presentations, including relatively long discussion periods. Panel discussions and tool demonstrations are also planned. The first day of the workshop, October 11, is devoted to tutorials and discussions on areas related to feature interactions. Attendance: Workshop attendance will be limited to 100 people. Attendance will be by invitation only. Prospective attendees are asked to submit either a paper (maximum 5000 words) or a single page description of their interests and how they relate to the workshop. Proposals for tutorials and discussions are also requested (maximum 3000 words). About 16-20 of the attendees will be asked to present talks; a small number of tutorials and/or discussions will also be selected. We will strive for an equal mix of theoretical results and practical experiences. Papers will be published in a conference proceedings. Submissions: Please send five copies of your full original paper or interest description to: Kong Eng Cheng Department of Computer Science Royal Melbourne Institute of Technology GPO Box 2476V Melbourne, Victoria AUSTRALIA 3001 E-mail: kec@cs.rmit.edu.au Tel: +61 3 660 3266 FAX: +61 3 662 1617 Important dates are: February 28, 1995: Submission of contributions. May 15, 1995: Notification of acceptance. June 26, 1995: Submission of camera-ready versions. Workshop Co-chairpersons Tadashi Ohta (ATR, Japan) Nancy Griffeth (Bellcore, USA) Program Committee Co-Chairpersons: Kong Eng Cheng (Royal Melbourne Institute of Technology, Australia) E. Jane Cameron (Bellcore, USA) Jan Bergstra (CWI and University of Amsterdam, The Netherlands) Ralph Blumenthal (Bellcore, USA) Rolv Braek (SINTEF DELAB, Norway) Bernie Cohen (City University of London, UK) Robert France (Florida Atlantic University, USA) Haruo Hasegawa (OKI, Japan) Dieter Hogrefe (University of Bern, Switzerland) Richard Kemmerer (UCSB, USA) Victor Lesser (University of Massachusetts, USA) Yow-Jian Lin (Bellcore, USA) Luigi Logrippo (University of Ottawa, Canada) Jan van der Meer (Ericsson, The Netherlands) Robert Milne (BNR, UK) Leo Motus (Tallinn Technical University, Estonia) Jacques Muller (CNET, France) Jan-Olof Nordenstam (ELLEMTEL, Sweden) Yoshihiro Niitsu (NTT, Japan) Ben Potter (University of Hertfordshire, UK) Henrikas Pranevicius (Kaunas University of Technology, Lithuania) Martin Sadler (HP, UK) Jean-Bernard Stefani (CNET, France) Greg Utas (BNR, USA) Jyri Vain (Institute of Cybernetics, Estonia) Hugo Velthuijsen (PTT Research, The Netherlands) Yasushi Wakahara (KDD R&D Laboratories, Japan) Ron Wojcik (BellSouth, USA) Pamela Zave (AT&T Bell Laboratories, USA) Workshop Statement: The feature interaction problem is a major obstacle to the rapid deployment of new telephone services. Some feature communications system. Telecommunications software is huge, real-time, and distributed; adding new features to a telecommunication system, like adding new functionalities to any large software system, can be very difficult. Each new feature may interact with many existing features, causing customer annoyance or total system breakdown. Traditionally, interactions were detected and resolved on a feature by feature basis by experts who are knowledgeable on all existing features. As the number of features grows to satisfy diverse needs of customers, managing feature interactions in a single administrative domain is approaching incomprehensible complexity. In a future marketplace where features deployed in the network may be developed by different operating companies and their associated vendors, the traditional approach is no longer feasible. How to detect, resolve, or even prevent the occurrence of feature interactions in an open network is now an important research issue. The feature interaction problem is not unique to telecommunications software; similar problems are encountered in any long-lived software system that requires frequent changes and additions to its functionality. Techniques in many related areas appear to be applicable to the management of feature interactions. Software methodologies for extensibility and compatibility, for example, could be useful for providing a structured design that can prevent many feature interactions from occurring. Features are typically design to suit the purposes of a user or business, hence Enterprise modeling will play a role in the identification of certain classes of interaction, in particular the solution of an interaction in one enterprise may not be desired by another. Formal specification, verification, and testing techniques, being widely used in protocol engineering and software engineering, contribute to the detection of interactions. Several causes of the problem, such as aliasing, timing, and the distribution of software components, are similar to issues in distributed systems. Cooperative problem solving, a promising approach for resolving interactions at run time, resembles distributed planning and resolution of conflicting subgoals among multiple agents in the area of distributed artificial intelligence. This workshop aims to provide an opportunity for participants to share ideas and experiences in their respective fields, and to apply their expertise to the feature interaction problem. Workshop Announcement: 3nd International Workshop on Feature Interactions in Telecommunications Software Systems, October 11-13, Kyoto, Japan, Sponsors: IEEE Communications Society. In cooperation with ACM SIGCOMM and ATR, Japan. Contact Tadashi Ohta, ATR, 2-2, Hikari-dai, Seika-cho, Soraku-gun, Kyoto, 619-02, Japan, Tel: +81 7749 5 1230, Fax: +81 7749 5 1208, e-mail: ohta@atr-sw.atr.co.jp. ------------------------------ From: etoupin@toupin.com (Edward B. Toupin) Subject: Satellite / DECNet Problems Date: 13 Jan 1995 15:53:26 GMT Organization: Edward B. Toupin Reply-To: sn=morrison%g=tom%i=p%dda=tel=3536%texaco@mcimail.com, The message is sent for an associate. TOM MORRISON writes: We currently have an application in which DEC VAXStations communicate through DECRouter 2000s. The local area network uses DECNet and the routers that connect disparate local area networks communicate via 56k leased data circuits. The required throughput on these circuits does not exceed 20k. It is our desire to provide a diverse route for data using an X.25 based double hop satellite system. This circuit configuration has approximately 1.5 seconds of processing and propogation delay. In testing the proposed configuration, 56kb modems were connected back to back to conduct 1 megabyte file transfers using X.25. In this configuraton, circuit throughput averaged 45kbps. The modems were then replaced with a satellite circuit which caused the throughput to drop off to 1100 bps! Incidently the satellite system provides local acknowledgements at the X.25 level and no flow control messages were seen. In evaluating the satellite throughput, we have been told that DECNet has a required acknowledgement for either one of four packets generated at the NSP level. This acknowledgement is hard coded into DECNet and can't be changed. These required acknowledgements, coupled with the long propogation time of the satellite system combine to limit throughput. Please provide any insight you may have to the following questions: 1. Are NSP acknowledgements required after each or every fourth packet? 2. We thought that adjusting the buffer sizes in the routers would change packet sizes, however, in monitoring data communication with Trace we didn't see any change in packet size. Can packet sizes be changed (increased)? 3. Has anyone had similar experiences with similar results? 4. Any ideas about how we may increase throughput in the double hop satellite system? Regards, Tom Morrison ------------------------------ Date: Fri, 13 Jan 95 12:53:13 EST From: Bill Subject: Acronym for "Information Superhighway" For the benefit of the readers... Bill Edwards, HUMOR listowner, BEDWARDS@UGA.BITNET (uga.cc.uga.edu) ===================================================================== To leave HUMOR send LISTSERV@UGA.CC.UGA.EDU the command SIGNOFF HUMOR To subscribe send LISTSERV@UGA.CC.UGA.EDU the command SUB HUMOR Call- name FamilyName. A command goes in the 1st line of the message field. -------------Original message-------------- Date: Thu, 12 Jan 1995 19:03:12 -0500 Sender: UGA Humor List From: "Greg V." Subject: Acronym INFORMATION SUPERHIGHWAY: Interactive Network For Organizing, Retrieving, Manipulating, Accessing, and Transferring Information On National Systems, Unleashing Practically Every Rebellious Human Intelligence, Gratifying Hackers, Wiseasses, And Yahoos. Thanks to Kevin Kwaku, who obvoiusly has way too much time on his hands. - Greg V. NYGreg@AOL.COM "Roadkill on the Information Superhighway" ---------------- [TELECOM Digest Editor's Note: Gee, it sounds just like the CB Radio era back in the late 1970's when CB was at its height of popularity. The crazy people ruined CB ... I guess now they will make things so miserable on the Internet large numbers of people will drop out. PAT] ------------------------------ From: jmandel@carbon.cudenver.edu (Jan Mandel) Subject: Modem-Voice Incoming Call Switching Date: 13 Jan 1995 11:31:39 -0700 Organization: University of Colorado at Denver A while ago I have posted a question how to switch incoming calls to an answering machine or a modem. Many have pointed out that incoming modem call is just silence and it is the answering modem that makes the shreeking noise. Thank you all. Consequently to decide if the incoming call is modem or not one would have to subject all callers to the unpleasant shreek. Here is another possible solution: let an answering machine take all calls. If there is silence on the line after the beep (all answering machines can detect this condition), let it time out and switch to the answering modem. Since I need this for my office where after office hours I would dial in or others may call in to leave a message, that úÿ would work for my needs. I'll set the timeout for my calling modem large so that it waits longer for the carrier. I was also looking for a modem setup parameter like "answer only after 60 seconds" for the asnwering side but could find none. Anyone knows what hardware I may need for this? I need to buy an answering machine for the office anyway so I may just as well buy the right one. I already have a pair of Hayes Accura 288 V.FC modems a year old. No, I canot use alternate ring because this is a PBX line. This whole exercise is because of our phone bozos who will not let me have another PBX (=cheap) line in the office once they heard we have modems, for fear I actually might use it. A separate telco line would be too expensive. TIA for any suggestions. Jan Mandel, Center for Computational Math, University of Colorado at Denver jmandel@colorado.edu ------------------------------ From: mudaw@uxa.ecn.bgu.edu (David A. Webb) Subject: Legal Problem Due to Modified Radio Date: 13 Jan 1995 17:55:40 -0600 Organization: Educational Computing Network Dear Moderator, I was rather impressed with your knowledge of FCC regulations. I read that you are an attorney, and I know time is money, but I thought you would be interested in my situation. University police searched my dorm room in November, 1992 after I consented to the search. (Mistake #1) An officer found my 2 meter amateur transceiver, turned it on, and discovered it could transmit on frequencies licensed to the local county police. I was not in my room during the time of the search, so I had no control over its operation. The radio was confiscated, and I had to defend myself in front of the school board. The school did not find me in violation of any rules because I had a statement from a county officer who is also a Ham. The officer wrote he knew my radio was legal for me to possess. I was never accused of using the radio. I was never charged in a court of law concerning the radio. I petitioned the court for the return of personal property. This was December 20, 1994. I didn't take any evidence to support my side (Mistake #2). The States attorney had three witnesses. Witness #1 was the university officer who stated under oath that he used the radio to transmit on county frequencies to verify the modifications. He also stated in his professional capacity that my radio is illegally modified, and therefor illegal to possess. He further stated that he called the FCC and was told my radio is illegal to possess. Witness #2 was the county sheriff. He indicated in his professional capacity that my radio was illegal to own. He also voiced understandable concern for my capability to interfere with his frequencies. Witness #3 was a person who services amateur equipment. He stated that my radio is type accepted, and therefor it is illegal to modify. Illegal modification therefor makes my radio illegal to possess. The University officer must have called the field office in Chicago, because when I called there, I was also told my radio is illegal to possess. I called the Washington office, and the Director of the Private Radio Division is sending me a statement which will say that my radio is legal for anyone to possess, and its use is regulated by the FCC. (unless local laws prohibit a radio which will transmit on police channels) Witness #2 was simply giving an opinion. Witness #3 was wrong about the type acceptance. Amateur equipment transmitters are not type accepted. Its internal receiver it accepted to receive everything it was modified to receive. I tried to submit the county officer/ham's statement, and the states attorney objected because the officer was not present for cross examination. Am I going to run into the same trouble when I try to submit the statement from the Private Radio Division of the FCC? If so, how can I get around this obstacle? I reported the discrepancy of the field office to the FCC's General Councils Office, and they will be investigating the person who gave me the faulty information. Although the university police violated FCC rules, it occurred over a year ago, and therefor time limits on me reporting them has expired. Neither the States Attorney, nor any of his witnesses, presented the judge with any law I *supposedly* violated. The judge ruled to NOT allow me to have my radio back UNLESS I paid to have it unmodified. I filed a motion for the Judge to reconsider his ruling, which is scheduled for February 9. The reason I have opted to do this on my own is that the radio isn't worth more than a few hundred bucks. I am pursuing this on the principal. My radio is legal for me to own, and I am tired of the harassment from university police. Please send your comments to me at mudaw@ecom.ecn.bgu.edu. [TELECOM Digest Editor's Note: First, and most important, I am not an attorney, and you are not my client. I will suggest that depending on how strongly you feel about the principles involved here and getting your equipment returned, you *should* consult an attorney who specializes in communications law, preferably in your community if possible, although quite a few (most?) of those people are in practice in Washington, DC and environs. We do have attornies whose practice is specialized in the area of federal communications law on the Digest mailing list, and perhaps one or more of them will respond to you directly at least once on a pro-bono basis offering some suggestions or help. My feeling is the cost involved for *good* legal representation in this area will be far in excess of the value of the equipment involved. This will have to be your decision in connection with any discussions you have with an attorney who is competent to assist you. I cannot do so. Good luck with this. Perhaps other Digest readers will have suggestions also. PAT] ------------------------------ From: Bill Parrish Subject: Old Rotary Service Question Date: Fri, 13 Jan 95 7:58:32 PST Pat's reply to the thread about scanners and cordless phones dealing with party lines reminded me of something I had always wondered about. In the early 70s, I went to UCSB, and we were serviced by GTE in the dorms. Occasionaly folks would decide to "share" a phone connection by making their own patches into terminal cabinets ... resulting in an illegal but effective party line arrangement. I recall that if the phone had the wrong type of filter in it that you would sometimes get the "pinging" sound rather than a vigorous "ring" when an incoming call came in. But there was a second funny thing about these "extensions" that was rather odd ... you sometimes could not make long distance calls on them ... and that always seemed odd to me. If I recall right, there was some sort of a movable pin on the back of the dial that could be put into one of several (three?) positions, and if you moved the pin, it would enable the long-distance capability. Could someone explain how that worked? (I could be remembering wrong ... it's been a long time, but I always wondered how that worked). Bill Parrish (916) 785-4986 M6KV Hewlett Packard Systems Technology Division 8000 Foothills Blvd. Roseville, CA 95747-5596 HPDesk: Bill_parrish@hp5200.desk.hp.com Unix to Unix: bparrish@hprpcd.rose.hp.com Fax: (916) (or TELNET) - 785-3096 ------------------------------ From: mkelly@gabriel.resudox.net (Mark Kelly) Subject: Call Overflow Question Date: 13 Jan 1995 22:38:58 GMT Organization: Resudox Online Services I have question for the telephony wizards out there. A single number DN #1 has been assigned to a trunk group (say a T1, 24 channels). When all 24 channels are busy, its desirable to route all incoming calls to the DN #1 to another number (DN #2). Can anyone think of a way to do this that doesn't involve adding a extra trunk group at the switch and pointing it to the second number. Any suggestions or hints would be welcome. Mark Kelly Advanced Multi-Point Conferencing 320 March Road, Suite 102 Kanata, Ontario K2L 1Z8 1-800-900-4249 (Reservations) 1-613-592-5752 ------------------------------ Date: Fri, 13 Jan 1995 19:33:42 EST From: Paul Robinson Organization: Tansin A. Darcos & Company, Silver Spring, MD USA Subject: 360 Degrees of Jumping the Gun I decided to check Pat Towson's comments about the 630 area code in Chicago. I first tried 1-700-555-1212 and it told me I have AT&T. I dialed 1-630-555-1212 and when asked what city, I asked the operator if it was the Chicago operator, and she said yes. I realized I really didn't have a reason to call anyone there. So, next I decided to see if the new area codes are in place here, and dialed 1-360-555-1 Oops, the phone times out on me! Now, for the fun part. I dial 611 and explain that I *can* call 1-630 but *can't* call 1-360 and the agent says "It must be in your phone." Yeah, right. I explained that I have dialed the number by going through 1-800-CALL-ATT and using a calling card. I explained that the same thing happens from other phones, on different lines. She put me on hold and when she came back she said that there is a routing problem, and she'll write up a trouble ticket. We'll see what happens. It must have been difficult (knowing my trouble with Bell Atlantic) because I got a return call a few minutes ago, about an hour after I placed the call to 611. According to the person calling me, the "official" date that area code 360 goes into effect isn't until tomorrow, which is why Bell Atlantic is not accepting calls placed to that area code yet. So, if the statment is correct, those places that are accepting calls to the 360 area code are actually "jumping the gun". ------------------------------ From: routers@halcyon.com Subject: FAQs on Campus Connectivity Date: 13 Jan 1995 12:14:06 GMT Organization: Northwest Nexus Inc. NEW ANSWERS FOR FAQs ON CAMPUS NETWORKS AND CONNECTIVITY This posting may be freely distributed to Internet and commercial online sites. Date: January 12, 1994 Keywords: UTP distance standards, campus networks connectivity, ethernet, wireless, LAN, microwave, repeaters, video 1. QUESTION: What is the maximum bandwidth that 4-wire copper UTP can handle in campus environments? ANSWER: ---E-1 up to 2.5 miles (4 km) 2. QUESTION: What is the longest distance that 4-wire copper UTP can transmit at T-1 band width? ANSWER: ---5 miles (8 km), up to 7 miles (11.2 km) with a repeater 3. QUESTION: Can you transmit data, voice, and video across 4-wire UTP at the same time without cross-talk? ANSWER: ---Yes 4. QUESTION: What is the maximum distance that ethernet at 10 Mbps can be extended? ANSWER: ---1500 ft (495 m), up to 3000 ft (990 m) with repeater 5. QUESTION: Is there a wireless solution that would allow a campus to connect all buildings together, and allow any PC or laptop computer on campus to communicate, even if they move about the campus? ANSWER: ---Yes. One solution allows building -to- building connections up to 6 miles (9.6 km), and allows any PC or laptop to be on line. It operates at 2 Mbps, has SNMP, and requires no FCC licence. 6. QUESTION: Are there any wireless solutions at 10 Mbps for LAN-to-LAN connections? ANSWER: ---Yes. A microwave solution allows LANs to connect up to 5 miles (8 km). This same system has options that will allow voice, data, and video at the same time, in either 4 -T1 slots, or 8 -T1 slots. The 8 -T1 version can handle 192 voice-grade circuits. For further information and product data sheets, please contact Router Solutions (routers@halcyon.com), or check our FTP site: ftp.halcyon.com /pub/local/routers ------------------------------ From: TELECOM Digest Editor Subject: Would You Believe More Rain on the Way? Date: Sat, 14 Jan 1995 08:00:00 CST Listening to WNIB on the radio this Saturday morning as I work on this issue ... the eight o'clock news says 'up to six more inches of rain due in California throughout the weekend ... more evacuations probably will be required ...' Well, good luck and my best regards, folks. It seems like the people in California spend all summer burning the place down, then spend all winter enduring mud slides and flooding. We are getting a lot of rain here today also, but the only effect has been to melt all the snow which had accumulated and leave some *huge* puddles of water to navigate at curbs where the street sewers are plugged, etc. Have the floods in California affected telephone service to any extent? PAT ------------------------------ End of TELECOM Digest V15 #31 *****************************