Occasionally I get to observe a client who has made a mistake; sometimes they come to us to help clean things up.
One such mistake is selling something that you don't have to sell. There are two forms of this mistake: the "Maximum Scale Error", and the "Unknown Cost Error".
Maximum Scale Error. Suppose you have a service, like Shared Call Appearance (SCA), also called Shared Line Appearance (SLA). This feature allows one phone to appear to have extensions for many other lines just like an old Key system. So you press one button to pick up "line one", and another button to pick up "line two", and you have the same buttons on several difference VoIP phones in your office. The mistake is assuming that you can reasonably expand that to any number of lines. For example, if you have a 10-button phone, you might assume you could share 10 lines across all those phones.
This is a simple naiveté: while some of the technology scales arbitrarily large, there are practical limitations on current implementations. In this case, a SIP message can carry arbitrarily large numbers of shared lines. But SIP over UDP can only handle a few, and UDP is what is often in use.
To avoid this error, you have to actually prove what the limits are. Are two SCA instances supported? Are five SCA instances supported? Are ten? In the case of SCA, there are actually two dimensions: (a) number of SCA lines, and (b) number of phones involved in the SCA line. The number of SCA lines relates to the maximum size of the messaging sent to any one SIP phone. But if you have only one SCA instance shared among 100 phones, then there's another scaling problem: the signaling cost of notifying all 100 phones may overwhelm the link connecting those 100 phones to the Application Server.
How do you prove the capability? The simplest form of proof is analysis. In this example, that's estimating signaling requirements network capacity/bandwidth. But these are also complex systems, and it can be difficult to know that you're accounting for every component in your analysis. Thus, you should also prove by testing the scale you wish to sell in advance.
Unknown Cost Error. Let's extend the example of Shared Call Appearance, and you've proven that sharing a line across six (6) SIP phones works just fine for customers connected via T1. Let's start selling! But then your Application Server (AS) / Call Agent (CA) or Session Border Controller (SBC) starts to have overload problems. What happened?
It turns out that SCA incurs a high cost on the system because all of the simultaneous messaging that must occur: every phone in the group is sent a SIP INVITE, and also SIP NOTIFY messages about the status of the other phones in the group. In a study with the popular VoIP platform BroadSoft's BroadWorks, placing single telephone call using SCA with six phones can create a burst 2.4 Mbps in SIP messaging. Using SCA in this call, a single telephone call can consume roughly six times the server/SBC capacity of a single "ordinary" phone call. Suddenly, your server capacity has dropped by 87% (since each call uses 6x capacity of one call, you have only 1/6 server capacity remaining.)
The naiveté here is not knowing how much the feature would cost, but selling it anyway. To continue the example, if you sell SCA heavily and thus "fill up" your system sooner than expected, will you have the revenue to upgrade or augment your system?
