30 Years of the Digest ... founded August 21, 1981
The Telecom Digest for December 6, 2011
====== 30 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 Bill Horne 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 that person, or email address
Addresses herein are not to be added to any mailing list, nor to be sold or given away without the explicit written consent of the owner of that address. 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: Mon, 5 Dec 2011 17:23:05 -0500 From: "Geoffrey Welsh" <firstname.lastname@example.org> To: email@example.com. Subject: Re: MSNBC/NYT: Caller ID Forging Message-ID: <6c638$4edd4416$adce29b0$2762@PRIMUS.CA> Wes Leatherock wrote: > They are complaining that when only the main number is given from a > PBX, that location may be miles away from where the actual caller is > (and where the need is for fire, ambulance or police). That may be true anyway. I have configured a branch office with no trunks but a T1 back to the PBX at the main office. Some staff at the branch office had DIDs that could have been registered at the new address but some extensions were not DIDs so the main number would have been used for CID. In retrospect that was awfully foolish of me: a 911 operator could have been forgiven for assuming that the address in question was accurate but I might have ended up in a lot of hot water if emergency services showed up to the wrong address and someone was seriously effected as a result (the offices were only a few doors apart but, in a situation like a heart attack, the extra couple of minutes to redirect the responders might have been critical.) I'm probably not the only person to have made such an oversight but hopefully this will remind us all to be mindful of the issue.
Date: Mon, 5 Dec 2011 13:34:09 -0500 From: Monty Solomon <firstname.lastname@example.org> To: email@example.com. Subject: Sneaky Mobile Ads Invade Android Phones Message-ID: <firstname.lastname@example.org> Sneaky Mobile Ads Invade Android Phones Download the wrong app to your Android phone, and you may end up with ads on your home screen or notification bar. We'll tell you who's behind the annoyance and how to get the ads off your phone. By Tom Spring December 4, 2011 Are you wondering how that mysterious icon ended up on your Android phone's start screen? Annoyed at the ads clogging your notification bar? You aren't alone. Thousands of Android apps now include software that shoves marketing icons onto your phone's start screen or pushes advertising into your notification bar--and many of the apps give you no warning about the ad invasion. Many of these ads come from mobile marketing firms such as AirPush, Appenda, LeadBolt, Moolah Media, and StartApp. The companies work with app developers hungry for some way to make money from their smartphone software. By bundling their adware into popular Android programs, these marketing companies say they are now pushing ads to millions of new smartphones each week. Smartphone users generally hate the swarm of marketing on their touchscreens, but the approach is growing fast. One of the companies, AirPush, says 800,000 people a day download an Android app with its adware inside--up from 250,000 just three months ago. It may be next to impossible to completely avoid this kind of advertising on your phone. I looked at dozens of apps that contain ad software and found that few of them disclose that they contain adware. But there are ways to get the ads off your phone, as we'll see below. ... http://www.pcworld.com/article/245305/sneaky_mobile_ads_invade_android_phones.html
Date: Mon, 05 Dec 2011 12:34:16 -0500 From: John Stahl <email@example.com> To: firstname.lastname@example.org. Subject: OSHA: Two Federal DOT Agencies Ban Hand-Held Phone Use Message-ID: <33.43.23309.A900DDE4@cdptpa-omtalb.mail.rr.com> US Occupational Health & Safety has reported on their web site (www.ohsonline.com) that "Two DOT agencies, the Federal Motor Carrier Safety Administration and the Pipeline and Hazardous Materials Safety Administration, published a final rule Dec. 2 that will prohibit use of hand-held mobile phones by commercial drivers while on the road...." It seems that the DOT has put a higher penalty on hand-held cell phone usage while driving than probably most states have imposed on over-the-road drivers and have even added a fine on their employers, too. According to the article, "Drivers who violate the restriction can be charged a civil penalty of as much as $2,750; a civil penalty of as much as $11,000 can be imposed on employers who fail to require their drivers to comply." These new rules take effect January 3, 2012. See complete article here: http://ohsonline.com/articles/2011/12/02/dot-agencies-ban-handheld-phone-use-by-commercial-drivers.aspx 73's, John Stahl
Date: Mon, 05 Dec 2011 10:36:51 -0500 From: Fred Goldstein <fgoldstein.SeeSigSpambait@wn2.wn.net> To: email@example.com. Subject: Re: MSNBC/NYT: Caller ID Forging Message-ID: <20111205153717.5304858A9@mailout.easydns.com> On Sat, 03 Dec 2011, John David Galt <firstname.lastname@example.org> wrote, >Robert Bonomi wrote: >... > > For ALL these reasons, the -only- way that the public will get 'reliable' > > Caller-ID info is via government regulation that requires originating > > telco enforcement. > >This is correct only as long as the feds require any carrier that receives >Caller-ID via SS7 from an earlier carrier to pass it along unchanged. In the recent Order on Universal Service and Intercarrier Compensation, the FCC did require carriers to pass along Calling Party Number and Charge Number unchanged. This was intended to prevent "phantom calls", where the terminating carrier can't tell where the call originated, so they can't see if they can charge high intrastate rates. HOWEVER,the new rules do not require every telco to correctly populate the CPN field; they just require intermediate telcos to pass it unchanged . ... On Sun, 04 Dec 2011, email@example.com (Robert Bonomi) replied, ... > > 1) An ethical telco does not pass along any Caller-ID from a call > > originating on its network (at least not without flagging it as > > "unreliable" in some machine readable way) unless it can > > authenticate that the number belongs to the originating > > subscriber. > >There is no provision in SS7 for such a flag. Actually, there is. Look at ITU-T Recommendation Q.763, the Calling Party Number information element. It includes two bits: Screening indicator 0 0 reserved (Note 2) 0 1 user provided, verified and passed 1 0 reserved (Note 2) 1 1 network provided NOTE 2 - Code 00 and 10 are reserved for "user provided, not verified" and "user provided, verified and failed" respectively. Codes 00 and 10 are for national use. These are also included in ISDN signaling to the subscriber. Now whether telcos ever bother to screen is a different question. (I don't know for sure but I doubt it's done often if at all, at least in the US.) The point is that there is a way to indicate whether a screen CPN passed the originating carrier's screen. And yes I know that ANSI SS7 (used in the US) is not quite the same as ITU SS7, but I think this part is similar, and the ITU stuff is available for free on line. The US stuff AFAIK isn't. -- Fred Goldstein k1io fgoldstein "at" ionary.com ionary Consulting http://www.ionary.com/ +1 617 795 2701
Date: 5 Dec 2011 15:27:09 -0500 From: firstname.lastname@example.org (Scott Dorsey) To: email@example.com. Subject: Re: MSNBC/NYT: Caller ID Forging Message-ID: <firstname.lastname@example.org> John David Galt <email@example.com> wrote: > >1) An ethical telco does not pass along any Caller-ID from a call originating >on its network (at least not without flagging it as "unreliable" in some >machine readable way) unless it can authenticate that the number belongs to >the originating subscriber. This would require a lot of legal changes, to the point of pretty much redfining the concept of the common carrier. --scott -- "C'est un Nagra. C'est suisse, et tres, tres precis."
Date: Mon, 05 Dec 2011 13:16:08 -0500 From: Pete Cresswell <withheld@Invalid.telecom-digest.org> To: firstname.lastname@example.org. Subject: Re: Pending legislation would allow robot calls to cell phones Message-ID: <email@example.com> Per Stephen: >Unfortunately UK has always been "caller pays" - and we still get >voice spam to mobiles.... > >at 6p / minute for cheap retail consumer calls (10 US cents) less bulk >discounts, the call costs are not going to make much difference to a >call centre costs per agent. Never thought of that. I pay 32 cents a minute. The bottom feeder that interrupts my work gets time for 6 cents a minute.... Sheesh! Oh well, so much for "Caller Pays" as a solution.... Seems to me like we're back to challenge-response as the only viable fix. -- PeteCresswell
Date: Mon, 5 Dec 2011 18:08:49 +0000 (UTC) From: firstname.lastname@example.org (Thor Lancelot Simon) To: email@example.com. Subject: Re: MSNBC/NYT: Caller ID Forging Message-ID: <firstname.lastname@example.org> In article <email@example.com>, Doug McIntyre <firstname.lastname@example.org> wrote: >"Geoffrey Welsh" <email@example.com> writes: >>r.e.d. wrote: >>> Can someone point to technical articles/references/etc. giving >>> details about how various methods of caller-id spoofing work? > >>... The obvious way to stop that abuse would be for >>the telco switches to verify that the number provided was associated with >>the trunk in question; > >Most CLECs I have encounted lately do this filtering automatically. >For instance, on my PRI trunks, I can not send out a CLID number that >is not in my range of DIDs, whereas I could with the old ILEC trunks >on the same gear. Again: one major issue here is the inadequacy of the caller id display to the end user. Within the network, there's a "network provided" bit that indicates whether the network or the customer provided the calling party number. The way the interworking standards are written, if you, the originating customer, send a number that is not provisioned on the facility from which you originate the call, that number should be duly sent on in the network -- but marked as customer-provided rather than network-provided. Unfortunately, customers' terminal equipment can't display the network provided bit, so you cannot know whether you can trust the number you have received. There is no reason why cellphones couldn't, and ISDN can (but who has ISDN phones?) -- but analog CLID displays simply can't. And cellphones aren't mandated to, so they don't. What your CLEC is probably doing -- and all should do, really -- is avoiding trouble with the ILEC and the regulators by stamping the ChargeNumber over the CallingPartyNumber any time you hand it a CallingPartyNumber it doesn't know you own. That way, nobody will complain that they allowed a "forged" CallingPartyNumber -- even if they did, correctly, mark it as customer-provided. There is, however, another severe problem, which so long as it persists will make any resolution to this impossible. Some carriers are being allowed to maintain connections to the SS7 network while they blithely stamp "network provided" onto arbitrary numbers that came not from the network but from customer equipment. These parties should (and could, with one stroke of the regulatory pen) be summarily disconnected from the interconnected SS7 network -- as should those who sell them access. Without that, no solution that does not effectively turn CLID back into ANI (by always stamping the ChargeNumber over the CallingPartyNumber at the terminating end office) is technically possible. -- Thor Lancelot Simon firstname.lastname@example.org "All of my opinions are consistent, but I cannot present them all at once." -Jean-Jacques Rousseau, On The Social Contract
Date: Mon, 5 Dec 2011 06:47:23 -0800 (PST) From: Wes Leatherock <email@example.com> To: firstname.lastname@example.org. Subject: Re: Update on at&t/T-mobile merger Message-ID: <1323096443.77255.YahooMailClassic@web111726.mail.gq1.yahoo.com> --- On Sat, 12/3/11, HAncock4 <email@example.com> wrote: > I presume you are talking about dialed direct station-to-station > rates. In those days there was no direct dialing. Later there was a discount for DDD calls, or if DDD was not available to th= e caller, the DDD rates applied to all calls. > In those days rates were usually in steps broken down by mileage. > Could you provide a rate step schedule for a year that reflects > those high figures for California and Illinois? At $3/minute, a > three minute call would cost $9.00. Rates were normally for a initial 3-minute period, and then in one-minute increments after that. Wes Leatherock firstname.lastname@example.org email@example.com
Date: Mon, 5 Dec 2011 03:15:39 -0500 From: Telecom Digest Moderator <firstname.lastname@example.org> To: email@example.com. Subject: I'm looking for #5XB training manuals Message-ID: <20111205081539.GA24898@telecom.csail.mit.edu> Thanks for reading this. I'm writing a brief talk about #5XB, and would appreciate pointers to traning materials. An overview document would be ideal, but I'll take anything. TIA. Bill -- Bill Horne (Remove QRM from my address to write to me directly)
Date: Mon, 5 Dec 2011 08:33:09 -0800 (PST) From: firstname.lastname@example.org (HAncock4) To: email@example.com. Subject: Re: I'm looking for #5XB training manuals Message-ID: <firstname.lastname@example.org> On Dec 5, 3:15 am, Bill Horne <bill@horneQRM.net> wrote: > Thanks for reading this. I'm writing a brief talk about #5XB, and > would appreciate pointers to traning materials. An overview document > would be ideal, but I'll take anything. TIA. The Bell Labs history "Switching 1925-1975" has a full chapter on No. 5 crossbar as well as other numerous references to it as additional applications were developed. I was surprised that No 5. crossbar was able to support Call Waiting. They tried it as an experiment and it was popular, but not cost effective to do in xbar and had to wait until ESS. In the original installation in Media, PA, there was a trial of pushbutton dialing. No. 5 crossbar, combined with AMA, helped bring subscriber dialed direct long distance.
Date: Mon, 5 Dec 2011 18:15:39 +0000 (UTC) From: email@example.com (Thor Lancelot Simon) To: firstname.lastname@example.org. Subject: Re: MSNBC/NYT: Caller ID Forging Message-ID: <email@example.com> In article <mZqdnV68z8zrDkXTnZ2dnUVZ_rGdnZ2d@posted.nuvoxcommunications>, Robert Bonomi <firstname.lastname@example.org> wrote: > Given that the 'telephone company' of the party originating the call > and the 'telephone company' of the party receiving the call are two > different entities -- as is almost invariably the case for > marketing calls. Then: > > 1) The telephone company of the party receiving the call CANNOT do > anything to prevent or even detect spoofed/forged CallerID > info. No amount of money spent will make one bit of difference > in customer attitude/opinion about the 'value' of Caller-ID. > > 2) The telephone company for the party making the calls =has= a > financial incentive NOT to filter 'customer-supplied" CID > data. There are two very different cases here, and the difference matters. A) The "spoofed" CallerID information is marked in the network messaging as customer-provided. B) It is marked as network-provided. In case A, the telephone company of the party receiving the call can do something about it: it can cease sending customer-provided CallingPartyNumber to analog caller-ID displays which can't alert the called party that the number they're receiving is untrustworthy. Or send the ChargeNumber (BTN) instead, so in this case the service behaves like ANI. In case B, the originating telephone company is unquestionably violating its interconnection agreements with other carriers, by marking customer provided calling party number as network-provided, thus violating the interworking standards to which it agreed in order to get either SS7 or ISDN access. In this case, it should be cut off by the carriers to which it is interconnected -- and if this is not done, the regulators should fine them, too, for deliberately facilitating this nonsense. I see hints in the giant new FCC order that someone on the staff there is actually starting to worm his or her way towards this conclusion; it is very, very clear to myself and everyone else I've talked to who's ever worked on carrier interconnection (particularly ISDN interconnection, which was once obscure but is now more and more common with the cheaper pricing compared to SS7, and the tendency of VOIP providers to take advantage of it). Unfortunately, it seems some carriers are throwing up a smoke screen and it may well be one that works. -- Thor Lancelot Simon email@example.com "All of my opinions are consistent, but I cannot present them all at once." -Jean-Jacques Rousseau, On The Social Contract
Date: Mon, 05 Dec 2011 12:02:50 -0500 From: Matt Simpson <firstname.lastname@example.org> To: email@example.com. Subject: Re: long distance tariffs, was: Update on at&t/T-mobile merger Message-ID: <net-news69-FF59D6.firstname.lastname@example.org> In article <email@example.com>, danny burstein <firstname.lastname@example.org> wrote: > Back in 1976 or so, I was living in a student frat-type building > in NYC. I had a girlfriend in Newark, NJ. A friend had one > up in Buffalo. > > We checked out the various costs. It turned out that getting > a Foreign Exchange line from our building to Newark, NJ, would > have let my GF and I talk using an untimed local call, and > let him and his... make a long distance interstate call. In about that same time frame, I worked for a utility in OH that had a generating station on the OH river. The plant did enough business in the KY town across the river that it was cost-effective to install FX lines. Calls to other locations in OH were also routed through KY over the FX lines so they would be interstate instead of intrastate, because that was cheaper.
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.
43 Deerfield Road
Sharon MA 02067-2301
bill at horne dot net
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) 2011 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.