The Telecom Digest for December 25, 2010
Volume 29 : Issue 348 : "text" Format
Messages in this Issue:
====== 28 years of TELECOM Digest -- Founded August 21, 1981 ======
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, and other stuff of interest.
Date: Fri, 24 Dec 2010 15:31:52 +1100
From: David Clayton <dcstar@myrealbox.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Please don't hit me with your modem
Message-ID: <pan.2010.12.24.04.31.51.711056@myrealbox.com>
http://www.dilbert.com/fast/2010-12-23/
C'mon, how many of you does this also apply to? :-)
--
Regards, David.
David Clayton
Melbourne, Victoria, Australia.
Knowledge is a measure of how many answers you have, intelligence is a
measure of how many questions you have.
Date: Fri, 24 Dec 2010 16:24:46 +0000 (UTC)
From: Horn <horn+NOSPAN@panix.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Please don't hit me with your modem
Message-ID: <if2hge$q3m$1@reader1.panix.com>
David Clayton <dcstar@myrealbox.com> wrote:
> http://www.dilbert.com/fast/2010-12-23/
> C'mon, how many of you does this also apply to?
Ok, I'm in.
Ackshually The modem in my primary box is connected to the phone line and
records the caller ID of all incoming calls, Um, via a utility called
Phonetrayfree.
--
Remove +STRING to reply by email
Date: Fri, 24 Dec 2010 21:09:59 -0700
From: Reed <reedh@rmi.net>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Please don't hit me with your modem
Message-ID: <i9OdncpsLe0j84jQnZ2dnUVZ_o6dnZ2d@earthlink.com>
On 12/23/10 9:31 PM, David Clayton wrote:
> http://www.dilbert.com/fast/2010-12-23/
>
> C'mon, how many of you does this also apply to? :-)
>
I saw that strip in the paper and about fell out of my chair...will
have it enlarged and framed...
Repaired or sold modems from 1966 to 1998
Rixon, Lenkurt, Codex, UDS, Milgo, Racal
***** Moderator's Note *****
The Sword Of Satire [tm] cuts both ways: I still have a modem, and I
still remember a couple of Hayes commands, and I have been in the
business for more than thirty years. I'm going to put the strip up
over my desk to remind me that when it comes to technology, the rule
is "Never Look Back".
Bill Horne
Moderator
Date: Fri, 24 Dec 2010 03:55:42 -0800
From: Sam Spade <sam@coldmail.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Number portability and the demise of line number pools in bankruptcy
Message-ID: <-eKdnbgxD7OiF4nQnZ2dnUVZ_qWdnZ2d@giganews.com>
John Levine wrote:
>
> So anyway, if anyone was asking, no, I would not recommend Vonage for
> your telephone service.
>
> R's,
> John
>
I've been a Vonage customer from their very beginning. I am still with
them today. I recommend them highly but not as anyone's only telephone
service. Also, I would not port a valued number to them but I reached
that conclusion early on.
I call England all the time for zero incremental cents per minute. ;-)
I also like having my primary number in Washington, DC, although I am in
California.
Date: 24 Dec 2010 18:08:23 -0000
From: John Levine <johnl@iecc.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Number portability and the demise of line number pools in bankruptcy
Message-ID: <20101224180823.64147.qmail@joyce.lan>
>I call England all the time for zero incremental cents per minute. ;-)
I ported my Vonage number to Primus Lingo, and also call Europe all
the time for zero incremental cents per minute. They're just like
Vonage, only cheaper and with actual live people who answer the phone.
>I also like having my primary number in Washington, DC, although I am in
>California.
Well, sure, any VoIP provider offers that. I have numbers in California,
Montreal, and England through a service in Belgium.
R's,
John
Date: Fri, 24 Dec 2010 13:42:29 -0800
From: Sam Spade <sam@coldmail.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Number portability and the demise of line number pools in bankruptcy
Message-ID: <HpidnTSN7-JbjojQnZ2dnUVZ_r6dnZ2d@giganews.com>
John Levine wrote:
>
> I ported my Vonage number to Primus Lingo, and also call Europe all
> the time for zero incremental cents per minute. They're just like
> R's,
> John
>
I had my first issue for at least two years the other day. I sent them
a trouble email and they responded within two hours. They reset it on
their end and recommended what I do on my end. It was all fixed.
Then, about two hours after that a real live person called me to ask if
it was working to my satisfaction.
I would love to have that kind of service from my wireline (Pac
Bell/AT&T) and my cable company.
Date: Fri, 24 Dec 2010 02:58:30 -0600
From: bonomi@host122.r-bonomi.com (Robert Bonomi)
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: ZIP Codes and barcodes
Message-ID: <e_ednRB-lugr_YnQnZ2dnUVZ_vCdnZ2d@posted.nuvoxcommunications>
In article <if0kmc$90f$1@news.albasani.net>,
Adam H. Kerman <ahk@chinet.com> wrote:
>
>If a firm has a lot of incoming mail, it might get one or more ZIP+4 codes,
>but this has become less necessary with encoding to delivery point. Encoding
>to a firm would be the finest encoding of all.
I know firms that have their own 5-digit zip. <grin>
Aside: there's the classical mail-routing story about mail that got
-delivered- (routinely, mind you) with nothing more than 3 five-digit
numbers for the address.
Mail going to someone in prison, first number was the prisoner ID,
second was the P.O.box where all prisoner mail was sent, and third was
the zip-code. :)
>You're not correct that each ZIP+4 is valid, for grosser encodings aren't
>used where finer encodings are available. If you gave a correspondent the
>ZIP+4 of the blockface but a different ZIP+4 is used specific to a small
>group of apartments, the system should print a barcode of the finest
>sortation level, otherwise sequencing is more difficult and they try to
>avoid having the carrier do any at all.
I know the 'groser', as you put it, ZIP+4 encodings *work*. Mail addressed
with one of those codes is delivered, and w/o any nag notes from the PO
to correct it. Unlike the situation if you use an incorrect code.
Date: Fri, 24 Dec 2010 20:46:47 +0000 (UTC)
From: "Adam H. Kerman" <ahk@chinet.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: ZIP Codes and barcodes
Message-ID: <if30rm$iu1$1@news.albasani.net>
Robert Bonomi <bonomi@host122.r-bonomi.com> wrote:
>Adam H. Kerman <ahk@chinet.com> wrote:
>>You're not correct that each ZIP+4 is valid, for grosser encodings aren't
>>used where finer encodings are available. If you gave a correspondent the
>>ZIP+4 of the blockface but a different ZIP+4 is used specific to a small
>>group of apartments, the system should print a barcode of the finest
>>sortation level, otherwise sequencing is more difficult and they try to
>>avoid having the carrier do any at all.
>I know the 'groser', as you put it, ZIP+4 encodings *work*. Mail addressed
>with one of those codes is delivered, and w/o any nag notes from the PO
>to correct it.
That's the advantage of having a human in the process to deliver the mail.
If the automated process were to route the letter strictly by ZIP+4 Code,
then any ZIP+4 Code composing the carrier route should get the letter to
the correct carrier, but that's not what happens in practice.
Hypothetical 50 unit apartment building, one street address, plus
management office and five small businesses: convenience grocery story,
nail salon, hair dresser, barber, and dry cleaning drop-off counter. There
is a large mail room serving the residents with one box per apartment.
To simplify the hypothetical, box numbers correspond with apartment numbers,
which isn't necessarily the case. So, correspondents should use an apartment
number with the street address. As the management office and each of the
small businesses would be open during typical hours the mailman would stop
by the building, they don't have boxes in the mail room and the carrier
enters their stores or office to deliver the mail.
The correspondent knows the street address and the correct name of the
addressee. The secondary address element is missing (apartment number).
The mail gets batched with other mail for the building with missing
address elements, with a Delivery Point ZIP Code, but doesn't get encoded
with its true delivery point and doesn't get sequenced. Now, a carrier
reasonably familiar with the building should be able to figure out which
apartment that addressee lives in, but a substitute carrier won't and
will Nixie it. Sometimes building management provides the carrier with
an alphabetized list of current residents that it keeps up to date,
but that cannot be counted on.
If the post office knows about it, every delivery point is encoded in
the database, every single one, so every secondary address element for
56 different delivery points should be encoded. There may be additional
ones as there is no consistency in how secondary address elements are
encoded for stores and offices. Also, there may be a firm record for the
management office if it gets enough inbound mail. The building's name,
if known, should be encoded in the database as a firm record against the
default ZIP+4 for the building's street address. If the company name in
the address block can be matched to a firm record, then that letter can
be encoded to the delivery point despite missing the secondary address
element. It's not reliable due to variations in the company name.
Quite frankly, the system ignores ZIP+4 codes and barcodes supplied by
the sender under many circumstances. The system routes to barcodes on
presorted mail that correctly encode a delivery point, only, and ignores
them on single-piece mail unless the correct Facing Identification Mark
barcode (FIM) is used on the envelope, which is in the upper right-hand
corner to the left of the postage. The delivery point is determined by
parsing the entire address block. If ZIP Code doesn't match city-state,
it's ignored. If ZIP+4 doesn't match the street address plus secondary
address element, it's ignored. If the address block barcode doesn't
encode the actual delivery point, it's ignored and a corrected barcode is
sprayed in the lower right-hand corner (sometimes with the carrier route
and delivery point ZIP Code added in human readable fashion). If a barcode
in the lower right-hand corner already exists that requires correction,
a label with the corrected barcode is applied. If the address block
cannot be parsed to determine the delivery point, it's image is sent to
remote encoding for a human to parse, or if that doesn't work, to the
delivery post office anyway to attempt to figure out which carrier route
it belongs to.
>_Unlike_ the situation if you use an incorrect code.
In the olden days, distribution clerks were ordered to route mailpieces
in which the city-state and ZIP Code didn't match to the post office
of the ZIP Code, but the automated database matching attempts to look
up the delivery point assuming the city-state is correct.
Date: 24 Dec 2010 18:03:56 -0000
From: John Levine <johnl@iecc.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Number portability and the demise of line number pools in bankruptcy
Message-ID: <20101224180356.63015.qmail@joyce.lan>
>The RFC John Levine came up with said QoR is a possible scheme but didn't
>state where it's implemented, so I'm really curious how they'd handle
>my hypothetical.
RFC 3482 has a table that describes the state of portability in many
countries as of 2003. Nobody's standardized on QoR but there are a
few places where it's optional, and a lot of countries used Onward
Routing (OR) which is basically call forwarding.
As to what would happen if the original network died in a QoR or OR
scenario, it would be a problem. Realistically, I expect that the
regulators would arrange for another carrier to take it over.
R's,
John
Date: Fri, 24 Dec 2010 11:47:46 -0500
From: Fred Goldstein <fgoldstein.SeeSigSpambait@wn2.wn.net>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Number portability and the demise of line number pools in bankruptcy
Message-ID: <20101224164917.C3128342D5@mailout.easydns.com>
On Thu, 23 Dec 2010 Robert Bonomi wrote,
>In article <ietvtc$ces$1@news.albasani.net>,
>Adam H. Kerman <ahk@chinet.com> wrote:
> >John Levine <johnl@iecc.com> wrote:
> >
> >John, please correctly attribute quotes of my remarks to me. If I was sloppy
> >in phrasing my question, then the error is on me and shouldn't be assumed
> >to be on anyone else.
> >
> >>>What happens to the ported numbers? Is routing to the pool
> simply shut down?
> >>>I assume that there is no obligation by the incumbent telephone company to
> >>>switch those virtual lines.
> >
> >>You seem to be confusing porting with call forwarding.
> >
> >I was not.
> >
> >I assumed that a call would be routed to the default network and, if
> >the number was ported, the database of ported numbers would be consulted for
> >routing instructions.
>
>Assumption is incorrect.
>
>Originating switch does a database dip to find appropriate destination switch,
>and routes directly to that destination switch.
>
>This is desirable/necessary because the 'native' switch, and 'ported number
>destination switch' may require -different- inter-carrier routing to get
>to the destination.
Both wrong.
The originating switch does not have to do a query of a local
number. If the call is to an 800 number, then the originating switch
or the first tandem switch does the query, which identifies which
carrier (the 4-digit CIC) gets the call. What the carrier does wtih
an 800-service call is up to that carrier. In the very specific case
of intraLATA 800 calls, the dip may return pseudo-CIC 0110, and a
10-digit local number, in which case the call is handed off to that
number. This allows LECs to issue intraLATA 800 numbers. But it's a
special case.
For a local call, the rule is different. The dip may be made at
any switch along the path, but must by made by the time the call
reaches the "N-1" switch, which is a switch that has a direct trunk
to the destination phone number. Typically this is the access tandem
in the destination LATA, or, if the LATA has local tandems, a local tandem.
The dip need only be made if a given NPA-NXX code is
"portable". There are still some non-portable codes, primary those
used for paging (which is not portable), but some rural carriers
still have non-portable codes. This is pretty common in the Alaskan
bush, for instance, and applies to a handful of codes in the lower
48. But the preponderance of calls are to portable codes. In such
cases, the phone number is really just a name, and the LNP database
is like the DNS, translating it to a destination address (the
location routing number, LRN).
The point is that the call is never, ever supposed to be sent to the
ported-from network. So if somebody in Iowa calls me here in
Massachusetts, their LD carrier may but need not dip the call. They
could hand off the call to the local tandem, which dips the call, and
the tandem then sends it to the end office that my number is actually
served by, regardless of which carrier "owns" the prefix (i.e., the
A-block record assignee).
If a carrier has direct end office trunks (DEOTs) to another end
office (which is common), then it cannot send the call over the DEOT
until it has dipped the call, because it doesn't know which DEOT to
use, or if it should send the call to the tandem, otherwise. Again,
the principle is that phone numbers are names, not addresses. A very
small carrier that only has tandem trunks need not do any dipping,
since the tandem can do so.
The dip returns an LRN. Each carrier gets only one LRN per
LATA. There may be multiple tandems per LATA.
>...
> >John kindly explained that we use an All Call Query scheme, in which case
> >the ported number database is queried to learn if the number is indeed
> >ported, instead of a Query on Release scheme, in which case the ported
> >number database is queried only if the number was ported out of the
> >default network's pool. In ACQ, I can see how routing instructions to
> >numbers ported out of a pool that no longer exists could survive the
> >demise of the pool.
>
>One can either query before every call, or attempt a call set-up to
>the 'native' network, and if that set-up fails (for pretty much any
>reason other than 'circuit in use'), do the (third-party maintained)
>master database dip, and re-try. Note: if the 'native' network has
>gone defunct, the above logic will work because the required info is
>still in the 3rd-party maintained database.
The US uses all call query, if it's a portable prefix. One never
attempts to send a call to the native network. *In practice*, this
does occur -- some switches are misprogrammed and cause routing rule
violations. ILEC switches generally will try to process these
calls anyway and pass them along, but will send the miscreant carrier
a (nominal) bill for their efforts, which basically serves as a
notice to fix the routing.
If the original carrier goes defunct, its prefix codes tend to remain
alive; I am personally aware of some such zombie codes that are in
the current LERG. When the carrier tanks, its numbers are ported
out. So no calls should go to the "default" carrier's LRN, but they
do go to their ported-to carriers. I suppose that another carrier
could ask to take over the A-record and thus ownership of returned
numbers, but this would be most likely to occur in an area code that
was running out of prefix codes.
--
Fred Goldstein k1io fgoldstein "at" ionary.com
ionary Consulting http://www.ionary.com/
+1 617 795 2701
Date: Fri, 24 Dec 2010 17:43:57 -0500 (EST)
From: Dan Lanciani <ddl@danlan.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: Number portability and the demise of line number pools in bankruptcy
Message-ID: <201012242243.RAA11942@ss10.danlan.com>
How does portability interact with caller name delivery? My understanding
is that typically the terminating office does the name lookup, i.e., the
name is not usually sent along with the call setup information. So is a
dip to determine who owns the number required before the dip to get the
name? Or is there a single name database that takes care of this? I
noticed that when my uncle ported from Verizon to the cable company I
stopped getting his name on caller ID. Now I just get "Massachusetts."
Dan Lanciani
ddl@danlan.*com
Date: Fri, 24 Dec 2010 19:42:42 -0800 (PST)
From: Lisa or Jeff <hancock4@bbs.cpcn.com>
To: telecomdigestmoderator.remove-this@and-this-too.telecom-digest.org.
Subject: Re: ZIP Codes and barcodes (was: Telstra loses directory copyright appeal)
Message-ID: <b4b7bf46-b2ce-49b5-87e4-6e7475277d63@l32g2000yqc.googlegroups.com>
On Dec 23, 3:03 am, "Adam H. Kerman" <a...@chinet.com> wrote:
> >M/S Word has long had a facility to print a bar code above an address
> >with the zip or zip+5 code in it.
>
> They removed support for the POSTNET barcode several versions ago.
> POSTNET barcode represents a 12-digit number: 11-digit Delivery Point ZIP
> Code plus a check digit. . . .
The bar code in MS Word (vers 6, c 1994) seems to just be taken from
either a plain five digit zip code or a zip+4 nine digit zip code. It
isn't one of the extended bar codes with the carrier route, etc, data,
and doesn't seem to be dependent on the actual address, just the zip
code. In other words, it appears to just convert the five or nine
digits into a bar code.
Are you saying this barcode is obsolete and no longer has any meaning
to the post office? I'm not talking about getting a postal discount,
rather, just to expedite the processing of the mail. For instance,
the return envelope of bills often has a similar bar code on it,
presumably to get it to the delivery address faster.
Thanks.
Old Memories:
1) I remember on the old Compuserve they had an premium app where you
could send someone a Mailgram from your online session. Interesting
overlap from the old to the new.
2) Anyone remember the old postal zones, eg "Brooklyn 15, NY"? I
think they were introduced in WW II in cities. In many cases the old
zone became the last two digits of the zip code when zip codes came
out, eg "Brooklyn NY 11215"
3) Remember the little figurine Mr. Zip? They discontinued using him
some years ago. We used to have an older letter carrier who kept on
wearing his old uniform, complete with uniform cap and metal badge,
instead of the baseball cap and fabric logo. He looked so much more
distinguished in the uniform than the younger guys.
TELECOM Digest is an electronic journal devoted mostly to telecom-
munications topics. It is circulated anywhere there is email, in
addition 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 Bill Horne. 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.
The Telecom Digest is moderated by Bill Horne.
Contact information: Bill Horne
Telecom Digest
43 Deerfield Road
Sharon MA 02067-2301
781-784-7287
bill at horne dot net
Subscribe: telecom-request@telecom-digest.org?body=subscribe telecom
Unsubscribe: telecom-request@telecom-digest.org?body=unsubscribe telecom
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
Copyright (C) 2009 TELECOM Digest. All rights reserved.
Our attorney is Bill Levant, of Blue Bell, PA.
---------------------------------------------------------------
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
organization.
End of The Telecom Digest (12 messages)
|
| |
or 