home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / telecom / 11987 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  4.1 KB
  1. Path: sparky!uunet!ukma!wupost!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!lll-winken!telecom-request
  2. From: varney@ihlpl.att.com (Alan L Varney)
  3. Newsgroups: comp.dcom.telecom
  4. Subject: Re: Does SS7 Support Early Busy Signal?
  5. Message-ID: <telecom12.854.11@eecs.nwu.edu>
  6. Date: 16 Nov 92 13:10:25 GMT
  7. Sender: Telecom@eecs.nwu.edu
  8. Organization: AT&T Network Systems, Lisle, IL
  9. Lines: 70
  10. Approved: Telecom@eecs.nwu.edu
  11. X-Submissions-To: telecom@eecs.nwu.edu
  12. X-Administrivia-To: telecom-request@eecs.nwu.edu
  13. X-Telecom-Digest: Volume 12, Issue 854, Message 11 of 12
  14.  
  15. In article <telecom12.842.12@eecs.nwu.edu> capek@watson.ibm.com
  16. writes:
  17.  
  18. > While trying to make a credit card call to a persistently busy number
  19. > recently, after typing in the card number for the n-teenth time, I
  20. > wondered if SS7 protocol would allow the calling exchange to "look
  21. > ahead" at the called number and inquire if it is (at that instant)
  22. > busy, before prompting me for the card number.  Of course, I might
  23. > still get a busy if either the line became busy after I keyed in the
  24. > credit card number, or if the response to the query didn't make it
  25. > back to the originating exchange in time. The advantage (to me) would
  26. > be not having to repeatedly pound in the billing.  The advantage
  27. > (small) to the carrier would be not having to do the credit card
  28. > verification, and perhaps getting the line on which I'm calling free a
  29. > bit quicker.  If the call in question were third party bill, or
  30. > collect, the savings could be a lot greater.
  31.  
  32.    Brief answer: It's possible.  SS7 supports a "primitive" query of
  33. 'distant line status'; the response indicates busy/idle and some other
  34. information.
  35.  
  36.    However, there are problems with this mechanism.
  37.  
  38. 1) Only very recent standards changes support such queries over IC SS7
  39. facilities (that is, between LATAs).  Since your call probably would
  40. reach IC operator facilities on the larger ICs, this isn't a huge
  41. issue, but until such standards are implemented, ICs that use the LECs
  42. for operator services would have a problem.
  43.  
  44. 2) There is currently no standard for "billing" an IC or LEC for the
  45. query, unlike the billing mechanism for queries about LEC calling
  46. cards and 'static' line information (e.g., line does not accept
  47. collect calls).  If the query were billed similarly to the calling
  48. card database, it would likely cost more (in access charges) than the
  49. cost of attempting to complete a call to the line.  It's true that
  50. when real operators are involved, the early query might save the IC
  51. some operator time and reduce costs.  The current implementation at
  52. least slows down the number of uncompleted call attempts you can make :-).
  53.  
  54. 3) Customer confusion about the meaning of "busy" during dialing.
  55. Today, such a tone usually means you mis-dialed the call.  I would bet
  56. there would also be hundreds of "auto-dialing" systems confused by the
  57. tone.  If the response to such confusion is to re-try the call, the IC
  58. has gained nothing.  Such repeated attempts cost the IC a small sum,
  59. but generate no revenue.
  60.  
  61. (Such auto-dialing systems might include "smart" coin phones, PBXs,
  62. credit-card POS units, etc.  All this "smart" CPE causes lots of
  63. problems whenever the telephone network is changed in very small ways
  64.  -- much of it was developed by trial and error using a few leased
  65. lines for testing, and it does not adapt as easily as humans to
  66. changes.)
  67.  
  68.   The obvious solution to repeated busy tone is also possible with
  69. SS7.  The 'automatic recall' or 'repeat dialing' CLASS capability
  70. would permit one to request the network to call you when the line is
  71. available.  This should work for most non-PBX and non-coin telephones
  72. when the 'query via IC' standards become widely implemented.
  73.  
  74.    For PBX and coin lines (most coin stations do not have CLASS), the
  75. solution is to "complete" the call even when the line is busy.  The
  76. more obvious solutions are either voice mail, pagers, call waiting, a
  77. portable DTMF generator containing your credit card number (RISKY?),
  78. or a LEC/IC mechanism that provides for automatic repeated message
  79. delivery.  Only the last two methods require no action on the part of
  80. the called party.
  81.  
  82.  
  83. AL Varney - just MY opinion.
  84.