home *** CD-ROM | disk | FTP | other *** search
/ Phoenix Rising BBS / phoenixrising.zip / phoenixrising / tele-dig / td14-069.txt < prev    next >
Text File  |  1994-02-10  |  29KB  |  693 lines

  1. TELECOM Digest     Wed, 9 Feb 94 08:48:00 CST    Volume 14 : Issue 69
  2.  
  3. Inside This Issue:                         Editor: Patrick A. Townson
  4.  
  5.     Don't Trust The Phone Company (Lars Poulsen)
  6.     Cellular Telephone companies in Mauritius (Dirk Vanoucek)
  7.     Help GMSK BER (F. Anwar)
  8.     Toll Free Numbers - Query (Sudeepto Roy)
  9.     Re: Calling 911 on a Cellphone When Out of Area (John Galloway)
  10.     Re: More California / Caller ID Questions (Al Varney)
  11.     Re: California CNID Questions (Lauren Weinstein)
  12.     Re: The Dawn of A New Age (Bill Halverson)
  13.     Re: 610/215 Split - Now I Can't Call 1-800- (Mike King)
  14.     Re: Modems for 3002 Circuits (Barton F. Bruce)
  15.     Re: How to Make a Sun Send Messages to a Pager or a GSM Phone (C. Kimball)
  16.     Re: Landlines Pay Airtime To Call Some Cellular Phones] (Carl Moore)
  17.     Re: Telephone Nunbers in France (Jean-Noel Marchalot)
  18.  
  19. TELECOM Digest is an electronic journal devoted mostly but not
  20. exclusively to telecommunications topics. It is circulated anywhere
  21. there is email, in addition to various telecom forums on a variety of
  22. public service systems and networks including Compuserve and GEnie.
  23. Subscriptions are available at no charge to qualified organizations
  24. and individual readers. Write and tell us how you qualify:
  25.  
  26.                  * telecom-request@eecs.nwu.edu *
  27.  
  28. The Digest is compilation-copyrighted by Patrick Townson Associates of
  29. Skokie, Illinois USA. We provide telecom consultation services and
  30. long distance resale services including calling cards and 800 numbers.
  31. To reach us:  Post Office Box 1570, Chicago, IL 60690 or by phone 
  32. at 708-329-0571 and fax at 708-329-0572. Email: ptownson@townson.com.
  33.  
  34.     ** Article submission address only: telecom@eecs.nwu.edu **
  35.  
  36. Our archives are located at lcs.mit.edu and are available by using
  37. anonymous ftp. The archives can also be accessed using our email
  38. information service. For a copy of a helpful file explaining how to
  39. use the information service, just ask.
  40.  
  41. TELECOM Digest is gatewayed to Usenet where it appears as the moderated
  42. newsgroup comp.dcom.telecom. It has no connection with the unmoderated
  43. Usenet newsgroup comp.dcom.telecom.tech whose mailing list "Telecom-Tech
  44. Digest" shares archives resources at lcs.mit.edu for the convenience
  45. of users. Please *DO NOT* cross post articles between the groups. All
  46. opinions expressed herein are deemed to be those of the author. Any
  47. organizations listed are for identification purposes only and messages
  48. should not be considered any official expression by the organization.
  49. ----------------------------------------------------------------------
  50.  
  51. Date: Wed, 9 Feb 94 14:03:35 +0100
  52. From: lars@eskimo.CPH.CMC.COM (Lars Poulsen)
  53. Subject: Don't Trust The Phone Company
  54.  
  55.  
  56. In RISKS issue 15.46, Tom Bodine reports the unsettling experience of
  57. being accused of making an obscene phone call, after the husband of
  58. the recipient of the call (his wife's best friend) used the "call
  59. return" feature at the end of the obscene call, and then reached his
  60. number.  He speculates that his number was captured by the friend's
  61. telephone switch as the result of a failed call from his wife while
  62. the friend's line was busy with the obscene call.
  63.  
  64. While such a feature interaction is possible (is the number supposed
  65. to be captured on a busy? I know it is on a no-answer failure), there
  66. is another way for this to occur: The perpertrator may have applied
  67. the call forwarding feature on his own phone prior to making the call,
  68. and left it there for a bit afterwards. In this situation, the number
  69. that was captured would not be the Bodines', but that of the perpetrator. 
  70. The effect would be the same, however, except that if the call is a
  71. billable long distance call, the number would show up on the next
  72. phone bill, and in the case of forwarding it would be the perpetrator's 
  73. number (since the last leg of the call is billed to the forwarding
  74. phone).
  75.  
  76. I believe that there is no such interaction problem in the case of the
  77. "calling number identification" feature, since the number is delivered
  78. in real time and only when the call rings through. Thus, the call that
  79. would come in DURING the problem call, would only be recorded if the
  80. recipient had the "call waiting" feature, and in that case would not
  81. get busy, but ringback, and the CNID (if subscribed) would be delivered 
  82. between the rings (call waiting tones)).
  83.  
  84. I am forwarding this note to the TELECOM Digest where someone from
  85. AT&T or Bellcore will probably be able to look up whether the
  86. mechanism surmised by Tom Bodine is also possible. I hope that this
  87. technical information will go some way towards repairing relations
  88. between the families.
  89.  
  90.  
  91. [TELECOM Digest Editor's Note: My memory is vague on this, but I think
  92. this same problem was reported here quite some time ago; or was it the
  93. same person with the same problem back then?  I *know* something about
  94. this topic came up here. If Mr. Bodine insists he is not the party who
  95. made the obscene call, then I guess we take his word for it and find
  96. someone else to blame; but it seems quite a stretch of the imagination
  97. and an unusual combination of circumstances for things to line up as
  98. Lars suggests. I guess it could happen that way. At one time or
  99. another in my life I've received phone calls I did not like, and when
  100. I have used 'return last (obscene) call' and/or 'Obscene Caller-ID' to
  101. return the courtesies shown to me the people have -- well, to put it
  102. bluntly -- lied through their teeth and insisted they were not the
  103. responsible parties, even when I *recognized their voice* as being the
  104. same as that of the original caller. In the case at hand, does the
  105. victim claim that the anonymous caller's *voice* was the same as that
  106. of Mr. Bodine?  
  107.  
  108. This seems to me to be a variation on last week's discussion here
  109. about drug dealers and phones, i.e. why will rotary dial phones stop
  110. drug dealers and their customers from paging each other when all they
  111. have to do is go to Radio Shlock and buy a tone dialer? The fact is,
  112. they don't use this work-around because they are not too bright. Ditto
  113. people who make obscene calls in this day and age with all the gimmicks 
  114. available on the phone network: Phreaks who know the phone network
  115. inside and out generally get their kicks in life by playing with the
  116. phone, not from obscene calls. People who make obscene calls generally
  117. are not sophisticated enough in how the phone operates to construct
  118. all the barriers to identification which Lars suggests. Here and there
  119. comes the exception, so I guess Mr. Bodine receives one 'Get Out of Jail
  120. Free' card (Monopoly game, copyright Parker Brothers) with my compliments.
  121. This is just IMO, you understand. Notice the absence of the /H/ in that
  122. net acronym. That's because I don't give humble opinions.  PAT]
  123.  
  124. ------------------------------
  125.  
  126. From: Dirk Vanoucek <dirk@music.en.open.de>
  127. Subject: Cellular Telephone Companies in Mauritius
  128. Date: 9 Feb 1994 10:15:49 GMT
  129. Organization: CCG Music Production
  130. Reply-To: Dirk Vanoucek <dirk@music.en.open.de>
  131.  
  132.  
  133. I would appreciate any information about Cellular Telephone Companies
  134. in Mauritius.
  135.  
  136.  
  137. (NeXT)-E-mail: dirk@music.ruhr.de
  138.  
  139. ------------------------------
  140.  
  141. From: cnbr73@vaxa.strath.ac.uk
  142. Subject: Help GMSK BER
  143. Date: 9 Feb 94 13:32:47 GMT
  144. Organization: Strathclyde University VAX Cluster
  145.  
  146.  
  147. Hi,
  148.  
  149. I need am approximate relationship between BER and received S/N for
  150. GMSK modulation. Any pointer would do. Thanks for any help.
  151.  
  152.  
  153. F.Anwar  e-mail cnbr73@uk.ac.strath
  154. Comms Div   EEE   Univ of Strathclyde
  155.  
  156. ------------------------------
  157.  
  158. From: sroy@qualcomm.com (Sudeepto Roy)
  159. Subject: Toll Free Numbers - Query
  160. Date: Tue, 08 Feb 1994 18:42:05 -0800
  161. Organization: Qualcomm Incorporated
  162.  
  163.  
  164. Hi!
  165.  
  166. I need some information on Toll-Free (800) numbers :
  167.  
  168. [1]     Configuration/Type of 800 databases
  169. [2]     Search/Sorting techniques applied on 800 database.
  170.  
  171. Any and all information/pointers shall be highly appreciated.
  172.  
  173.  
  174. S. Roy   Qualcomm Incorporated, San Diego, CA.
  175.  
  176. ------------------------------
  177.  
  178. From: jrg@rahul.net (John Galloway)
  179. Subject: Re: Calling 911 on a Cellphone When Out of Area
  180. Organization: a2i network
  181. Date: Tue, 8 Feb 1994 16:56:23 GMT
  182.  
  183.  
  184. In article <telecom14.61.3@eecs.nwu.edu>, John Galloway <jrg@rahul.net> 
  185. wrote:
  186.  
  187. > When I call 911 on my cellular (having seen an accident just happen)
  188. > it appears that I get forwarded to a fixed site that just dispatches
  189. > the call to the proper 911 officem i.e. the first person answers "911
  190. > emergency" but just asks where you are, and then the phone rings a
  191. > second time and you get another "911 emergency".
  192. > Whats going on?
  193.  
  194. I then received this reply in email which I am passing along:
  195.  
  196.  From: zeta@tcscs.com (Gregory Youngblood)
  197.  Date: Fri, 04 Feb 94 16:31:19 PST
  198.  In-Reply-To: <9402040746.AA21194@delta.eecs.nwu.edu>
  199.  Organization: TCS Computer Systems
  200.  
  201. I can tell you what is going on ... unfortunately I can't reply easily
  202. to the net so I'm answering directly to you.
  203.  
  204. In order for the cellular carrier to tell where you are they have to
  205. divide their system into several regions.  Then each region has its
  206. own digit translation tables and that is how the calls get routed to
  207. the proper 911 office.  The problem is that cell sites normally do not
  208. follow 911 center territories so even when the calls are divided like
  209. that it is hard to tell exactly where to send your 911 call.
  210.  
  211. In the interest of time, most 911 centers are able to tell that you
  212. are calling from a cellular phone and in the more advanced 911 areas
  213. they even have special questions to ask you up front, such as
  214. confirming the cellular and then asking for your exact location.
  215.  
  216. I hvae set up cellular digit translations both ways.  I can tell you
  217. one thing, for a company that handles a very large area it may
  218. separate their cells into different areas (such as the case for a
  219. company that has a switch in an MSA area and does the switching for
  220. several RSAs) for various reasons (in this example it would be to keep
  221. track of activity for each market).  Doing this makes it even harder
  222. to separate cells by 911 office because of the switches capapctity to
  223. handle different areas.
  224.  
  225. The next problem comes from cell site physical locations and their
  226. coverage areas.  When a cellular carrier is set up to route 911 to the
  227. closest center it is using the cell site that your call is on as the
  228. determining factor of where to send your call.  However the coverage
  229. for a particular site may cover any number of 911 zones depedning on
  230. lcoation..so usually they have to try and route the 911 office that is
  231. in the most covered zone.  This means if your in the wrong zone you
  232. get the wrong 911 office.
  233.  
  234. All 911 offices in each state and maybe even across state boundries
  235. are usually linked in some fashion so that they can send your call to
  236. the right office right away.  That sounds like what is happening in
  237. your case here.
  238.  
  239. Your call goes to 911 office A, they see a flag that you are on
  240. cellular or other special circuit so they ask wehre you are.  That
  241. tells them what 911 office to send you to so they route you to the
  242. proper office.
  243.  
  244. Hope this helps ... feel free to post this if you'd like.
  245.  
  246.  
  247. Greg
  248. The Complete Solution BBS     Allfiles List:    Anonymous UUCP Calls Accepted
  249. 707-459-9058 (24hrs, v.32)    ~/tcsbbs.lst      Login: nuucp  Password: nuucp
  250. Telemate Distribution Site  zeta@tcscs.com      Cellular Telephony Groups
  251.  
  252.                        ------------------
  253.  
  254. internet    jrg@galloway.sj.ca.us  John R. Galloway, Jr  795 Beaver Creek Way
  255. applelink   D3413                  CEO...receptionist    San Jose, CA   95133
  256.                                    Galloway Research     (408) 259-2490
  257.  
  258. ------------------------------
  259.  
  260. Date: Wed, 9 Feb 94 04:04:07 GMT
  261. From: varney@ihlpe.att.com
  262. Subject: Re: More California / Caller ID Questions
  263. Organization: AT&T Network Systems
  264.  
  265.  
  266. In article <telecom14.63.2@eecs.nwu.edu> ethan@medisg.Stanford.EDU
  267. (Ethan C. Tuttle) writes:
  268.  
  269. > I have a technical/political question about CallerID in California:
  270.  
  271. > Say someone calls me long distance from an LEC that supports Caller
  272. > ID.  My understanding is that the long distance carrier would pass the
  273. > Caller ID info to my LEC, which would then forward those digits to my
  274. > CallerID equipment.  EXCEPT, perhaps, in California.  Does the Caller
  275. > ID legislation in CA protect the privacy of those outside of the
  276. > state?  As a Californian, do I get that Caller ID info from
  277. > out-of-state callers?
  278.  
  279.    Since GTE California and PacBell have not tariffed any form of
  280. CallerID, it is obvious that California telephones to not get Caller
  281. ID, regardless of the presence/absence of such information from the
  282. originator.  Delivery of CallerID information in any of its forms
  283. (analog FSK on analog loops, "bulk" over RS-232 interfaces, IEs in
  284. ISDN BRI/PRI Setup messages, etc.)  is an option controlled at the
  285. terminating interface -- just because the far end sent it to an IXC
  286. who then forwarded it to the terminating CO doesn't mean you get
  287. delivery.
  288.  
  289.    CallerID legislation in CA does nothing to protect or invade
  290. privacy of callers or called parties outside the state.  It can only
  291. restrict what the LECs do as local service providers, and the IXCs as
  292. local/intra-state carriers (and of course, what any person inside the
  293. state is able to do).
  294.  
  295. > More important, does (or will) PacBell actually forward the Caller
  296. > ID info?  I don't yet have a Caller ID box to test.  I tried to ask
  297. > PacBell, but all they seem to know about Caller ID is 'uh, no.'
  298.  
  299.    Delivery ("forwarding" in your terms) is controlled at the
  300. terminating CO.  If it's a PacBell or GTE CO, you don't get CallerID.
  301. Other LECs in California may have other tariffs, permitting CallerID.
  302.  
  303. > I am primarily interested in Caller ID as a cheap transport mechanism
  304. > for ANI.
  305.  
  306.    Ethan, there have been lots of proposals to use ANI (CAMA/FG-B/FG-D) 
  307. as CallerID.  I don't know anyone who has proposed the use of Caller
  308. ID delivery mechanisms as a method of delivering ANI.  (Actually, ISDN
  309. supports both, but it clearly identifies the number as "Calling
  310. Number" or "Charge Number".)  Unfortunately, I hear all sorts of
  311. stories about folks who think ANI and Calling Party Number are the
  312. same.  When the difference is explained to them, they say "Oh, that's
  313. OK.  I understand.  I won't really DEPEND on the number being correct."  
  314. But if you need ANI, you need it all the time (right?).
  315.  
  316.  
  317. Al Varney
  318.  
  319.  
  320. [TELECOM Digest Editor's Note: Maybe it is right 'often enough' in a
  321. non-critical application that it serves the purpose. Whether it is
  322. the billing number or the calling number, the two (if not identical)
  323. show up in the same physical location often enough that a company which
  324. needed to verify addresses or calling party's name, etc could generally
  325. rely on either mechanism that was available to them.   PAT]
  326.  
  327. ------------------------------
  328.  
  329. Subject: Re: California CNID questions
  330. Date: Tue, 08 Feb 94 13:38:08 PST
  331. From: Lauren Weinstein <lauren@vortex.com>
  332.  
  333.  
  334. > Does the Caller ID legislation in CA protect the privacy of those outside 
  335. > of the state?  As a Californian, do I get that Caller ID info from
  336. > out-of-state callers?
  337.  
  338. As far as I know at this time, no California telcos are offering CNID
  339. to their California subscribers, so the question is moot at this
  340. point.  I believe that if CNID *was* present, whatever came in from
  341. out of state would probably be displayed.  The telcos are not
  342. prohibited from offering CNID here -- they simply chose not to do so
  343. since they didn't like the rules (e.g. per-line blocking, non-pub'd
  344. numbers blocked by default, etc.)
  345.  
  346. > More important, does (or will) PacBell actually forward the Caller
  347. > ID info?  I don't yet have a Caller ID box to test.  I tried to ask
  348. > PacBell, but all they seem to know about Caller ID is 'uh, no.'
  349.  
  350. Documents I've seen filed by PacBell indicated that since they were
  351. not providing CNID, and since by extension they were not providing the
  352. mandated mechanisms for California subscribers to protect their
  353. numbers on outgoing calls, they were planning to set the "unavailable"
  354. bit on calls sent out of the LATAs.  I assume GTE was following a
  355. similar plan.  This was sometime back and I haven't heard anything new
  356. lately on the subject.  Every so often there are rumors of some
  357. numbers "leaking" out of California, but most likely this is due to
  358. misconfiguration rather than policy.  It would be interesting to see
  359. some more formal statements about this issue from PacBell and GTE.
  360.  
  361. > I am primarily interested in Caller ID as a cheap transport mechanism
  362. > for ANI.
  363.  
  364. None of the discussion of CNID applies to ANI at all, which is a
  365. completely different system.
  366.  
  367.  
  368.  --Lauren--
  369.  
  370. ------------------------------
  371.  
  372. From: wjhalv1@pacbell.com
  373. Subject: Re: The Dawn of A New Age
  374. Date: 8 Feb 94 22:40:02 GMT
  375. Organization: Pacific * Bell
  376.  
  377.  
  378. In article <telecom14.58.2@eecs.nwu.edu>, <0003945654@mcimail.com> writes:
  379. Here is what the future could bring!!!
  380.  
  381. > TCI, the nation's largest cable television company, is in talks to
  382. > launch a unique pilot project in conjunction with Pacific Gas and
  383. > Electric Co. and Microsoft Corporation to design a "smart home".  The
  384. > home automation industry is expected to triple in size, from $1.7
  385. > billion this year to more than $5.1 billion by the year 2000.
  386.  
  387. > Here is the diary of a future homeowner!
  388.  
  389. [FUNNY STUFF DELETED]
  390.  
  391. The author is closer to the mark that he may realize.  Here are three
  392. interesting, publically available facts:
  393.  
  394. 1.  Two years ago, Bill Gates spent a half-day with PG&E executives in San 
  395. Francisco; he gave a presentation to PG&E employees ovre their Corporate TV 
  396. network.
  397.  
  398. 2.  Two months ago, TCI announced their plans to complete a fiber ring around
  399. the SF Bay area and directly compete with Pacific Bell in porviding 
  400. voice-dialtone.
  401.  
  402. 3.  Two years ago, MCI and PG&E filed a tariff with the CPUC that, in
  403. effect, allows MCI to get fiber anywhere along PG&E right-of-way, in
  404. exchange for PG&E's ability to get some amount of bandwidth as
  405. compensations for the use of their right-of-way.  Under the public
  406. terms of the agreement, MCI will pay PG&E to do the construction, and
  407. PG&E will get to put the value of the contruction into its ratebase.
  408. (For all you non-regulatory-types, the rate-base is what PG&E uses to
  409. calculate how much revenue it needs each year.  In effect, when the
  410. rate-base goes up, your electric bills go up ...)
  411.  
  412. Now, I haven't actually _seen_ the announcement the article's author
  413. bases his story on, but then again I don't know who the author is or
  414. what _private_ info he has access to.
  415.  
  416.  
  417. Bill Halverson   Pacific Bell   
  418. 415 542 6564     wjhalv1@pacbell.com
  419.  
  420. ------------------------------
  421.  
  422. From: mk@TFS.COM (Mike King)
  423. Subject: Re: 610/215 Split - Now I Can't Call 1-800-
  424. Date: Tue, 8 Feb 1994 13:19:15 PST
  425.  
  426.  
  427. In TELECOM Digest V14 #61, dhorvath@sas.upenn.edu (David Horvath) wrote:
  428.  
  429. > With all the advertising about the 610/215 area code split, you'd
  430. > think they'd get it right -- I'm now in 610 (even my new cellular
  431. > phone reports 610).  But I can't make a lot of 1-800 calls.  I have
  432. > AT&T on one line and Sprint (remember the modem offer) on the other.
  433. > Same problem on both.
  434.  
  435. Your outbound IXC is irrelevant to making 800 number calls.
  436.  
  437.   [...] 
  438.  
  439. > general message was that they don't take calls from our area.  Gee,
  440. > they took calls from us back in December.
  441.  
  442. > A call to 611 ultimately resulted in a call back that it was AT&T's
  443. > problem and has been reported to them.  Now what?
  444.  
  445. Besides Pat's solution, try this; it seems to work in many areas:
  446.  
  447. Call 1-800-959-2000.  You'll get [insert telco here] "800 trouble
  448. desk."  Press 1 to report a problem.  You'll then be instructed to
  449. enter the 7D part of the 800 # you're trying to reach.  They'll do an
  450. SS7 lookup, tell you which carrier is responsible for the number, and
  451. then transfer you to the 800 trouble desk for that carrier.
  452.  
  453.  
  454. Good luck!
  455.  
  456. Mike King  mk@tfs.com   
  457.  
  458. ------------------------------
  459.  
  460. From: Barton.Bruce@camb.com
  461. Subject: Re: Modems for 3002 Circuits
  462. Organization: Digital Equipment Computer Users Society
  463. Date: 8 Feb 94 16:25:49 -0500
  464. Organization: Cambridge Computer Associates, Inc.
  465.  
  466.  
  467. In article <telecom14.57.2@eecs.nwu.edu>, henderson@mlnaxp.mln.com writes:
  468.  
  469. > Can anyone recommend a pair of modems, in the 9600bps range, that will
  470. > work on 3002 circuits?
  471.  
  472. Sure.
  473.  
  474. Why you would be doing this in this day and age is another question,
  475. but if those are the circuits you are stuck with ... (the IXC portion
  476. of interstate circuits is EXACTLY the same whether it is 3002 or 56kb
  477. DDS-II (ASDS in ATTese).
  478.  
  479. The ZyXEL modems can do leased lines as well as dialup. The 1496-E
  480. (Economy??) model will ONLY do two wire in leased lines mode and
  481. easily will go to 16.8kb. Street price probably just over $250.  The
  482. E+ will do 19.2kb and probably costs ~$100 more.
  483.  
  484. Their full blown 1496+ (somethimes called the 1496S+ model) with the
  485. LCD front panel does two and four wire leased and does dialup two
  486. wire, of course.  It can use dialup to automatically backup the leased
  487. line, and on programmable timers will periodically retry the leased
  488. line before resuming spending your $s on the dialbackup. Probably in
  489. the $500-$600 range.
  490.  
  491. Can do v.29 or whatever compatibility if you need end to end compatibil- 
  492. ity with existing obsolete leased line 9.6 modems of other brands.
  493.  
  494. Any of those ZyXELs make great general purpose modems when you decide
  495. to not use them on leased lines.
  496.  
  497. OTOH, there ARE some 28.8kb modems out there (no ZyXEL yet) if you can
  498. use the speed. The high end of many brands do both dialup and leased
  499. line.
  500.  
  501. ------------------------------
  502.  
  503. From: cek@sdc.cs.boeing.com (Conrad Kimball)
  504. Subject: Re: How to Make a Sun Send Messages to a Pager or a GSM Telephone
  505. Date: 9 Feb 94 07:00:08 GMT
  506. Organization: Boeing Computer Services (ESP), Seattle, WA
  507.  
  508.  
  509. In article <telecom14.53.7@eecs.nwu.edu> jdb@sunbim.be writes:
  510.  
  511. > I'm looking for something quite special:
  512.  
  513. > We would want to have our Sun, (which is running critical
  514. > applications), dial-out to a semascript pager to tell the sysadmin
  515. > something is wrong. Typically, we have some sort of contool, which
  516. > send a certain fixed message for a certain error-situation. This
  517. > messages would then in fact be send to a modem that dials up a
  518. > semascript pager, and passes on the error.
  519.  
  520. > In our dreams we would like to go even further, and have the Sun dial
  521. > up a GSM telephone, and have the Sun speak to the sysadmin saying that
  522. > there is a problem. (pre-recorded fixed messages). In this case, we
  523. > thought of have a modem that directly dials up a GSM mobile telphone.
  524. > But there are some problems to be solve with this: for example, a GSM
  525. > will not give a Carrier Detect, only a connect signal. Anybody dealt
  526. > with this kind of problems before?
  527.  
  528. > Does anybody out there know of software that does one of these two
  529. > things, or does anybody have some tips, or thoughts he or she would
  530. > like to share with me?  (Like which modems could we use, etc)
  531. > The software may be commercial or public domain.
  532.  
  533. I don't know what a semascript pager or a GSM telephone is, but here's
  534. a Bourne shell script I wrote a while back when I was playing around
  535. on my Sun with a similar idea.  In this case I was calling a pager
  536. that expected me to use a touch-tone keypad to enter the number to be
  537. called back, though it should be trivial to extend the idea to send
  538. any arbitrary message that can be keyed in from a touch-tone keypad.
  539. I don't know how you would do voice.
  540.  
  541. The script uses the freely available "expect" program to drive a modem
  542. via the Sun "tip" utility.  It sends Hayes "atdt" commands to the
  543. modem to mimic pressing the touch-tone keys on a real telephone.
  544.  
  545. Hope this helps.
  546.  
  547. #!/bin/sh
  548.  
  549. Usage(){
  550.     echo "usage: `basename $0` pager_number callback_number" >&2
  551.     exit 2
  552. }
  553.  
  554. case $# in
  555.     2)  PagerNumber=$1;CallbackNumber=$2;;
  556.     *)  Usage;;
  557. esac
  558.  
  559. NonDigits=`expr "${PagerNumber}" : '.*\([^0-9]\)'`
  560. if [ -n "${NonDigits}" ]; then
  561.     Usage
  562. fi
  563. Length=`expr length "${PagerNumber}"`
  564. case "${Length}" in
  565.     4)  PagerNumber="9986${PagerNumber}";;
  566.     7)  PagerNumber="9${PagerNumber}";;
  567.     8)  : ok;;
  568.     *)  Usage;;
  569. esac
  570.  
  571. NonDigits=`expr "${CallbackNumber}" : '.*\([^0-9]\)'`
  572. if [ -n "${NonDigits}" ]; then
  573.     Usage
  574. fi
  575. Length=`expr length "${PagerNumber}"`
  576. case "${Length}" in
  577.     0)  Usage;;
  578.     *)  : ok;;
  579. esac
  580.  
  581. expect - << expectEOF
  582.         send_user "spawning tip ...\n"
  583. set pid [ spawn tip dialers ]
  584.         send_user "sleeping 5 ...\n"
  585. exec sleep 5
  586.         send_user "sending atv1 to ask for verbal (text) responses from modem ...\n"
  587. send "atv1\r"
  588. expect "OK"
  589.         send_user "sleeping 1 ...\n"
  590. exec sleep 1
  591.         send_user "sending atm1 to turn on speaker to monitor the call ...\n"
  592. send "atm1\r"
  593. expect "OK"
  594.         send_user "sleeping 1 ...\n"
  595. exec sleep 1
  596.         send_user "sending atdt${PagerNumber}; to dial pager ...\n"
  597. send "atdt${PagerNumber};\r"
  598. expect "OK"
  599.         send_user "sleeping 10 ...\n"
  600. exec sleep 10
  601.         send_user "sending atdt${CallbackNumber} to send callback number ...\n"
  602. send "atdt${CallbackNumber}\r"
  603. expect "OK"
  604.         send_user "sleeping 3 ...\n"
  605. exec sleep 3
  606.         send_user "sending ath0 to hang up the phone ...\n"
  607. send "ath0\r"
  608.         send_user "sleeping 5 ...\n"
  609. exec sleep 5
  610. exec kill \$pid
  611. close
  612. wait
  613. expectEOF
  614.  
  615.                            ---------------
  616.  
  617. Conrad Kimball        | Client Server Tech Services, Boeing Computer Services
  618. cek@sdc.cs.boeing.com | P.O. Box 24346, MS 7M-HC
  619. (206) 865-6410        | Seattle, WA  98124-0346
  620.  
  621. ------------------------------
  622.  
  623. Date: Tue, 8 Feb 94 17:50:45 EST
  624. From: Carl Moore <cmoore@BRL.MIL>
  625. Subject: Re: Landlines Pay Airtime To Call Some Cellular Phones]
  626.  
  627.  
  628. Replying to V2ENA81%OWEGO@zeta.eecs.nwu.edu:
  629.  
  630. > Back to the original thought of the post, I always thought that the
  631. > only pay exchanges in all of the NYC area codes was 976.  This has
  632. > nothing to do with 1-900, by the way.
  633.  
  634. There is that infamous 540 prefix.
  635.  
  636. > If someone can explain how there could possibly be a phone number
  637. > shortage, especially with the elimination of both 1 + 7D and the
  638. > recent expansion of area code second-digit assignments please send me
  639. > E-mail or post here to the Digest.  I have always believed this to be
  640. > an urban legend, especially in light of the elimination of 1 + 7D in
  641. > the past ten years and the more recent second-digit area code allowance.
  642.  
  643. The "second-digit area code allowance" IS the coming solution to the
  644. phone number shortage, and in preparation for this, either the 1+7D
  645. goes or you end up with some ambiguities which can only be resolved
  646. with a time-out.  (For the same reason, those few places which still
  647. have used NPA+7D for long distance will have to insert leading 1
  648. there.)
  649.  
  650. > ...718 (Queens/Bronx/Bkln).
  651.  
  652. You forgot Staten Island.  (By the way, Bronx joined 718 late, having
  653. stayed in 212 back in 1984.)
  654.  
  655. ------------------------------
  656.  
  657. From: marchalo@aur.alcatel.com (Jean-Noel Marchalot)
  658. Subject: Re: Telephone Nunbers in France
  659. Date: 9 Feb 1994 11:44:52 GMT
  660. Organization: Alcatel Network Systems, Raleigh NC
  661. Reply-To: marchalo@aur.alcatel.com
  662.  
  663.  
  664. In article 18@eecs.nwu.edu, Earle Robinson <76004.1762@CompuServe.COM>
  665. writes:
  666.  
  667. > Richard D G Cox said that the change in French phone numbers is put
  668. > off due to complaints from users.  This I doubt, since almost no one
  669. > in France is aware of any impending change.  There is almost complete
  670. > ignorance of such questions in France, in part due to the few people
  671. > who have access to Internet. 
  672.  
  673. Never heard about something called Minitel? Any idea about the penetration 
  674. rate compared with Internet? (probably an order of magnitude larger).
  675.  
  676. > Anyway, France Telecom does what it wants.  There's no competition
  677. > and the French just bow and obey.
  678.  
  679. Sure, now they are still really lucky to enjoy a network that has
  680. evolved in 15 years from one of the most backward to one of the most
  681. advanced in the world. There must be some mysterious mechanism, beyond
  682. competition, that made sure that France Telecom would be a little
  683. responsive to the users' needs and the users do more than "bow and
  684. obey"?
  685.  
  686.  
  687. Jean-Noel Marchalot
  688.  
  689. ------------------------------
  690.  
  691. End of TELECOM Digest V14 #69
  692. *****************************
  693.