For your convenience in reading: Subject lines are printed in RED and
Moderator replies when issued appear in BROWN.
Previous Issue (just one)
TD Extra News
TELECOM Digest Tue, 17 May 2005 19:37:00 EDT Volume 24 : Issue 218 Inside This Issue: Editor: Patrick A. Townson Measuring Availability in Service Level Agreements (slasupport) AT&T Licensed the Transistor For Free (Lisa Hancock) Vonage Improvement: No More Dial 1+ (John Schmerold) Survey: Mobile Video Gets Lukewarm Support (Telecom dailyLead from USTA) Foreign Exchange (FX) Lines Still in Use? (Lisa Hancock) Re: Very Early Modems (Brad Houser) Re: Very Early Modems (Lisa Hancock) Re: FAQ: How Real ID Will Affect You (jmeissen@aracnet.com) Re: Traveller Seeks Phone Advice (Joseph) Re: Will 911 Difficulties Derail VoIP? (Dean M.) Re: Vonage Changes 911 to Opt-Out (Robert Bonomi) "Popular Vote" (was Re: FINAL Words on Sodomy Insane) (Carl Moore) Telecom and VOIP (Voice over Internet Protocol) Digest for the Internet. All contents here are copyrighted by Patrick Townson and the individual writers/correspondents. Articles may be used in other journals or newsgroups, provided the writer's name and the Digest are included in the fair use quote. By using -any name or email address- included herein for -any- reason other than responding to an article herein, you agree to pay a hundred dollars to the recipients of the email. =========================== Addresses herein are not to be added to any mailing list, nor to be sold or given away without explicit written consent. Chain letters, viruses, porn, spam, and miscellaneous junk are definitely unwelcome. We must fight spam for the same reason we fight crime: not because we are naive enough to believe that we will ever stamp it out, but because we do not want the kind of world that results when no one stands against crime. Geoffrey Welsh =========================== See the bottom of this issue for subscription and archive details and the name of our lawyer; other stuff of interest. ---------------------------------------------------------------------- From: slasupport <lswanzer.slasupport@earthlink.net> Subject: Measuring Availability in Service Level Agreements Date: 17 May 2005 12:14:46 -0700 Dear All, Availability is one measure of quality used in Service Level Agreement programs by telecommunication providers today. The way availablity is measured by vendors determines the compensation customers receive for service outages and determines how good the guarantee is. The way the measures are done today is via time series, i.e. measure availability over time. This doesn't take into account the network size. The only way to take into account network size is to measure availability across the network. Doing so provides compensation based on the amount of the network that was not available. Please see below for a complete, but concise, summary of what the different availability measures actually guarantee! Thanks Measures of Availability Availability of service is measured today using time series data by all vendors in the telecommunications industry, for all their services. Cross section data is not used today to measure availability. But cross section data is very useful in quantifying a customer's network availability. The difference between the times series data and cross section data is: 1. Times series measures the availability of an individual IP-VPN site, Frame/ATM port or pvc, or Private line circuit over time. 2. Cross section data measures the availability of an IP-VPN Network, Frame/ATM Network or Private Line Network at a point in time. In other words: 1. Time series measures Site Availability, Port Availability, PVC Availability, or Circuit Availability for IP-VPN, Frame/ATM and Private Line service respectively. These measures are used in SLA programs today. 2. Cross section data measures Network Availability for a IP-VPN Network, Frame/ATM Network or Private Line Network. These measures are not used in SLA programs today. (The name "Network Availability" is used to describe availability measures by some vendors in their SLA programs. But the measurement is a time series measure, a measure of availability on a site, port or pvc over time, not a measure across the network.) The cross section approach is a patent pending methodology of L. Swanzer - E2E SLA Support, LLC. Their use requires license be obtained by the telecommunications providers to offer these metrics to their customers. The difference between a time series measure of availability and a cross section measure of availability is shown in the table below (please see www.e2eslasupport.com if you can not read the table. This memo is on our website). The time series approach measures the availability of each IP-VPN Site (it could also be a Frame/ATM port or pvc, or a Private Line circuit) for any given month. So for example, sites 1, 2 and sites 6-10 had 100% availability in January. Sites 3, 4 and 5 had 99.03% availability in January. Sites 3, 4 and 5 had a 7 hour outage, from 2pm-9pm on January 15th, which implies 99.03% availability. Jan Jan Jan Jan Sites 1/1-1/15 1/15 1/15-1/31 Site Avail. %Sites Site 1 100% 100% 100% 100% 10% Site 2 100% 100% 100% 100% 10% Site 3 100% 0% 100% 99.03% 10% Site 4 100% 0% 100% 99.03% 10% Site 5 100% 0% 100% 99.03% 10% Site 6 100% 100% 100% 100% 10% Site 7 100% 100% 100% 100% 10% Site 8 100% 100% 100% 100% 10% Site 9 100% 100% 100% 100% 10% Site 10 100% 100% 100% 100% 10% Total 100% 70% 100% 99.71% 100% Percent Time in 48.39% 0.97% 50.64% 100% Range The cross section approach measures availability of the network at various points in time. From January 1st to January 15th, there were no outages on the network. Therefore the network had 100% availability during those first 15 days of the month. On January 15th, from 2pm to 9pm, sites 3, 4 and 5 had 0% availability (these sites were affected by a seven hour outage). Therefore, from 2pm-9pm, on January 15th, the network availability was 70%. Average availability is sometimes used as the SLA metric for availability. The average availability is the same whether the measure of availability is Network Availability or Site Availability. The method used to calculate average availability today is by averaging the individual Site Availabilities. The average availability measures are a weighted average. With Network Availability the weights are the time spent at different ranges of availability, with Site Availability (used today) the weights are the percent of Sites with different levels of availability. The Average Availability, in this case, was 99.71% shown in the bottom right corner. Network Availability, Site Availability and Average Availability all have their own strengths and weaknesses. The weakness with Network Availability is that compensation is capped by the amount of time the network is below the target level of availability. So, if 50% of the network is down for a couple of hours then the most the customer can be credited is the percent of time the network was down. For a 2 hour outage this amounts to .28% (2 hours out of 720 total hours in the month) of the total network charges. Even if the entire network is down, the credit is capped by the percent time the network was down. So if 100% of the network is down for 2 hours the maximum compensation due the customer is .28% of the network charges. On the other hand, Site Availability provides compensation based on the percent of the sites that are down. So if 50% or 100% of the Sites were down for 2 hours Site Availability would compensate a customer up to 50% or 100% of the network charges, respectively. The weakness of Site Availability is that compensation is capped by the percent of sites that are below the target level of availability. For example, if there were a problem, in a given month, where a site had recurring problems that lasted much of the month, the customer's compensation would be capped to be a maximum of the charges on the problem site. For a large network, say a network with 100 sites, this would amount to a 1% of the total network charges are eligible for credit. If, on the other hand, Network Availability were the measure of availability, then the customer would be eligible for up to a maximum of 100% of the network charges, if the site caused the network to be below the target level for the entire month. In general, Site Availability is going to compensate better then Network Availability when outages are of relatively short duration and impact many sites all at the same time. Network Availability will provide more compensation to the customer in months when outages are sporadic, occurring at different points and time during month. Finally, Average Availability is an all or nothing deal. It provides either the best compensation or the worse compensation of the three metrics, depending on the outages. With Average Availability compensation is not limited by the amount of time the network is below the target level of availability nor is it limited by the percent of sites that are below a targeted level of availability. If the Average Availability target is missed the customer is eligible for compensation for all the network charges. The issue with Average Availability is that it won't provide any compensation at all if the target is met, even though there could have been outages on the network that required compensation under Network Availability and/or Site Availability. If the target for Average Availability is 99.99% then a network wide outage that last 4 minutes and 31 seconds would not be eligible for any compensation. Similarly an outage that lasts 72 hours at a single site, on a network with 1000 sites, would not be eligible for any compensation. In both cases, the 4 minute 31second network wide outage and the 72 outage on a single site, would meet a 99.99% average availability target. None of the availability measures protect the customer against all types of outages. For complete coverage against any type of outage you may consider combining Site Availability and Network Availability. For example, include both measures of availability in the Service Level Agreements. The measure that applies in any given month is the metric that provides the most compensation to the customer. Another way of getting the benefit of Site and Network Availability is to multiply the percent of the time of the month a particular outage lasted by the percent of total sites effected. The result would be the total percentage of the network that was affected by the outage: Percent time of the month * Percent of Circuits. Applying the resulting percentage to total network charges would amount to a refund of the customer's charges for the effected circuits, for the time the circuits were down. Of course an additional percent credit would have to be added to compensate the customer for the burden of the outage. This is a very brief summary of today's measures of availability. We have a detailed presentation, which you can view from our website. You can also find out more about our: SLA administration services (tracking, reporting, claim processing), consulting services, presentations, and other services. Please see www.e2eslasupport.com for more information. Network Availability and the variants of it are patent pending business methodologies of L. Swanzer and E2E SLA Support, LLC. Thank you, Larry Swanzer E2E SLA Support, LLC 908-806-4097 ------------------------------ From: hancock4@bbs.cpcn.com Subject: AT&T Licensed the Transistor For Free Date: 17 May 2005 07:15:49 -0700 From time to time critics of the old Bell System gripe that the company was "guaranted profits" by the regulators and as such, owed something back to the community. Aside from the fact that regulation actually limited profits, AT&T was indeed required to give things back. One of which was the rights to its invention of the transistor, which were available free of charge. (Per Ziff-Davis history). I had always wondered why AT&T never seemed to make any money from the invention of the transistor. I presume other Bell Labs patents were also available free; indeed, I never knew of AT&T making money from licensing its many inventions. It appears patents were more for freedom of use than profit. IBM adopted a similar policy in the 1950s. Both did so from anti-trust settlements. ------------------------------ Date: Tue, 17 May 2005 07:42:27 -0500 From: John Schmerold <john@katy.com> Subject: Vonage Improvement: No More Dial 1+ Recently ordered a new Vonage line. The new line does not require a "1" prefix. I was spending $50 per new line for a device that inserted the 1. This is Great news! [TELECOM Digest Editor's Note: Since there is no price differential on Vonage in most cases (I still have a 500 minute limited account but most users do not) the '1' is pointless and a waste of time. _Everything_ is ten digits; even locally, and the price is the same no matter what. However, some people do not know that Vonage can also be _seven digits_ with area code (where the box was installed, or 'home area') assumed. Like telco, if nothing is dialed after seven digits, then it sits there for a few seconds to time out, and deals with what it got. PAT] ------------------------------ Date: Tue, 17 May 2005 13:27:27 EDT From: Telecom dailyLead from USTA <usta@dailylead.com> Subject: Survey: Mobile Video Gets Lukewarm Support Telecom dailyLead from USTA May 17, 2005 http://www.dailylead.com/latestIssue.jsp?i=21641&l=2017006 TODAY'S HEADLINES NEWS OF THE DAY * Survey: Mobile video gets lukewarm support BUSINESS & INDUSTRY WATCH * Yell buys U.S. directories publisher * Some MCI shareholders withhold votes * VoIP companies find acceptance, rejection overseas * Alcatel dumps stake in mobile phone venture USTA SPOTLIGHT * Hear Telecom Crash Course author Steven Shepard at Telecom Engineering Conference @ SUPERCOMM EMERGING TECHNOLOGIES * Scripps to offer broadband channels REGULATORY & LEGISLATIVE * SBC, Verizon take TV fight to state legislatures * Los Angeles OKs stricter customer service rules for cable * Vivendi sues Deutsche Telekom over Polish deal Follow the link below to read quick summaries of these stories and others. http://www.dailylead.com/latestIssue.jsp?i=21641&l=2017006 ------------------------------ From: hancock4@bbs.cpcn.com Subject: Foreign Exchange (FX) Lines Still in Use? Date: 17 May 2005 13:47:38 -0700 In another thread Pat mentioned FX lines. As mentioned, these were used to save on long distance changes -- customers would make a local call to a distant business and the business could call its customers for the cost of a local call. This service was not cheap. At a resort I visited that had FX lines to a city 75 miles away, the switchboard had special heavy cord pairs. Extensions authorized for FX had a second jack underneath in which the heavy cord was inserted. I heard FX lines used higher voltage thus the heavy cords. I don't know what kind of special wiring, if any, was in the telephone sets. I would guess WATS and long distance packages has made most FX lines obsolete. There was toll free before 800 numbers but it was manual and a local number added a comfort factor. Obviously today a business's 800 number is more convenient for anyone. Further, businesses have outward long distance packages so the cost of paying for an FX trunk (that only worked in a specific city) couldn't be justified. But there is another type of "FX" service that seems not to have gone away even though the need has. Philadelphia has a local city zone and message units for more distant suburban calls. Many suburban businesses had a city phone number for the same reason companies had FX lines. Even some suburban homeowners who made a lot of city calls had a second line with a city number. AFAIK, many suburban businesses still maintain their existing city phone numbers even though today the need isn't as much. (The following is the economic analyis for those interested). The message unit charge has been 7c for at least the last 40 years. Now 7c 40 years ago was like 50c today and say a monthly usage of 100 units comes to some serious money in today's terms (equivalent of $50) while today it's $7 which isn't a big deal. Further, Verizon has increased local calling area sizes and reduced zone charges. My guess is today it probably costs a business far more to maintain the city line than whatever they save in message units, and customers don't give making a suburban call a second thought today. In looking through the yellow pages I noticed many businesses had multiple numbers. However, for some time Verizon offers remote forwarding -- that is you get a local number but it really isn't a line -- it just forwards calls to your actual number. That's more to imply a business has a local presence than to save customers toll charges. I guess that businesses maintaining a distant line never gave it any thought and just pay for it month after month. A few businesses had Enterprise service they kept as well until that was finally discontinued a few years ago (at least such numbers are gone from the city phone books). My own employer used tie lines in distant places to save on toll charges 25 years ago. But now they have more modern bulk purchase toll service arrangements, all done automatically. We once dialed various codes, but now just dial 9+ for all outside calls. ------------------------------ From: Brad Houser <bradDOThouser@intel.com> Subject: Re: Very Early Modems Date: Tue, 17 May 2005 12:46:39 -0700 Organization: Intel Corporation Reply-To: bradDOThouser@intel.com On 16 May 2005 13:14:42 -0700, hancock4@bbs.cpcn.com wrote: > In the IBM history series by Pugh et al, they said IBM converted > punched cards to paper tape for transmission in the 1940s. My guess > is that that particular transmission used telegraph TTY lines (not > voice) of either AT&T or Western Union. Recall that AT&T maintained > telegraph long distance lines as part of carrier long distance > circuits. Because of the low bandwidth, a telegraph channel could be > carried on the low end of a carrier channel. Accordingly, no > modulation was required and thus no modem needed. > It was also said IBM limited development in this area to avoid > annoying AT&T who was IBM's best customer. > However, in the 1950s, IBM developed card-to-card directly without > paper tape and "over AT&T lines". Modems were developed to take good > advtg of the available bandwidth (about 1200 baud). Undoubtedly the > equipment and implementation was developed in close cooperation with > AT&T. > I was wondering if the modems in that application were supplied by IBM > (who appears to have developed the technology) or by AT&T. My > understanding that AT&T's "Dataset" modem-telephones didn't come out > until the 1960s. > Comments by anyone familiar with pre-1960 data communications would be > greatly appreciated. Here is a picture of a 1958 AT&T modem (not sure if this is the first commercial modem, the Bell 103. If so it was 300 baud): http://www.att.com/history/milestone_1958.html Brad H ------------------------------ From: hancock4@bbs.cpcn.com Subject: Re: Very Early Modems Date: 17 May 2005 07:10:57 -0700 Organization: http://groups.google.com hancock4@bbs.cpcn.com wrote: > I was wondering if the modems in that application were supplied by IBM > (who appears to have developed the technology) or by AT&T. My > understanding that AT&T's "Dataset" modem-telephones didn't come out > until the 1960s. I found some additional information on the above: It appears the modems for the 1950s units were developed and implemented by IBM, not AT&T. They used four signals to take advantage of the 4 Khz range of a voice grade telephone line giving an effective transmission rate of 1200 baud. The information was sent from punched card to punched card. This was an advantage over the prior method of converting it to paper tape and back again for transmission. The data was converted from Hollerith code to a special 8 bit code in which there was always four bits to represent a character. Considerable error checking and control protocols were included -- these were not present in the paper tape method -- and this was considered a major feature of the system. The passage said that AT&T strictly controlled attachments to their lines; the IBM system was used mostly on private lines or leased lines. As we recall, many large organizations, especially railroads, maintained their own privately built and maintained telephone networks and such users could of course attach anything they wanted. Railroads could use this IBM system to send in freight car movements punched at remote locations to a central site. But I wonder if AT&T allowed private attachments to leased private lines it supplied. I wonder if the rules were different for such lines as opposed to the switched network. I also wonder if the independent telephone companies were as strict as AT&T regarding attachments. It was hard to tell from the passage just how many units were out there actually in regular revenue service as opposed to specialty and demonstration units. My guess is that there weren't very many in the 1950s; it was probably cheaper and adequate in those days to mail source documents to central HQ to be keypunched there rather than keypunch them remotely and transmit them. Reproducing cards is a slow process. The early card-to-card systems used modified keypunch machines. Now, around 1960 IBM began to offer a number of "tele-processing" products and I suspect at that point volume did indeed grow. I don't know what AT&T offered as modems in 1960 before their "Dataset" was introduced. Around 1964 IBM introduced commnication systems that used its new Selectric typewriter as a term. My own bank began to use them around 1965. Relatively early on IBM introduced an audio response unit from Touch Tone queries. I remember another bank having a side Touch Tone keypad next to a rotary phone for such inquiries around 1967. Supposedly one customer for this system was AT&T itself to provide automated route-rate information for operators. At the time I thought such systems were a smart idea; of course today seeing how maddening it is to use them I feel a little differently. ------------------------------ From: jmeissen@aracnet.com Subject: Re: FAQ: How Real ID Will Affect You Date: 17 May 2005 09:01:42 GMT Organization: http://extra.newsguy.com In article <telecom24.216.7@telecom-digest.org>, <hancock4@bbs.cpcn.com> wrote: > DevilsPGD wrote: >> Sure -- I can't speak for anyone else, but I'm willing to deal with the >> resulting fallout if I get in a fight in a bar or with my landlord or >> whatever. > I don't know your personal circumstances, but I can't help but wonder > if you don't realize the long term import of the situation. I highly recommend reading the opinions of Bruce Schneier, of Counterpane Internet Security: http://www.schneier.com/crypto-gram-0505.html He has some interesting comments in his most recent newsletter, and in earlier essays and his blog. john- ------------------------------ From: Joseph <JoeOfSeattle@yahoo.com> Subject: Re: Traveller Seeks Phone Advice Date: Tue, 17 May 2005 05:18:52 -0700 Reply-To: JoeOfSeattle@yahoo.com On Mon, 16 May 2005 14:57:18 -0700, Mark Crispin <MRC@CAC.Washington.EDU> wrote: > On Sun, 16 May 2005, John Levine wrote: >> In the US, you have to get the phone from whoever sells the prepaid >> service. You'd think you could just buy a SIM if you have a GSM >> phone, but you can't. > Both T-Mobile and Cingular say, at least at the local shops where I > checked, that they'll sell a prepay SIM card to someone who has a > suitable phone. True, but you'll also get a better deal on card price and included number of minutes if you look for sales on ebay. ------------------------------ From: Dean M. <cjmebox-telecomdigest@yahoo.com> Subject: Re: Will 911 Difficulties Derail VoIP? Organization: SBC http://yahoo.sbc.com Date: Tue, 17 May 2005 15:42:52 GMT AES <siegman@stanford.edu> wrote in message news:telecom24.217.6@telecom-digest.org: > In article <telecom24.216.13@telecom-digest.org>, Dean M. > <cjmebox-telecomdigest@yahoo.com> wrote: >> I see now that your proposal is: since our communications are being >> decoupled from the copper wire anyway (or at the very least the low >> band part of it), we should not remove (on this point, see another >> posting about Verizon's FiOS offering and copper) or allow it to >> decay, but use it as dedicated conduit for "utility" services like >> 911, alarms etc. Anything which is first location dependent and then >> customer dependent as opposed to the other way around. > That's a fair enough summary. [snip] > Note that minimal basic telephone service can currently be obtained > for something in the range of $10/month, give or take (although I > don't know how much subsidy is in that number). Suppose the telco > didn't have to provide the telephone service, handle the switching of > calls, do the billing, all that stuff -- just provide and maintain a > bare wire. Wouldn't take much in the way of services to support > that monthly cost. That's what SBC charges for bare minimal phone service where I am. But then they tack on all kinds of fees and taxes and it comes to almost twice that! Unfortunately I don't have the bill in front of me so I can't recall how much of those fees is "legitimate" (i.e. government forces them to charge it) and how much is what SBC will call fees but they're not government mandated. Anyway, the point is I cannot shed any light on the question of copper loop maintenance/greenfield expansion costs. Anyone else? Dean ------------------------------ From: bonomi@host122.r-bonomi.com (Robert Bonomi) Subject: Re: Vonage Changes 911 to Opt-Out Date: Tue, 17 May 2005 18:28:58 -0000 Organization: Widgets, Inc. In article <telecom24.215.13@telecom-digest.org>, Robert Bonomi <bonomi@host122.r-bonomi.com> wrote: [[.. munch ..]] > The "easy" solution is a two-part one. > Part 1: The VoIP 'head end' tracks the 'most recently used' IP > address for each customer. _EVERY_TIME_ the customer IP > address changes, the phone goes *out*of*service* with a > notice that the customer must update their "calling > location". > Possibly with an added hook that if the phone has been 'off > line' for some non-trivial period, that when it goes back > 'on line', the customer is queried (in an automated > fashion) to confirm that they are still at "thus and such > location"; where "thus and such" is the previously > specified location for the phone. > Part 2: The VoIP 'head end' maps the various 'calling locations' to the > appropriate PSAP, upon need. > Add an option for the customer to intentionally _not_ specify his > location, but which also totally disables 911 calling. This protects > his 'privacy' at the expense of his safety, but it is the customer's > decision. > The last part of the puzzle is ensuring that the customer is aware > that the "location information" provided is used for "emergency calls" > and that deliberately providing FALSE information can (and probably > _will_) lead to criminal prosecution if emergency services are > directed to an incorrect location as a result of said false > information. There is already existing enforcement mechanism for this > -- "filing a false police report", etc. [[.. munch ..]] > Now, silly as it sounds, something that "works right" 98% of the time, > but "invisibly" does the _wrong_ thing the other 2% of the time is > *worse* that something that 'almost never' gets it right. > An essential element of a 911 'locator' system it that it either gives > a 'right answer', or it gives *NO* answer. "Wrong answers" are simply > not acceptable -- wrong answers (a) delay the response to the location > where it is needed, *and* (b) tie up resources that may be needed to > respond to a 'real' emergency. > [TELECOM Digest Editor's Note: Well ... regards your first point, of > a 'tunnel' to some remote place, do you remember when 'Foreign Exchange > Service' (or FX) was quite common? It still exists today. Either as actual hard-wire to the remote CO (with a *BIG* one-time install charge, plus a moderate monthly) or, more commonly, as a 'virtualized' service. > So, one day in my office, a masked man breaks in, and waving his > gun around, he announces, "I am going to rob all the cashiers and > rape all the men". I say, 'oh no you are not!' and rush to my phone > to call the police. But in my haste I grab up the FX tie-line phone > and dial '911' -- (or as Bonomi would say, ooops) ... -- and wind > up lodging my complaint with the politce in Kalamazoo and Timbuck also. Funny thing about FX lines, the telco _does_ know where the end of that line is. In your scenario, if you called 911 on that line, while the call _might_ go to the PSAP for locale where the switch is, the *location* *information* given to the police would be accurate. The accurate POTS parallel to the VoIP 'location' problems is the situation where there the telephone company service terminates at a PBX, and there are 'extensions' *BEHIND* the PBX to 'remote' locations. The *telco* _does_not_ _know_ anything about what goes on behind the PBX, and can only report where =their= service terminates. Which leads to the telco providing "wrong answers" to the 911 center. Cell phone systems have the same problem. The point at which a cell-phone call is connected to the PSTN is _not_ necessarily anywhere "close" to the tower which is handling the call. AND, that tower may be in a different 'jurisdiction' than the one where the person _placing_ the call is. A review of actual 911 history will show that *both* of the above scenarios were real problems in the early days of 'enhanced 911'. In the first case, governmental regulations were issued that require PBX owners to keep the PSAP 'location database' updated with the *actual*location* of all extensions that are behind that PBX. The cell-phone problem was considerably thornier -- and went through a number of steps: 1) cell phone links were *blocked* from calling 911 because "wrong data" was being displayed. 2) 911 calling was re-enabled when it became possible to return "no data" for those calls, instead of "wrong data" as to the location. 3) enhanced technology was mandated/deployed _on_the_cell_ network (*NOT* a part of the PSTN) that allowed fairly precise _caller_ location determination 'on the fly'. 4) Where that technology was deployed, "good" (as in valid/accurate) 'location' data was then passed to the PSAP, instead of the prior "no data". Dealing with VoIP involves much 'harder' problems than either of the above. To have the phone itself figure out "where it is" it has to have straight-line inputs from a minimum of two sources that it (a) knows where are, *and* (b) can take directional bearings on, OR a minimum of three sources that it can measure signal timing from. AND it has to be able to reliably derive that information at _any_ location where the phone might be used. Using GPS is not a viable option -- 'indoor' reception is too poor. And the 300 ft accuracy is problematic. That last can be remedied by using DGPS, but that makes for a more expensive receiver. And doesn't do anything for the fundamental reception problems. The only solution for _that_ problem is to replace the transmitters with more powerful ones. Which is *awfully* expensive. LORAN-C might be a possibility, it carries indoors fairly well. BUT, it operates at 100kHz, which requires a non-trivial antenna for decent reception. *AND* it is only accurate to around 1/4 of a mile. "within several blocks" is simply not good enough for emergency-service dispatch. One is left with the possibility of direction-finding on local commercial stations. This could possibly be made to work, but requires access to a fairly massive database of *precise* transmitter locations. The equipment required to get a precision bearing on a transmitter isn't cheap, either. (If you're 10 miles from the transmitter, a _one_degree_ uncertainty in direction makes for +/- nearly a thousand feet in your location.) "Technology" is not the solution for this, "Policy" is. The two-part solution described previously does get the job done. Administratively, not via technology. All the burden (what burden there is) is on the VoIP provider and the actual 'owner' of the phone. And it probably takes 30 days, or _less_, to get it into 'production' status at any/every major VoIP provider. > If a _real man_ does not know where his broadband service is out of, > then he has no business calling the police to start with, does he? PAT] I stand "corrected". PAT _has_ come up with the ultimate solution. With his proposed 'local ISP'-based handling of emergency calls, *NOBODY* but the person who set up the VoIP service -- and knows where it connects through -- is allowed to use the phone in an emergency. "So what" if that person is unconscious on the floor from a heart attack, and the VoIP phone is the only one available, and someone who _doesn't_know_ that it is an IP phone, or where it connects through, cannot call for help. No need to even consider the situation of the person who takes "their" phone to a friends place, because they may have to make some lengthy toll calls, and simply _don't_know_ where _that_ broadband service is out of. After all, that could _never_ happen, could it? [TELECOM Digest Editor's Note: No, of course it _could_ happen, but what are the odds? Figure the 'odds' based on these things: the VOIP phone is on the road somewhere, not in its usual place. The subscriber has an incident and needs help. Not only does _he_ not know where he is at (or is not in a position to speak to the police) and the _phone_ does not know where it is at. There is no landline available, and/or the person in trouble not only cannot get to the (landline) phone, or whatever. My personal reaction is _all those factors taken in combin- ation_ are so negligible as to not matter at all. As soon as any one of those conditions does not exist, the problem is dealt with. We do not live in the town of 'Perfect' as the commercial for Walgreens states. And you know what, Robert? Even if magically, every one of those rare obstacles were overcome tonight, magically, _YOU_ would come up with still more obstacles, wouldn't you? And after all, why not? You swear on a stack of tech reference manuals that _nothing_ can be done to tame the 'wild west' lifestyle of the internet. I have never yet seen you ever admit to any possible cure for the nastiness on the internet. It just has to be the way it is, because Robert has all the (non) answers. Why shouldn't any problems with E-911 and VOIP turn out the same way. You don't really want to see any answers to any of those problems, do you? And rather than do _something_ and bring some small amount of relief to the vast majority of users, there will still be some iota-percentage we are unable to help, given our understandings. So better to do nothing at all, right Robert? I thought your thinking was absolutely ludicrous where spam/scam/viri was concerned, but people have seen nothing at all until you explain the 'hassles' (as you see them) with 911 and VOIP. PAT] ------------------------------ Date: Tue, 17 May 2005 17:05:24 EDT From: Carl Moore <cmoore@ARL.ARMY.MIL> Subject: Popular Vote (was Re: FINAL Words on Sodomy Insane) Danny Burstein <dannyb@panix.com> wrote in March 2003 about the 2002 World Series (in commenting about the U.S. Electoral College, noting that the 2000 presidential winner didn't get the most popular votes): > Giants: total runs: 44 > Angels: total runs: 41 > Of course, the number that COUNTS is the number of individual games that > were won. And there, the score was: > Giants: 3 > Angels: 4 I don't mean to go on a sports tangent, but even more dramatic was the 1960 World Series. The Pittsburgh Pirates defeated the NY Yankees 4 games to 3, but scored only 27 runs compared to NY Yankees' 55 runs! ------------------------------ 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, Yahoo Groups, 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-copyrighted. You may reprint articles in some other media on an occasional basis, but please attribute my work and that of the original author. Contact information: Patrick Townson/TELECOM Digest Post Office Box 50 Independence, KS 67301 Phone: 620-402-0134 Fax 1: 775-255-9970 Fax 2: 530-309-7234 Fax 3: 208-692-5145 Email: editor@telecom-digest.org Subscribe: telecom-subscribe@telecom-digest.org Unsubscribe:telecom-unsubscribe@telecom-digest.org This Digest is the oldest continuing e-journal about telecomm- unications on the Internet, having been founded in August, 1981 and published continuously since then. Our archives are available for your review/research. We believe we are the oldest e-zine/mailing list on the internet in any category! URL information: http://telecom-digest.org Anonymous FTP: mirror.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 * * Judith Oppenheimer, President of ICB Inc. and purveyor of accurate * * 800 & Dot Com News, Intelligence, Analysis, and Consulting. * * http://ICBTollFree.com, http://1800TheExpert.com * * Views expressed herein should not be construed as representing * * views of Judith Oppenheimer or ICB Inc. * ************************************************************************* ICB Toll Free News. Contact information is not sold, rented or leased. One click a day feeds a person a meal. Go to http://www.thehungersite.com Copyright 2004 ICB, Inc. and TELECOM Digest. All rights reserved. Our attorney is Bill Levant, of Blue Bell, PA. ************************ DIRECTORY ASSISTANCE JUST 65 CENTS ONE OR TWO INQUIRIES CHARGED TO YOUR CREDIT CARD! REAL TIME, UP TO DATE! SPONSORED BY TELECOM DIGEST AND EASY411.COM SIGN UP AT http://www.easy411.com/telecomdigest ! ************************ Visit http://www.mstm.okstate.edu and take the next step in your career with a Master of Science in Telecommunications Management (MSTM) degree from Oklahoma State University (OSU). This 35 credit-hour interdisciplinary program is designed to give you the skills necessary to manage telecommunications networks, including data, video, and voice networks. The MSTM degree draws on the expertise of the OSU's College of Business Administration; the College of Arts and Sciences; and the College of Engineering, Architecture and Technology. The program has state-of-the-art lab facilities on the Stillwater and Tulsa campus offering hands-on learning to enhance the program curriculum. Classes are available in Stillwater, Tulsa, or through distance learning. Please contact Jay Boyington for additional information at 405-744-9000, mstm-osu@okstate.edu, or visit the MSTM web site at http://www.mstm.okstate.edu ************************ --------------------------------------------------------------- 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 fifty 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 End of TELECOM Digest V24 #218 ****************************** | |