home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / telecom / 12098 < prev    next >
Encoding:
Internet Message Format  |  1992-11-21  |  2.4 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!ames!lll-winken!telecom-request
  2. From: rickie@trickie.ualberta.ca (Richard Nash)
  3. Newsgroups: comp.dcom.telecom
  4. Subject: Re: Does SS7 Support Early Busy Signal?
  5. Message-ID: <telecom12.866.7@eecs.nwu.edu>
  6. Date: 22 Nov 92 02:14:33 GMT
  7. Sender: Telecom@eecs.nwu.edu
  8. Organization: TELECOM Digest
  9. Lines: 36
  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 866, Message 7 of 12
  14.  
  15. Peter Capek writes:
  16.  
  17. > While trying to make a credit card call to a persistently busy number
  18. > recently, after typing in the card number for the n-teenth time, I
  19. > wondered if SS7 protocol would allow the calling exchange to "look
  20. > ahead" at the called number and inquire if it is (at that instant)
  21. > busy, before prompting me for the card number.  Of course, I might
  22. > still get a busy if either the line became busy after I keyed in the
  23. > credit card number, or if the response to the query didn't make it
  24. > back to the originating exchange in time. The advantage (to me) would
  25. > be not having to repeatedly pound in the billing.  The advantage
  26. > (small) to the carrier would be not having to do the credit card
  27. > verification, and perhaps getting the line on which I'm calling free a
  28. > bit quicker.  If the call in question were third party bill, or
  29. > collect, the savings could be a lot greater.
  30.  
  31. Unfortunately in a basic call setup message, 0+ wants to first secure
  32. the billing method before determining the state of the called party
  33. line.  Yes, it would be possible to determine the line state of the
  34. called party first, but this would require actually connecting to the
  35. called party first, playing out an announcement to advise them to wait
  36. while the billing information was secured, and then either advising
  37. them that the calling party will be with them or that the calling
  38. party's credit check has failed.
  39.  
  40.   Correct me if I am wrong, but SS7 does not have a 'prober' style
  41. message that asks the far end to return information of the busy/idle
  42. status of a line.  In fact, it is telco optional as to whether or not
  43. the treatment will actually be returned back to the originating end.
  44.  
  45.  
  46. Richard Nash              Edmonton, Alberta Canada T6K 0E8
  47. UUCP:                     rickie%trickie@ersys.edmonton.ab.ca
  48. Amatuer Radio Packet:     VE6BON @ VE6MC.AB.CAN.NA 
  49.                           VE6BON.ampr.org [44.135.147.206]
  50.