Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!mailrus!accuvax.nwu.edu!nucsrl!telecom-request From: nvuxg!mjs1@bellcore.bellcore.com (Michael Sonnier) Newsgroups: comp.dcom.telecom Subject: Re: Caller ID (NOT Another Flame!) Message-ID: <4245@accuvax.nwu.edu> Date: 22 Feb 90 22:41:22 GMT Sender: news@accuvax.nwu.edu Reply-To: 23185-Michael Sonnier Organization: Bell Communications Research Lines: 128 Approved: Telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 10, Issue 121, message 2 of 5 In article <3966@accuvax.nwu.edu>, comcon!roy@uunet.uu.net (Roy M. Silvernail) writes: > In article <3841@accuvax.nwu.edu>, ames!ames!claris!portal!cup.portal.com! > fleming@uunet.uu.net writes: > > Why aren't the BOCs rushing to offer this (calling name delivery) > > as a solution? > > Simple... Judge Greene won't let them. Running a phone number through > > a database and flashing an associated ASCII string onto your screen > > qualifies as an information-processing service, and that's a no-no. > I haven't studied the break-up too closely, but it would seem this is > an ideal opportunity for a symbiotic service. Couldn't the private > sector produce a company to service this information-processing? And > wouldn't that be seperate from the BOC itself? Independent of who provides the database lookup, there are very real network performance issues (read $$$s) to be considered. Considering simply the volume of queries to this database that are likely, the amount of processor time sucked up on switching systems could be huge. A few moments reflection leads me to believe there are (at least) 4 major alternative ways to provide such a service (Labeled A1, A2, B1, and B2): A> Do the lookup at the originating end of the call, and pass the information in the SS7 call setup message (Initial Address Message) This has the advantage that the data can be somewhat localized. The big disadvantage is that it must be done on every call (or at least every inter-switch call) since it is not known whether the terminating party subscribes to the feature. A1> Store the data on the switch, and have the switch do the lookup There is a clear impact on the memory requirements as well as processor real time of the switch. The memory to store the ID strings, as well as indexing information to aid in rapid lookup, is huge, especially relative to some of the older technology electronic switching products that exist (and will continue to exist for a LONG time) in the network. In addition, the per call addition to average processor time used could be quite significant. A2> Store the data on a database accessed by the switch There is still some impact on the switch processor real time used, though likely smaller than case A1. However, some delay is added to the processing of each call (and remember that 100ms is considered large when dealing in Initial Response Time for call setup), causing both a degradation of service for customers, but also increasing the holding time of every call at the switch resulting in increased usage of switch resources (e.g., either need to pay for more resources or decrease the capacity of the switch). Cases A1 and A2 are especially painful since they must be processed on (almost) every call in the network. This makes these alternatives essentially infeasible, since the marginal cost will be quite high, especially if few people subscribe to the service. B> Do the lookup at the terminating end of the call: This has the advantage that you only need the lookup if the terminating party subscribes to the feature. B1> Store the data on the switch All of the same concerns as case A1 apply, with the magnification that the database for all network users, not just those served by this switch, must be stored at each switch. Clearly not a feasible approach! B2> Store the data on a database accessed by the switch Again, either the data will need to be copied many places in the network (i.e., near each switch) or these data queries will involve lengthy distances. In the first case, data must still be duplicated, which is very costly both in terms of equipment and overhead to populate and maintain the many copies of the data in a coordinated fashion. The second case is similar to case A2, except the cost per query will be much higher, consuming more resources due to the distance. In addition, the anticipated delay in call processing will probably be larger due to the distance. Again, the cost in terms of network capacity could be large for alternatives B1 and B2. Though there is an order of magnitude decrease in the number of data lookups to be perfomed over the A cases, the cost per lookup and the delay resulting are larger. And I haven't even gotten into the difficulties where inter-LATA calls are involved! (Yes, I know that calling number display doesn't apply today on inter-LATA calls, but that doesn't mean it won't ever.) The prospect of some third party providing the data lookup for the TelCo is very scary. Not only do all of the above concerns exist, but there are many significant new concerns: the delay properties of the network, service reliability, and quality of the network provided service are largely out of the TelCo's control. Who are you going to call when the service doesn't work properly? Who's going to get flamed when call setup takes longer? I must point out that I have not studied this area in any depth. I do not mean to suggest that such a service cannot or will not be offered, or even that such a service is not under consideration. Frankly, I don't work on this, and just don't know whether or not that is the case. My only purpose in writing this is to point out that there are significant technical hurdles to providing such a service, and that such a service MAY potentially be very costly. How much would YOU be willing to pay for such a service? SPECIAL DISCAIMER: This is presented solely as my opinion, and has no connection in any manner whatsoever to the opinions of my employer. I make no claim as to the accuracy or quality of the opinions presented, nor to their relationship to anything, or anyone. Any similarity to persons, places, things, or ideas living or dead is purely coincidental. Michael J. Sonnier @ Bellcore; Navesink Research & Engineering Center Logical: [...]!bellcore!nvuxg!mjs1 | Audible: (201) 758-5787 Physical: 331 Newman Springs Rd #2Z419; Red Bank, NJ 07701 "Trust us; we're the phone company and we're here to help you; WE know what's best!" ;-) Disclaimer: How can you infer this is the opinion of my employer? I don't even know if it's mine yet!