|
SIP Server Capacity Planning - An IntroductionSession Initiation Protocol (SIP) is a telecommunications signaling protocol for establishing, maintaining and tearing down sessions between a variety of types of real time media – voice, video, text messaging, and on-line gaming. For such activities, SIP will locate the party, establish a communications session and allow for the modification of session flows as necessary. This newsletter will highlight important issues, considerations, metrics and calculations that would support the process of determining the capacity of SIP proxy servers, which are used to assist the session establishment process. We are going to discuss capacity planning in terms of IP telephony applications, with an emphasis on end-user-office-level SIP servers – the PBX replacement engine. Capacity planning of computer resources includes several tasks:
The last task may be the most difficult as it involves testing, measuring, simulating, and extrapolating, not all of which might be readily available. The voice related requirements and goals of the IP telephony office system, as opposed to a carrier’s systems, should consider the following factors:
Understand the SystemThe next step is to understand how the proposed system works and what variables can impact its operation, which in this case includes an understanding of the SIP protocol and SIP server activities. 
IP telephony systems usually are comprised of IP phones (hard phones or computer-based softphones), a controlling server(s), adjunct media servers for such things as voice mail or conferencing, and conversion gateways all linked through a local area network with appropriate switches, routers, and firewalls. Diagram 1 shows the basic components of such a system.
SIP is like glue that logically controls the calling over such a system. It is an Internet Engineering Task Force (IETF) standard that provides two main functions: finding potential call recipients and connecting them as they move among locations.
There are various types of logical SIP servers and various types may run on the same physical machines. Examples of SIP servers are:
2. SIP Registrar – Accepts registration requests for users in the system and manages the identity and authenticity of end devices in the system. Other Related Servers – Adjunct server functions may be provided in the system for such functions as call accounting, instant message and presence management, unified communications, conferencing, etc. which may participate in the SIP message flow. It should be noted that commercial implementations of these logical servers could be in the form of a single machine running additional applications and may go by the name of call controllers, call managers, IP-PBX, softswitch, etc. Understand the FlowThe SIP call session establishment flow is shown in diagram 3. SIP uses a Request/Response-based protocol. Six request commands include Invite (want to establish a session), ACK (acknowledge the reception of a response), Cancel (stop pending transaction), BYE (used to abandon a session), Options (query to a server) and Register (inform a server).
There may be other SIP proxies in the signaling path, especially if this was an outbound call to another office. The carrier(s) use several core SIP proxies and there would be other, office-level SIP servers, at the receiving end. Office level proxies would be some form of Call Stateful proxy, as more duties are imposed on it for call management functions. In fact, B2BUAs may be more commonly used today within the office setting. Server Capacity ConsiderationsSever capacity considerations would include real memory size as well as CPU speed and utilization, primarily. The Operating System (OS) used in the server may have some bearing on the performance and efficiency of the server; however, the application(s) performing the SIP duties (UAS) would have a bigger impact. The SIP standard defines what needs to be done but not how it is done or coded. Each vendor’s implementation of the SIP duties and how their program is written to implement them, as with any application, becomes an important component of the server’s operational efficiency. There are several considerations that go into SIP server capacity determination. One is the number of SIP messages the application generates and processes per call. The flow used in this diagram shows a typical 13 messages; however, this is a straight forward example without additional tasks being performed or error/timer messages being generated. The SIP proxy may be called upon to perform other duties per call request, such as to authenticate the UAC by sending challenge/response messages, performing address lookups (DNS queries), query a location server, send provisional responses in place of real responses in the event of processing or other delays, processing additional and complex SIP message headers, handling state information, etc. This is especially common for outbound or out of office calls. SIP proxies may be configured so that not all messages need to traverse the proxy. In this diagram example, the BYE and OK exchange could be sent directly between clients, which would reduce the processing time per call. Because SIP allows the use of multiple transport protocols, including UDP and TCP, it is important to understand the impact each has on server performance. TCP, being a connection-oriented protocol, establishes sessions between end devices and keeps track of correctly received data segments by sending acknowledgements back to the sending end point. It also supports a packet flow-control mechanism. While providing more functionality, it is a more complex protocol than UDP, which is a connection-less service with no acknowledgements. When used as the transport protocol for SIP signaling messages, TCP requires more server processing time per call, with some benchmark studies showing up to 40% more time. So why not just use UDP for all SIP transactions? The SIP protocol has several timers that will kick off a retransmission of a previously attempted request if it has not been responded to in some way before the timer expires. Such a delay may be due to a network problem, such as a dropped or compromised packets, or it could be due to a slow, overworked server. UDP does not provide feedback for such situations so the SIP timers, which can be set at a high default value (500 milliseconds), will kick in causing a request retransmission. SIP running over TCP can take advantage of TCP’s feedback and timer mechanisms, which could provide a more effective packet/message flow and a smoother increase in response times, compared to large jumps with SIP timers only, as loads increase on the server. For a more detailed understanding of the effect that increased utilizations have on a resource such as a server, see the newsletter Applying Queuing Theory to Network Design. The processing of SIP requests will involve some form of a database access including registrar activities and contact address look-ups for intra-office calling and authentication checks and DNS queries for outbound calling. Depending upon the user population, calling activity level and physical location of the database, such accesses can have an influence on processing time and RAM utilization. Database configurations could include in-memory tables, in-memory with disk caching and external to the server databases alternatives. Each structure can impact processing delay and memory usage differently per query – all tables in memory provides the fastest access while external database systems are slower but can offer larger storage space, be easier to maintain by remotely connected management tools and may provide for faster system rebooting. Server processing time per transaction for a stateful proxy is higher than for a stateless proxy as more (call state) information must be handled and maintained throughout the duration of the call. B2BUA servers would have the most processing load on the CPU. In addition, for each active call, state information must be maintained requiring more real memory, 30K bytes per concurrent call as an example. When computers do not have enough real memory they revert to using virtual memory, which involves a relatively slower disk operation called paging – where information chunks are continuously moved back and forth between disk storage and real memory. Determine the LoadFinally, the potential load on the server must be determined and would include:
Other Considerations and Goals:
Security requirements: This affects processing time.
Backup requirements: This affects number of machines.
Questions to ask vendor:
This is the type of analysis and thought that needs to go into the decision to purchase a vendor’s IP telephony system and SIP server when considering capacity requirements. As real-time SIP-based applications are very sensitive to delay, under sizing a server may save money but it will result in unhappy users, one of whom maybe the boss. Further TrainingThese types of tips and insights can be found in all training classes provided by McGuire Consulting. The high quality nature of these courses is based on the many years of work and training experience of the author, Jay D. McGuire. |
The SIP protocol logic implemented in the end device (IP phone, PDA, laptop) is called the SIP User Agent (UA) or UA client (UAC) and in SIP servers it is called the UA server (UAS), as shown in diagram 2. SIP is used to establish call sessions and is not involved in the actual transport of the media (voice) and, therefore, the SIP servers are not involved with the media transport either – calls do not go through the servers. SIP servers are there primarily to assist the end devices with establishing links to each other.
There are many response messages, which are grouped into six categories (100, 200, 300, 400, 500 and 600 class messages) and include items like Trying, Ringing, OK, status messages and error messages. In this diagram, UAC1 sends an Invite request to UAC2 via the SIP proxy (B2BUA) to establish a session – call UAC2. UAC2 returns the response message Ringing and when the phone is answered, returns an OK response message. After an ACK is sent by UAC1 to signify it received UAC2’s OK, a call path is established directly between the two UACs as a separate IP media session. These voice packets are handled by another protocol, the Real Time Protocol (RTP), and not SIP. This is why voice or media traffic is sometimes referred to RTP traffic or RTP packets. When the conversation completes, a party hangs up, a BYE request is automatically initiated and an OK response from the other UAC terminates the SIP message session.
