Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!wuarchive!swbatl!texbell!vector!telecom-gateway From: nvuxr!deej@bellcore.bellcore.com (David Lewis) Newsgroups: comp.dcom.telecom Subject: Re: Interactions between "retry on busy" & "return call if busy" Message-ID: Date: 24 Aug 89 17:13:05 GMT Sender: news@vector.Dallas.TX.US Organization: Bellcore, Livingston, NJ Lines: 45 Approved: telecom-request@vector.dallas.tx.us X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@vector.dallas.tx.us X-TELECOM-Digest: volume 9, issue 324, message 7 of 9 In article , munnari!batserver.cs.uq. oz.au!anthony (Anthony Lee) writes: >In the proceedings to the 7th International Conference on Software Engineering >for Telecommunications Switching Systems, there is an article by T.F. Bowen >et al from Bellcore. >The article was called "The Feature Interaction Problem in Telecommunications >Systems" The following is a paragraph from the article: [text deleted] >> To make this idea concrete, suppose that customer >>A has automatic "retry on busy", which continues calling a busy line until >>it is free, and customer B has automatic "return call if busy", which >>remembers a call that arrives when the line is busy and returns it as soon >>as the line is free. If A calls B, an infinite cycle of calls could be >>initiated, in which B tries to return A's call but A is retrying B, who >>remains busy trying to call A. > > ..... > >My question is why is it not possible to have the exchange watch for >such a situation and cancel either the "retry on busy" or "return call >if busy". Is it possible to view the above problem as a deadlock >situation ? Part of the problem is that you don't have just *one* situation to watch out for. True, you could have your switches or your service logic (I'm using some perhaps unfamiliar terminology here; sorry -- consider it a peek at Bellcore documents...) (of course, they're not *proprietary* documents, so I won't get fired...) watch for a certain situation. But in an environment where you have a potentially large number of services being introduced fairly rapidly (where "rapid" is in comparison to today's pace -- e.g. two years or less to introduce a new service), you've got an exponentially growing set of pairwise interactions; if you also factor in the multiple states in which any two services can interact... determining the proper pairwise interactions for each new service can become a Very Big Deal. (Which, to my understanding, is the way that it's done in developing a new switch generic today -- and guess how many staff-years it takes to create a new generic? Lots.) -- David G Lewis ...!bellcore!nvuxr!deej "If this is paradise, I wish I had a lawnmower."