Two-Stage Forking for SIP-based VoIP Services

Two-Stage Forking for SIP-based VoIP Services Tsan-Pin Wang National Taichung University An-Chi Chen Providence University Li-Hsing Yen National University of Kaohsiung Abstract SIP (Session Initiation Protocol) is an application-layer signaling protocol commonly adopted by VoIP systems nowadays. It provides personal mobility by allowing a user identified by a unique logical address to register to a proxy server multiple contact addresses, one corresponding to each SIP-enabled terminal the user may use. To setup an inviting session, the SIP proxy server forwards signaling messages to all registered contact addresses, a process referred to as call forking. Call forking process may degrade the performance of the proxy server. To alleviate the problem, this article proposes two-stage forking approaches, which partition all contact addresses into two groups based on their relative priorities, and perform call forwarding for one group at a time. The second-stage call forking process can be skipped when the callee successfully responds in the first stage, which significantly lowers signaling cost and processing latency. We discuss the management of these groups, with experiments conducted to demonstrate the effectiveness and efficiency of the proposed approaches. Keywords: SIP, VoIP, Personal mobility * Corresponding author. 85

1. Introduction SIP is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants [1, 2]. In SIP, a network component called proxy server is utilized to locate session participants. Before starting any session, SIP user must register a contact address that uniquely identifies her/his currently-used terminal to the proxy server. With the registered address, the proxy server is able to forward session setup requests addressed to the user. SIP provides the flexibility that a user may register two or more contact addresses, one for each actively-used terminal [4]. This feature enables personal mobility, allowing network operators to use a single logical address to identify a user that are reachable via different terminals. Consequently, users need only maintain a single externally visible identifier regardless of their network locations [3]. Fig. 1 illustrates how a proxy sever processes a session invitation request destined for a user that has registered multiple contact addresses. In this example, user A initiates a session invitation request destined for B by sending an message to a proxy server. The proxy server duplicates and forwards the request to all the contact addresses that B has registered, which is the reason why the proxy server is also called forking proxy [1]. User B Fixed phone Mobile phone SIP soft phone Forking Proxy Server Fig. 1. Forking Proxy User A s typically perform the forking process in a single-stage manner [1], meaning that the request is forwarded to all target terminals without any particular order. This approach minimizes user waiting time. However, signaling cost in terms of transmitted messages is maximized as the request is duplicated and forwarded to all possible targets. SIP specification alternatively defines, a parameter ranged between and 1 that specifies the degree of preference for each registered contact address. With the information of, the forking process may be performed in stages [1]. For example, suppose that Jason has registered three terminals (fixed phone with.1, mobile phone with.2, and SIP soft phone with.3). When another user Alice sends to Jason, the forking proxy may forward the request first to Jason s SIP soft phone, then to Jason s mobile phone, and finally to his fixed phone (Fig. 2). To minimize signaling cost, the forking proxy should not forward a request to a target until it is confirmed that all other targets with higher do not respond. This policy essentially creases multiple stages, one for each target. However, such a stop-and-wait fashion forking process potentially maximizes user waiting time. Alice@14.128.1.95 1 Trying Proxy Server =.3 =.2 =.1 Jason@14.128.1.11 Jason@14.128.1.151Jason@14.128.1.17 Ringing Ringing Fig. 2. Staged forking example Ringing 2. Two-Stage Forking Process As a tradeoff, this article considers two-stage forking strategies, which classify contact addresses registered by a user into two groups, active and standby. The classification is based on : addresses in the active group have higher s (and thus a higher priority) than those in the standby group. In the first stage of the forking process, the proxy server duplicates a received request and forks it simultaneously to each contact address in the active group. The second stage proceeds only if there is no response after a fixed period of time, indicating a failure of the first stage. The proxy server commences the second stage by forwarding the request in parallel to each target in the standby group. Fig. 3 illustrates the two-stage forking process. User Agent Client (UAC) Query Callee location information with registrar Location database Response Forward request in first round Standby group Active group 1.6 2.5 Forward request in second round 3.4 4.3 5.2 6.1 User Agent Server (UAS) Fig. 3. Example of Two-Stage Forking Process The performance of the proposed approach depends on the size of the active group. If the active group is large enough to accommodate all registered contact addresses, the proposed 86

approach simply reduces to single-stage forking. On the other hand, if the active group is too small to keep all actively used contact addresses, both user waiting time and signaling cost suffer as the proxy server needs to consult the standby group frequently. Formally, let n be the number of registered contact addresses, m n the size of the active group, and h(m) first-stage hit ratio (FSHR), the successful call establishment rate in the first stage given an active group of size m. The expected user waiting time is upper-bounded by h(m) d 1 + (1 h(m)) (d 1 + d 2 ), (1) where d 1 and d 2 are the time values of the no-response timer in the first and second stages, respectively. The expected signaling cost is proportional to h(m) m + (1 h(m)) n. (2) Clearly, given n and m, the performance of two-stage forking strategy is govern by h(m).in this article, we assume that both n and m are predetermined system parameters, and investigate how to dynamically select members for the active group so as to maximize h(m). The group management issue here seems similar to the cache or storage management problem in computer systems. These two issues are not identical, however, as accesses to cache incur constant time cost regardless of cache size. Consequently, a large computer cache accommodating all accessible data entities surely has the highest performance, while single-stage forking is not our ultimate solution. To facilitate group managements, one might exploit a mobility profile that characterizes user s mobility patterns. However, user profiles are too complicated and sometimes expensive to be implemented in proxy servers. We therefore consider only profile-free management schemes for the active group in the following. 3. Group Management Strategies Group management is to dynamically select members for the confined active group so as to achieve a high FSHR. As two-stage forking strategies partition contact addresses into active and standby groups based on address s, the manipulation of s is central to group managements. Group management schemes are assumed to operate in the following manner. When a user registers a contact address, the address is put in the active group as long as there is still room for it. If this is not possible, some previously-registered address will be moved from the active group to the standby group to make room for the new address. Which address should be replaced is determined by an independent replacement policy. User Agent REGISTER with registrar Store user location information Location database Active group Standby group 1.6 2.5 3.4 4.3 5.2 6.1 Fig. 4. Example of Registration Procedure (m = 2) This article considers four feasible replacement polices: first-in-first-out (), least recently used (), least frequently used (), and with aging (-Aging). Although these polices have been commonly used in storage managements in computer systems, our work is unique in the sense that these polices are all realized in SIP by manipulating standard s. As a result, the address with the minimum in the active group is always chosen whenever a replacement is needed, regardless of which replacement policy is in effect. Some notations are defined to improve the quality of our discussion. We denote the of address i by i, the set of all contact addresses by A, and the set of all contact addresses in the active group by G. A. Strategy: strategy replaces the least recently used address from the active group. Our design maintains a global counter. Its value is increased by.1 and copied to c each time address c is referenced. Extra efforts are made to prevent from overflow. This design can be abstracted by the following three rules. Initialization: When contact address c is registered, c is set to.1. Update: When the proxy server receives a REGISTER,, or request from c, c is set to the current maximum of the active group (i.e., ) plus.1. That is, c i G.1 max (3) Reset: Reassign all s belonging to the same user when some reaches 1.. Let avg i A A i i. 87

Router Switch UAC Proxy Server UAS UAS UAS UAS UAS UAS UAS UAS UAS Fig. 5. Experimental environment Then the reassignment is achieved by i A: max(,1,.1) i i avg (4) B. Strategy: With strategy, the earliest registered address in the active group will be replaced. c in this strategy represents the time at which address c was registered, and it advances only upon address registrations. The maintenance rules for are similar to those of, with the only exception of the update rule. Update: c is updated by (3) only when the proxy server receives a register request from c. It does not advance on the reception of other messages. C. Strategy: strategy replaces the least frequently used address from the active group. To implement, we let i reflect the relative reference count of contact address i. shares the same maintenance rules with, but changes the update rule to the following. Update: When the proxy server receives an or request from c, c is increased by.1. D. -Aging Strategy: One potential problem of is that older addresses, even obsolete, tend to have larger reference counts than newly added ones and therefore can hardly be banished from the active group. As a result, new addresses which are likely to be actively used by the target user recently can be easily removed from the active group. -aging strategy attempts to remedy this weakness by periodically multiplying all reference counts by a common fractional factor, effectively diminishing the advantage of older addresses. This aging procedure is also used to deal with overflows. -Aging therefore inherits the maintenance rules from, with the reset rule changed to Reset: When some reaches 1. and on predetermined time instants, all the s are reset by i A: i i aging _ factor, where < aging_factor < 1. 4. Performance Evaluation We conducted intensive experiments to evaluate the performance of the proposed management strategies. 4.1 Experimental Setup Fig. 5 illustrates our experimental environment. User agent client (UAC) is a Linux-based PC running SIPp [7] software. It sends requests through a proxy server to user agent servers (UASs). Up to nine UASs were deployed, all using VoIP software developed by Xten Company. We used SIP Express Router (SER) to implement the proxy server. SER is a high-performance, configurable and free SIP server developed by iptel [5]. The architecture of SER is so flexible that it can be configured as a registration server, redirect server, or Radius server [6]. We implemented the considered management strategies within SER, thanks to its open architecture. The UAC, UASs, and the proxy server were all put in an isolated network segment, so as to minimize potential influence from any background traffic. The core of the experiments is to simulate the dynamic of SIP events. The UAC issued requests every eight seconds. Each established session lasted five seconds, after that the UAC sent BYE message to terminate the call. Each experiment tested 5 calls. We did not control address registrations in the experiments: the time and frequency of registrations were under the control of UAS s built-in functions. We neither simulate grants of call requests by letting a person wanders around UASs and answers calls when nearby UAS rings. Instead, UASs were modified to stochastically answer calls on behalf of the target callee. Two probability distributions were considered: uniformity and locality. Let pi be the probability that UAS i answer calls. The uniformity distribution assumes that pi = 1/n for all i while 88

Number of received messages Number of received messages Journal of Information Technology and Applications the locality distribution assumes that pi = (2n i)/(2n 1). Let R a = m / n be the ratio of the active group size to the total number of contact addresses. As (1) and (2) indicate that R a has an influence on performance results, we tested two different values of R a (1/3 and 2/3). We used ethereal.9.3 to gather network traffic data. These data were then filtered and analyzed to derive performance metrics. using uniform call-answering probability distribution. Compared with original single-stage forking approach, all two-stage forking strategies have lower signaling costs. Among them, performed the best, followed by -Aging. and had nearly identical results and were next to -Aging. 4.2 Performance Metrics UAC UAS Three performance metrics were considered in our experiments: signaling cost, request processing time, and user waiting time. Signaling cost counts the number of control messages used to setup media sessions. Other signaling messages such as registration requests were not counted as they are not affected by forking strategies. Request processing time is the time the proxy server takes to process received requests. These requests include registration, session setup, and session termination. While different types of requests incur different amounts of processing time, call forking process dominate this measure. The time interval between T3 and T4 in Fig. 6 represents the time taken by a call forking process, which accounts for querying the user location database for contact addresses and forwarding call requests to all found contact addresses. T7 T8-T7 1 Trying Call Setup T8 RTP Media Stream BYE BYE Fig. 7. Timing diagram of User Waiting Time Uniform Distribution (Ra=1/3) 3 -Aging UAC 1 Trying UAS T3 T4 T4-T3 Call Forwarding 3 6 9 Fig. 8. Number of received messages with Uniform distribution (R a =1/3) Uniform Distribution (Ra=2/3) RTP Media Stream Fig. 6. Timing diagram of Call Forwarding User waiting time is the time period starting from the issue of an from the UAC to the reception of the corresponding 2 Ok message, as illustrated in Fig. 7. It includes the call forking latency of the first and possible second stages. The value of user waiting time with two-stage forking strategies is generally governed by FSHR. 4.3 Experimental Results Figs. 8 & 9 show measured signaling costs 3 3 6 9 -Aging Fig. 9. Number of received messages with Uniform distribution (R a =2/3) 89

Number of received messages User Waiting Time (s) Number of received messages Journal of Information Technology and Applications The signaling-cost results with locality distribution are shown in Figs. 1 & 11. Here the performance gain of two-stage forking strategies over the original is higher than that with uniform distribution. In the case of R a = 1/3, still outperformed the others. However, the results of did not differ much from those of the other two-stage counterparts when R a = 2/3. In fact, was overtook by -Aging when m = 9, though not very significantly. 3 Locality Distribution (Ra=1/3) 3 6 9 -Aging Fig. 1. Signaling costs with locality distribution (Ra=1/3) original method..375.37.365.36.355.35.345.34.335.33.325.32.315 Call Forwarding - Aging Fig. 12. Call Forking Processing Time The results of user waiting time are shown in Fig. 13. The original method performed well since it processes call forking in parallel. Two-stage approaches, on the other hand, waste extra time when they need to execute the second stage. The result that has a waiting time lower than the original method deserves an explanation. Although LUR sometimes needs to execute the second stage, this occurred so infrequently that the caused increase can be compensated by LUR s advantage in lower first-stage forking processing time, resulting in a lower average. Locality Distribution (Ra=2/3) Call Setup 8.32 8.31 3 -Aging 8.3 8.29 8.28 8.27 8.26 8.25 3 6 9 Fig. 11. Signaling costs with locality distribution (Ra=2/3) Fig. 12 displays the results of call forking processing time. All two-stage approaches spent less time on call forking than the original method. This is due to smaller sizes of user s location database in case of using staged strategies: only a subset of contact addresses (those in the active or standby group) was processed at a time. In contract, all contact addresses were processed on call forking by the 8.24 - Aging Fig. 13. User Waiting Time for Call Setup 5. Conclusions We have proposed two-stage forking approaches to processing multiple contact addresses in SIP proxy servers. The efficiency and effectiveness of these approaches depend on the management of the active group. The considered management schemes,,,, and -Aging, are all realized by manipulating s, which conforms to SIP specification. The experimental results show that two-stage forking strategies successfully reduce signaling cost, as the process of the standby group can be safely skipped on successes of the 9

first stage. Average call forking processing time of two-stage approaches is also lower than that of the original method, as in general fewer addresses are processed by two-stage approaches. Finally, though the original method performs well in terms of user waiting time, performs even better for its carefully designed replacement rule for the active group. Acknowledgement This work was supported in part by NSC under Grants NSC 94-2213-E-142-2 and NSC 95-2221-E-142-1, Taiwan. Reference [1] J. Rosenberg et al., SIP: Session Initiation Protocol, RFC 3261, IETF, June 22. [2] SIP Tutorial at http://www.iptel.org/sip/ [3] H. Schulzrinne, Personal Mobility for Multimedia Services in the Internet, in European Workshop on Interactive Distributed Multimedia Systems and Services (IDMS), March 1996. [4] H. Schulzrinne, E. Wedlund, Application layer mobility using SIP, Mobile Computing and Communications Review, Volume 4, Number 3, pp. 47-57, July 2. [5] http://www.iptel.org [6] Administrator s guide of SER at http://www.iptel.org/ser/admin [7] http://sipp.sourceforge.net/ 91