Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Maximizing Platform Performance
Things can get complicated with protocols that allow multiple modes of operation and real-time fallback to older version procedures just to accommodate interoperability with legacy equipment. H.323 has been streamlined with fastStart and tunneling, but there are at least three ways that you can initiate signaling and thus experience different performance from the same softswitch platform. Therefore, it might be inevitable to require characterization of the modes of operation and interpolate (or, better yet, test each case separately) for performance expectation in between. Similarly, the use of proxies and firewalls in a topology and ensuing requirements for protocol support might dictate the choices that an engineer has to make regarding "preferred modes of operation" for a signaling protocol.
Firewalls can be bottlenecks in the signaling path if they are distributed in the topology and are controlled by external gateways, such as the softswitch itself. The reason is simply the need to signal to the firewall and thus add "arrows" in the call flows. Arrows mean more processing and reduced switch capacity. "Smart" firewall implementations, such as firewalls that are part of or an extension of the softswitch itself, might increase performance, but the impact of such a design on flexibility and scalability must be examined carefully. Firewalls protect both the signaling and media paths, which might not (and, more often than not, will not) be the same. In other words, you might need to make a trade-off between performance and network scalability before picking the final design approach.
Distributed softswitch platforms offer enhanced scalability, but they present other complexities that could prove prohibitive from a cost perspective. The most common way to achieve platform distribution is to develop a complete switch in a single CPU and use internal signaling to distribute call processing among the all processors in the platform. This is nice and easy to say, but you must now consider that there are additional "arrows" in the path of a call that are internal to the platform and that must be accounted for in the performance and capacity analysis. Other complexities, such as failover in cases of equipment or link malfunction, could impose internal signaling requirements that will affect system capacity as well. For example, DNS operations might involve internal "trips" in the switch to a resolution resource and thus would add "arrows" to the complete call flow. Also, audits for calls, equipment, and facilities in cases of gateway restarts can consume computing resources for extended periods of time.
Finally, signaling during an active call is often unnecessary from a protocol perspective, but other signaling is required to ensure proper resource utilization, additional resource requests (such as a request to open a video channel during a voice call), and statistics gathering that all must be accounted for when setting the platform capabilities expectation and billing and OSS signaling. The latter two both require computations local to the switch and signaling to the back office from all the switch elements servicing calls.
Setting the Right Expectation
A softswitch platform that utilizes a number of VoIP signaling protocols (as will inevitably be the case sometime in the future) is dealing with at least two major issues:
Functional interoperability among the protocols, including portions of the protocols that might exist inside local or distributed firewalls
Performance expectation when calls between dissimilar endpoints using different signaling protocols are attempted
In any telephony signaling call flow, there are "arrows" (signaling operations in the ping-pong diagrams) that can be pipelined and "arrows" that cannot. Let's consider a call involving two switches in the path of two endpoints. The total number of arrows to service a call between the originating endpoint and the first switch is 7, including the call termination exchanges. You will see a number of such call flows in the text, and you must not forget to add the termination signaling in the estimating performance. Let's also assume there are five signaling "arrows" between the two switches for this type of call. The terminating exchange signaling protocol uses 8 arrows to service the call, for a total of 20 arrows in the basic call flow. If each "arrow" is an atomic operation and requires 5 milliseconds to execute (including propagation delays between signaling entities), the total time to complete the call is 100 milliseconds. This would make the capacity of the switch 10 calls per second, thus hardly useful.
Luckily, a lot of signaling operations can be pipelined. First, when a signaling message has been dispatched to an entity, the switch is free to service other endpoints and calls. Therefore, we remove the propagation delays from the dispatch of the signaling message to the instant that a reply is received. This leaves the switch processing of the signaling messages as the factor for performance estimation. If the average execution time of the "arrows" in our example is 2.5 milliseconds, the total time dedicated to signaling for this call is 50 milliseconds, or double the capacity of 20 calls per second.
Second, within the same call flow it might be possible to dispatch multiple signaling messages simultaneously to the various entities (switches, endpoints) for the same call, even if they use the same signaling protocol. For example, consider a SIP proxy that receives an INVITE for an endpoint that it serves. It can propagate the INVITE toward the ultimate destination and reply with TRYING back to the originator simultaneously. In the case of a softswitch receiving an NTFY (MGCP Notify message) for an incoming call from a PSTN gateway, it could send CRCX (Create Connection) to the endpoint and the PSTN gateway simultaneously, and then assemble the ACKs from each signaling entity.
Pipelined signaling will increase platform performance and can be used for groups of nondependent serial signaling exchanges.
In the previous example, if three or four signaling messages between either endpoint and its local switch can be pipelined, this might reduce the average time for the call completion by as much as 10 milliseconds, thus bringing up the capacity of the switch to 25 calls per second. This "small" increase can actually translate to savings: If the target is to achieve 100 cps for the entire platform, then the requirement can be met with only four CPUs instead of five in a distributed design.
From the plethora of signaling call flows that you can draw for all types of calls, it might become necessary to plot the operating characteristics of the platform under best- and worst-case scenarios and, with proper weighting, establish the expected operating range of the switch in a real-life deployment. This means simply that the design can support anywhere between 60 and 100 cps at the two extremes; the expectation is that it will operate in the 70–80 cps range for voice calls mixed with a percentage of feature calls, such as call forwarding and call waiting, plus fax and modem calls.
A huge consideration for setting the performance expectation is the requirement to support emergency dialing (911). Simply speaking, in a well-designed platform, an emergency call must be accepted whether or not there is processing capacity in the switch. Therefore, the queuing scheme for calls in progress (not having reached midcall state yet) needs enough sophistication to allow bumping of a call if the switch is operating at or near capacity limits. In any case, the switch must always allow enough processing power to allow it to screen the incoming call before deciding on its own capability to service it to completion.