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
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
******************************
| |