June 06, 2006

Feature Interaction

Carl’s guest post on Feature Interaction has prompted Alec and Martin to post their thoughts on this matter. Carl has responded to their posts. In this post I respond to Alec’s claim that “feature interaction is a boogeyman”.

Alec’s example for feature interaction – failure of “simul-ring” when the call is originated from one of the “target” phones is not feature interaction at all. After all there is only one feature. As he points out it is an implementation of incomplete logic. As he correctly points out the logic should have checked for this possibility. (The corrective action suggested by Alec will work only if the SIP Proxy is given the caller id information in the first place.)

Alec rhetorically asks isn’t feature interaction “really just a case of a poorly designed feature?” I could take issue with it. But the point that Carl and I discussed is the logistical issues when features are independently developed and deployed. When I raised the possibility of false nirvana, Carl brought up the counter point that rich user interface will solve the problem of feature interaction. This is true, but does not solve the problem.

You see, the clients and the first n features have already been deployed. The users are familiar with these features. With this background, imagine an independent developer developing “n+1” feature. S/he must make sure that the logic for the new feature interacts in an expectable (acceptable?) manner, given the user interface limitations. This is easier said than done, because the set of “n features” may differ from one user to another. It is worse when “n+1” and “n+2” features (that may interact) are being developed independently but may be deployed concurrently. This testing and verification process introduces delay in deployment and invariably introduces the loathsome arbiter. I would think that there is a conference running on this topic for almost a decade suggests that feature interaction is a real issue.

Posted by aswath at June 6, 2006 04:07 AM
Related Posts Widget for Blogs by LinkWithin
If you do not have an OpenID, then please use www.enthinnai.com/unauopenid/anyblog.

 

Comments

Doesn't this therefore suggest we'll continue to see competing fully integrated yet isloated communications systems, with limited interoperability -- rather than an open, seamless one with no owner? There will thus not be a voice equivalent of the Web within the forseeable future.

Maybe using the PSTN for interop isn't such a bad idea after all. At least it works. Shame that there's no presence and availabilty features.

Posted by: Martin Geddes at June 6, 2006 06:41 AM

Hi Aswath,

There is a conference -- used to be called the Feature Interaction Workshop, and now it's called something else. The last one was in 2005, so they're about due for another.

Regarding the situation I described, why is that not a feature interaction? There are two features I see -- the simulring, and the call forward busy feature.

I think the POV I have on feature interactions is that most are easily solved. It is the esoteric cases that are frequently cited that are hard to solve, but perhaps not common problems. For instance, what would the world look like if my telephone was programmed to phone yours at exactly the instant it detected you were present, and your phone was programmed to do the same... we'd have a collision. Both would go to voice mail. Is this likely to happen? I think the timing alone is unlikely.

A

Posted by: Alec Saunders at June 6, 2006 09:59 AM

Martin:

Precisely. But the industry is promising independent feature development braking the mold of the “intelligent network”. But I am not sure why this implies we need to use PSTN for interop. We could just as easily use IP connectivity for media transport and a very basic subset of SIP in place of SS7. This way we do not have to lose presence and availability features. I think the problem is not technical, but business - the VoIP service providers are artificially creating a barrier.

Alec:

I had not realized from your description that you are including CFB. I said it is not a feature interaction because that problem is there even with out CFB.

It is true that feature interactions are solved. If nothing else, they are solved by definition. But it is a tedious work. When a new feature is proposed, one has to enumerate interaction with every other existing feature and develop resolution rules. If two features are being developed in isolation, the potential interaction will be discovered only after deployment. These two points suggest that even in IP domain, introducing new features is just as cumbersome as in PSTN. That was the point Carl and I had talked.

I don’t think I will call the call collision scenario to be an instance of feature interaction. But that is just me. In any event, this will not happen in VoIP :-) . After all both the end points are intelligent. They will recognize that they are talking to each other; they will do “enie meanie minie mo” and one session will survive. Sorry, I forgot. VoIP terminals haven’t become intelligent yet.

Posted by: Aswath at June 6, 2006 12:01 PM

A lot of very bright people have worked on formal methods for the verification of services in the Intelligent Network, with little to show for it. The problem is fundamental to the services themselves, not with whether the INAP or SIP transport protocol is used to carry signalling.

Posted by: Fazal Majid at June 13, 2006 03:44 AM



Copyright © 2003-2014 Moca Educational Products.