Received: (from ptownson@localhost) by massis.lcs.mit.edu (8.9.1/8.9.1) id BAA15285; Fri, 30 Apr 1999 01:57:08 -0400 (EDT) Date: Fri, 30 Apr 1999 01:57:08 -0400 (EDT) From: editor@telecom-digest.org Message-Id: <199904300557.BAA15285@massis.lcs.mit.edu> To: ptownson Subject: TELECOM Digest V19 #65 TELECOM Digest Fri, 30 Apr 99 01:57:00 EDT Volume 19 : Issue 65 Inside This Issue: Editor: Patrick A. Townson Re: Telephone Pairs and Lines (Curt V) Re: Portable Local Numbers: Why Aren't They? (Patrick Hollowell) Re: Portable Local Numbers: Why Aren't They? (Thor Lancelot Simon) Re: Portable Local Numbers: Why aren't they? (Allen Mcintosh) Re: Good Conference Phone? (Carl Navarro) Re: Use of Cellular Phones in Schools (Thomas Peter Carr) Re: Columbine and Cell Phones (was Re: Cell Phones in Schools) (B Ackerman) Re: Sprint PCS Loses Too ... (Brad Ackerman) Re: Dealing With Comcast? Buy a Cable Modem and Go to Jail (Bill Levant) Re: Dealing With Comcast? Buy a Cable Modem and Go to Jail (Max Buten) Archives Renovation Update (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 networks such as Compuserve and America On Line, and other forums. It is also gatewayed to Usenet where it appears as the moderated newsgroup 'comp.dcom.telecom'. TELECOM Digest is a not-for-profit, mostly non-commercial educational service offered to the Internet by Patrick Townson. All the contents of the Digest are compilation-copywrited. You may reprint articles in some other media on an occassional basis, but please attribute my work and that of the original author. Contact information: Patrick Townson/TELECOM Digest Post Office Box 765 Junction City, KS 66441-0765 Phone: 415-520-9905 Email: editor@telecom-digest.org Subscribe/unsubscribe: subscriptions@telecom-digest.org This Digest is the oldest continuing e-journal on the Internet, having been founded in August, 1981 and published continuously since then. Our archives are available for your review/research. URL information: http://telecom-digest.org Anonymous FTP: hyperarchive.lcs.mit.edu/telecom-archives/archives (or use our mirror site: ftp.epix.net/pub/telecom-archives) Email <==> FTP: telecom-archives@telecom-digest.org Send a simple, one line note to that automated address for a help file on how to use the automatic retrieval system for archives files. You can get desired files in email. ************************************************************************* * 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. * ************************************************************************* In addition, a gift from Mike Sandman, Chicago's Telecom Expert has enabled me to replace some obsolete computer equipment and enter the 21st century sort of on schedule. His mail order telephone parts/supplies service based in the Chicago area has been widely recognized by Digest readers as a reliable and very inexpensive source of telecom-related equipment. Please request a free catalog today at http://www.sandman.com --------------------------------------------------------------- Finally, 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. Please make at least a single donation to cover the cost of processing your name to the mailing list. 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: Curt V Subject: Re: Telephone Pairs and Lines Date: Thu, 29 Apr 1999 15:22:24 -0500 Organization: Posted via RemarQ Communities, Inc. Hey, as long as you are talking about lines to a house, I have been trying to find one of the old devices that Bell used to use which allows two POTS lines to be muxed together over one pair of wires so that they could actually be used at the same time. I have an application that doesn't allow me to use a digital line (e.g., ISDN BRI) and I can't pull another pair of wires into the location. Anyone have any idea where I can find one of those? Thanks, Curt V Highland Park, IL ------------------------------ From: patrick@hollowell.net (Patrick Hollowell) Subject: Re: Portable Local Numbers: Why Aren't They? Organization: Network Management Associates, Inc. Date: Thu, 29 Apr 1999 22:30:26 GMT Aside from that, 800 calls are routed to an IXC for transport. LNP calls are not. Patrick Hollowell Network Management Associates, Inc. Charlotte, NC patrick@hollowell.net ------------------------------ From: tls@panix.com (Thor Lancelot Simon) Subject: Re: Portable Local Numbers: Why Aren't They? Date: 28 Apr 1999 23:11:14 -0400 Organization: PANIX -- Public Access Networks Corp. Reply-To: tls@rek.tjls.com In article , Art Kamlet wrote: > In article , Gideon Stocek > wrote: >> Can someone provide a good reference for changes required to ISUP >> and/or TCAP application requirements for LNP? I'm curious as to how >> this is all supposed to work. > You are posting from a Lucent addrress yet ask about LNP? My advice > is to check with the lucent LNP standards folks. Try the ActiView > folks in Holdmel, for example, for an LNP person. > Basically there will be a few additional applications transactions > which will have to query the LNP SCPs or SCP-databases (the SCP can > manage the SS7 queries to SCDs which act just like databases.) "Not exactly". There's one key change to ISUP, the addition of the TCNI ("tick-knee") bit to the Initial Address Message, which indicates that LNP database lookup has already been done and that the called party address is an LRN. (Wow, I hope I got that right, I've avoided LNP work like the very plague, though I was trained on this stuff mostly by accident.) Unlike predecessor technologies, in LNP the magic is *not* all in the "databases" (which is a pretty silly thing to call remote-procedure- call servers that remote-control switching hardware, but whatever ...). There are a number of bits of major new functionality required to support LNP (at least in widespread deployment -- yes, this has been kludged together various ways in the absence of even SS7 itself): * 10-digit Global Title Translation in STP's (SS7 routers) * Changes to ISUP itself (the addition of the TCNI bit) * Elimination of F-links between switches (which were mostly gone anyway, but...) because you could get into a situation where you could route the *call* but not the *lookup* that would tell you you were misrouting the call * Distributed database update mechanisms * AIN 0.2 (the SDS instead of the "3/6/10" trigger, formalization of trigger priorities, and explicit error handling procedures) * Huge improvements to switch and SCP transaction performance. In one very common implementation, the LNP query is actually handled by a fixed-function "SCP" that's actually embedded in the Tekelec Eagle STP itself. However you do it, LNP means your SCP performance probably has to get a hundred times better than it was before. Switches have had to learn to handle a LOT more outstanding transactions, as well. SS7 networks have had to be built-out for vastly more traffic per call. The load on the SS7 network is substantial enough that some companies do rather unusual things just to save a few bytes here or there: about a year ago I spoke to one ILEC and SCP vendor who were working together to do the actual LNP queries as ITU CS-1 IN queries instead of Bellcore AIN queries, because a difference in encoding some field saved them 10 bytes per message. Not a big deal until you realize that's probably 5-10% of the total bytes it took to set up the call *completely* before, if not more ... Thor Lancelot Simon tls@rek.tjls.com "And where do all these highways go, now that we are free?" ------------------------------ Subject: Re: Portable Local Numbers: Why Aren't They? Organization: Telcordia From: mcintosh@bellcore.com (Allen Mcintosh) Date: 28 Apr 1999 12:08:55 -0500 In article , Ralph Hyre wrote: > What's the real issue with Local Number portability? > 800 Number portability was achieved years ago (1993?), and the > technology and operational issues are basically the same, with some > minor scaling issues. Let me outline a few of the "minor" issues: Let's say that local carrier "A" has been assigned NPA-NXX 999-999 under the old scheme. You move your number, 999-999-1212, to local carrier "B". Someone from local carrier "C" calls 999-999-1212 using IXC "X". 1) When should that database dip happen? Should "C" forward the call through "X" to "A", and only do a database dip if "A" says your number has been moved? (Called query-on-release.) This is disadvantageous to "B", since calls to numbers serviced by "B" take a fraction of a second longer. For this reason, query-on-release was not allowed. The alternative is a database dip for each call to an NPA-NXX that has been marked "ported". If you assume LNP has been implemented everywhere, this means a database dip for every inter-switch call. 2) Who should do the database dip? "C" or "X"? These are political issues, so sorting them out took time. 3) At the time of 1-800 portability there were switches that could not do the IN SS7 signaling for a database dip. (For all I know, there may still be switches out there that can't do IN/AIN.) Since 1-800 traffic is only a fraction of all calls, it was reasonable to forward all such calls to a tandem and let it do the work. If ALL calls (or just most of them) require a database dip then this solution is no longer feasible. Upgrading switches takes time and $$. 4) SS7 signaling for an average POTS call takes on the order of 80 bytes. Signaling for the average database dip takes roughly 150 bytes. Suppose every POTS call requires a database dip. What would this do to the originating carriers' SS7 networks? 5) Databases used for 1-800 are too rich (and too slow) for local number portability. 6) Suppose "A"'s database says that 999-999-1212 has moved to "B", but "B"'s database says "A" still owns the number. What will happen when "C" or "X" tries to figure out where to route the call? How do you maintain consistency in the absence of a central database (as for 1-800)? 7) Routing for ISUP call setup in SS7 is based on the NPA-NXX of the called number. This won't work if numbers are portable. The solution was to use a bogus called number and "hide" the real one. (This wasn't an issue with 1-800.) I don't mean to imply that these are all hard problems, just that there were legitimate technical issues here that required some thought. ------------------------------ From: cnavarro@wcnet.org (Carl Navarro) Subject: Re: Good Conference Phone? Date: Wed, 28 Apr 1999 13:28:01 GMT Organization: Airnews.net! at Internet America On Tue, 27 Apr 1999 09:21:47 GMT, ffaure@bigSPAMGAZETTAIDAMEfoot.com (F. Faure) wrote: > I need to buy a new conference telephone, as everyone complains that > the Panasonic KX-TS700FR-B we bought a couple of months ago is > terrible. Should have done my homework instead of trusting that > salesman ... Evidently everyone else hated the Panasonic system too. My distributor tells me they are MD'd, but Alltel still has some stock. > Could someone recommend other brands? I found infos on 3Com/USR's > site, and also www.phonezone.com: They tell me the 3C/USR 1000's are MD'd too :-(. I have really good luck with those. That makes POLYCOM the winner by default! I have not used them, they're pricey. At 5X the price of a Panasonic, it's not an item you bring into inventory for a demo :-). Carl Navarro ------------------------------ Subject: Re: Use of Cellular Phones in Schools From: carr@falcon.si.com (Thomas Peter Carr) Date: 29 Apr 1999 09:03:09 -0500 Organization: Smiths Industries Matt Ackeret writes: > In article TELECOM Digest Editor > noted: >> NO, we do not need any more gun laws; NO we do not need any knee-jerk > If they did not have access to guns, it would have been much more > difficult to kill so many people. Why is it that everyone has forgotten that this is NOT the worst killing of school children. The worst was 38 students at Bath, Michigan on 18 May 1927. http://detnews.com/1999/nation/9904/22/04220188.htm Without guns, people who want to kill will find a way. Thomas Peter Carr | I have a dream, ... carr_tom@si.com (Internet) | M L King Jr 08/28/63 616-241-8846 / 616-241-7533 FAX (Telephone) | Smiths Industries, MS 3D1; 3290 Patterson Ave SE; Grand Rapids, MI 49512-1991 ------------------------------ From: bsa3@cornell.edu (Brad Ackerman) Subject: Re: Columbine and Cell Phones (was Re: Cell Phones in Schools) Date: 28 Apr 1999 23:19:05 -0400 Organization: NERV GeoFront, Tokyo III Jeremy Beal writes: > It was only about 10 minutes later that they realized that there were > televisions located in every classroom, and that there was a very good > chance that the attackers had heard the information from the phone > call. The station promptly asked anybody trapped to call 911 rather > than the station. An unintended consequence to the rapid sharing of > information ... Another problem -- if you're dealing with only slightly more sophisiticated opponents, you need to worry about said opponents eavesdropping on the phone call. Strangely enough, analogue telephones are still being sold in the US, and only GSM phones have any encryption worth mentioning. With analogue phones, listening in is as simple as turning on a scanner, keying in 870.000 MHz, and pressing start. Brad Ackerman N1MNB "...faced with the men and women who bring home bsa3@cornell.edu the pork, voters almost always re-elect them." http://skaro.pair.com/ -- _The Economist_, 31 Oct 1998 ------------------------------ From: bsa3@cornell.edu (Brad Ackerman) Subject: Re: Sprint PCS Loses Too ... Date: 29 Apr 1999 00:10:27 -0400 Organization: NERV GeoFront, Tokyo III Ed Kummel writes: > Personally, having experience in European GSM (900MHz), US GSM (also > known as PCS, 1900MHZ) US digital, both TDMA (AT&T) and CDMA (LEC) and > analog, I personally prefer the voice quality of the analog > system. Oro? I've used every American air interface, and GSM is by far the best in this regard. CDMA comes close with good equipment (Sony phones have good audio quality; Samsung phones are quite pathetic.), and analog -- ouch! Mabye analog provides acceptable quality if the cell is coming in at full quieting, but that just doesn't happen where I am. My GSM 1900 handset (Siemens g1050) has audio quality which, if not equal to a landline, is good enough so that nobody can tell the difference, and it does that even if the signal strength is only S4 or S5. Also, I mentioned the security aspects of analog phones in another Digest thread -- in short, it's so easy to eavesdrop that you have to assume someone is doing so. The NSA could very well have equipment to crack A5 encryption, but I'm not an employee of a foreign company with a product ripe for Fort Meade-aided industrial espionage, and I doubt that they're interested in credit card fraud. > It seems that the digital networks that are prevalent (Powertel, > Sprint, AT&T, Pactel, Western Wireless) is looking more and more > like the way the analog cellular system was 5-8 years ago. (no > roaming between carriers, and if so, no calls could be received...we > still have the problem of no international dialing on analog > systems). As with Ryan, I've had no problems roaming on any GSM network, and I've done it on Fido, Aerial, Deutsche Telekom, Mannesmann Mobilfunk, and the Netherlands' PTT's 900 MHz network (I forget what they call it; I was only there for an hour.) Have you ever tried roaming outside of North America on a non-GSM phone? You can't -- unless you count AT&T's "option" of paying $50/year and $2.50/minute for a SIM card. Considering that my recent trip to Germany cost me $1/minute on my Omnipoint SIM, and you could do better than AT&T's price by buying either a prepaid or a two-year contract (the latter if you do more than a few hours of roaming/yr), I wouldn't call that much of an option. BTW, back when I was a Frontier customer, $1/minute was what I used to pay to roam in Toronto, NYC, or Boston, minus Frontier's $3/day roaming charge. Now, Boston and New York City, along with every other Omnipoint market, are in my home area, and in Germany, roaming would have cost even less if I had paid more attention to whether I was on Deutsche Telekom or Mannesmann. Finally, if you really think that the analog networks are fully deployed, myself and John Levine can give you a rather enlightening test drive through upstate New York. There are plenty of coverage nodes around here, and I expect that Omnipoint will provide considerably superior signal when they initiate full deployment. (Last I heard, that was scheduled for 2Q, of which two months remain.) Brad Ackerman N1MNB "...faced with the men and women who bring home bsa3@cornell.edu the pork, voters almost always re-elect them." http://skaro.pair.com/ -- _The Economist_, 31 Oct 1998 ------------------------------ From: Wlevant@aol.com (Bill Levant) Date: Wed, 28 Apr 1999 21:11:30 EDT Subject: Re: Dealing With Comcast? Buy a Cable Modem and Go to Jail Reply-To: Wlevant@aol.com Geez, Comcast got lucky. It's a damned good thing that Ms. Sammel is so good-natured. *Criminal* charges ?? Expungement of a criminal record ?? I would have sued the f**k out of 'em. Bill [TELECOM Digest Editor's Note: I think they were very lucky. The worst that has happened to them or is likely happen is they have been seeing a loss of customers as a result of the bad publicity on this. It has been all over the internet now, in several newsgroups and mailing lists as well as this Digest. It has been covered on television in a couple places as well as on the radio. Since I put the story out here a couple days ago, I've gotten email from people in Comcast service territory using 56 K who were considering changing to cable modem who now say they are going to think about it a bit longer, at least until/if/when a viable alternative to Comcast and @home is available in their area. Like yourself Bill, my conclusion is Ms. Sammel must be awfully good- natured to have allowed this to pass as she did. She is obviously under the erroneous impression that the only way her 'record could be expunged' was by releasing Comcast from any liability in the matter, and that is a complete lie. She does not need their cooperation or approval on that matter at all. There are laws in her state like every other state that a person who has no previous criminal record (let alone be found not guilty) who gets in no other trouble for some period of time can apply for expungement. In any event, I would have held off on applying for expungement in order to not have to give Comcast any waivers. First, like yourself, I would give them a good suing. Not, as she suggested, on the basis of malicious prosecution or falsely lodging charges against her, both of which require pretty strict qualifications. I would sue them for harassment and fraud; ie they took her money with the understanding that she was their customer, then made claims that she was not their customer (instead, someone stealing from them). I would sue them because they damaged my reputation. I would sue them for interupption of my service on the occassions the wires were removed by the latest imbecile they sent out without my approval and because later the two traps on the line caused the signal to be worthless. I would sue them for making me wait 45 minutes on hold, and for breaking appointments without notice to do installs, maintainence, etc. I most definitly would try and start a class action, representing other subscribers of Comcast who were or had been similarly situated. I would sue them for every broken promise and worthless claim they had made. The only thing I would NOT do is I would NOT gvie them a waiver on malicious prosecution in order to obtain an expungement. That can be done independently (regardless of whatever baloney the Comcast attorney gave Sammel) and would not force me to release them from liability. In other words, if I have not been perfectly clear, I would happily fix things so that their attornies were tripping over their own feet coming and going up and down the steps of the courthouse to respond for their client. And don't say it cannot be done. In 1974 I sued the First National Bank of Chicago for fraud, and theft of money through the US Mail. I only did it when the United States Postal Inspection Service said they could not force the bank to comply with postal laws, and when the bank said to me they had no intention of complying with postal laws. Oh no? Let's check it out. I won that case, and about the same time my efforts via the FCC forced MCI to change its advertising. I've told of that incident here in the Digest; if anyone wants to see it again, let me know. Cableco -- large parts of the industry -- are more sleazy than telco ever thought about being in Ma Bell's heyday. There are a few exceptions. By the way, Ms. Sammel, not only do you NOT need Comcast's approval to have your record expunged, they would really love it if you begin attending the public meetings of the cable commission in your community and you frequently filed formal complaints their attorney had to answer prior to franchise renewal time each year or two. PAT] ------------------------------ From: maxbuten@home.com (Max Buten) Subject: Re: Dealing With Comcast? Buy a Cable Modem and Go to Jail! Organization: Ampers and Sons Date: Thu, 29 Apr 1999 01:21:56 GMT In article <99.04.27.00013@telecom-digest.org>, editor@telecom-digest.org says... > If there are any readers of TELECOM Digest or the c.d.t. newsgroup who > still remain unconvinced about whether Comcast and Comcast@home are > If this does not scare you folks on the east coast away from doing > business with them, I do not know what would. Are you suggesting that I give up my cable connection with Comcast@home and go back to 56k modem? Nooooooooo Waaaaaaaaaaay! Or maybe I should pay 4 times as much to Bell for slower service? Noooooooooo Waaaaaay! Max Buten maxbuten@home.com http://members.home.net/maxbuten/ [TELECOM Digest Editor's Note: I am only suggesting one thing, Max. You might want to find out if your local county jail has jacks where you can plug your computer in to the internet so you can stay in touch with everyone here while you wait for a Comcast employee who 'stepped away from her desk' or 'been in a meeting all day' or 'been in training class all week' or wants to tell you to call some other division of the company so they can put you on hold for 45 minutes before giving you a run-around to return your call. Even though they told Ms. Sammel they were going to implement procedures, etc .. a little birdie today told me they had done nothing of the sort, and that when the 'Sammel incident' -- as it is now known was brought up at an industry meeting recently, some people from Comcast who were present were 'dumbfounded and speechless' as my correspondent put it. They had never even heard of the incident. That's how well Comcast and @home corrected the problem. They made sure most of their employees did not even find out about it. Apparently @home was making a presentation to some cableco executives and telling them how well they communicated and worked together. Someone brought up the 'Sammel incident' and said if you and Comcast don't speak to each other or sychronize your work together, why should we believe you when you say you will talk to us and work with us? And that, said the little birdie to me, was when the room became silent, a few jaws dropped open, and none of the presenters at the meeting knew quite what to say or how to respond. Their employer had kept them in the dark on it. Obviously, cable modem is the way to go these days if you have access to it. I am only suggesting Max, that if your connection is with @home, through arrangements with Comcast, you'd better be careful. If there are alternative connection methods which are similar, I would select one of them instead. A lot of cablecos are going to be doing their own thing. Consider that when it becomes available. PAT] ------------------------------ Date: Thu, 29 Apr 1999 23:16:23 EDT From: TELECOM Digest Editor Subject: Archives Renovation Update As of Wednesday, music is now available to Netscape users of the archives as well as the Internet Explorer visitors. The problem was that the Netscape Server at lcs.mit.edu did not have the MIME type 'audio/midi' correctly defined. That has now been corrected, and I thank Mary Ann Ladd for taking a couple minutes to work on it for me -- for all of us really. So feeling energetic and knowing for sure it would only take me 30-45 minutes or so, I decided to make what small changes would be required to synch the pages so that Opera browsers would be included. 30-45 minutes! hahahahahaha! Since Opera tends to go along with most HTML commands that Internet Explorer will accept, it should be easy enough to go to wherever a browser test is done and where looking for navigator.appName to be 'Internet Explorer' simply change it to say 'Internet Explorer || Opera' meaning one or the other. Then I found that Opera uses the appName string 'Netscape' ... meaning, it wants people to think that it is part of that group. That, even though it uses Explorer's 'bgsound src' to play music rather than Netscape's 'embed src'. I could not very well do any browser tests with a situation of 'be either IE or Netscape' so using Opera's app.Name was out. The so-called 'navigator.appCodeName' on all browsers these days seems to be 'Mozilla', a name that Netscape was using from the beginning, then in the early days when they were way ahead of Microsoft with browser features, Microsoft stole 'Mozilla' to put in their browser name so that web sites would accept them on an equal basis. Now Opera calls itself 'Mozilla' also. So much for that. The User_Agent string was a long, unweildy thing in every case which I never was able to type in correctly. But appVersion at least was unique, allowing the very simple '3.' as a way to say this is an Opera browser instead of an appVersion 'MSIE' guess-who browser. So after some logic exercises, I was able to write it up so that everything was assigned, then it if was not 'MSIE' *and* not '3.' therefore let's assume it is Netscape-for-real and make the needed reassignments to Netscape's way of doing things. Now let's go look things over with the Opera browser ... A choice of music or not appears, and the music plays as requested. Good! But something is not quite right ... it appears that Opera sticks in unwanted line breaks after a command that has nothing to do with the text; a background color instruction for example, or a background music command ... bingo, the rest of the text gets dropped a line. Opera has a hard time dealing with indenting the text to go around images the way you want it, and although it will do it, you have to say it totally different than the way you say it to Netscape or IE. Then is when I discover it really comes much closer to being in the Netscape 'family' than in the Explorer style. Throughout the opening page of the Archives using Opera I would find that (having assigned it to go along with IE) there were all these lines showing up centered that should not be, and lines that would not start next to a .gif where I wanted them, etc. But the worst was yet to come! On IE and Netscape browsers, using a 'target=new' instruction as part of an anchor allows for a smaller window as part of a new instantiation of the browser to open inside the large main window. This is good for footnotes or other incidental items you want people to see without taking them away from the main page at your site. IE actually starts a new browser with a small window, carries over the 'history' to the new browser, and allows the user to click it shut and once again view a full screen from the main browser. Netscape simply opens a new browser with full screen, forcing the user to narrow it down somewhat as desired, but at least the history is carried over, along with commands to close the window and go back where you started automatically, etc. Opera has no idea what 'target=new' means as part of an anchor. It closes the browser that was running and opens a new one, shutting down everything on the old browser instance ****except the music*** but it forgets all the history (thus no backward/forward arrows) and on closing that window you are out of it totally. If you choose as an alternative to use the address bar, you can keep the browser alive alright, and go wherever you want, but with the music **from the first browser** never going away, just playing and repeating itself endlessly. While 'bgsound' stays open with a target=new but shuts off when the main window is either (a) minimized to the task bar or (b) the page is reloaded from cache or the server, 'embed src' will stay open on being minimized to the task bar as well as with target=new. And if you do target=new while Opera is handling bgsound, it goes totally buggy: the music will never shut off, period except when the browser is totally terminated. Opera has no way that I can tell to force a page to be reloaded from the server rather than from cache, although I am sure there must be some way of doing it; I just have not figured it out. After '45 minutes' I looked at my clock and saw that it was 5:10 AM ... so I quit to go to bed. What I may do in the next day or two is write a different index.html page; identical in their links and comments, etc, but with Opera's idea of a good time where the HTML is concerned. Then when I see them coming, I will redirect them to the other page. Seriously, I would rather be the contortionist here rather than force users to get the browsers I want them to use. In the meantime, as I always did say, "this page is best viewed if you stop by my office and look at my monitor" ... I also corrected a small bug that occassionally gave the caller no choice of music at all and a totally blank background. It would be too incredibly boring to try and explain how that bug came about. For now, cheerio! http://telecom-digest.org "Sorry, no Make Spam Fast, no Nude Teens, no warez, none of the very traditional internet fare: just all you ever wanted to know about telephones and telecommunications." PAT ------------------------------ End of TELECOM Digest V19 #65 *****************************