SIP Intrusion Detection and Prevention:
                        Recommendations and Prototype
based step. The prototype implementation shows a first step                                    or on signature-based de...
scalability of the solution while keeping the advantages of the                                clarify their scopes:
again a filter which decides if the packet should be analyzed                                  decrease in performance ...
   In order to evaluate the end-to-end delay introduced by the                                                   0.0011...
paper. This prototype extends the basic functionality of Snort
implementing SIP knowledge-based security checks and pos...
Upcoming SlideShare
Loading in …5

Sip Intrusion Detection And Prevention Recommendations And Prototype Implementation


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Sip Intrusion Detection And Prevention Recommendations And Prototype Implementation

  1. 1.  SIP Intrusion Detection and Prevention: Recommendations and Prototype Implementation S. Niccolini A, R. G. Garroppo B, S. Giordano B, G. Risi B, S. Ventura C A NEC Europe Ltd., Kurfürsten-Anlage 36, 69115 Heidelberg, Germany; Tel +49.6221.905.11.18 B University of Pisa, Dip. di Ingegneria dell'Informazione, Via Caruso, 16, 56122 Pisa, Italy Tel.: +39 050 2217511 C Haute Ecole d'Ingénieurs et de Gestion du Canton de Vaud (HEIG) Rte de Cheseaux 1, CP, CH - 1400 Yverdon-les-Bains, Switzerland, Tel + +41.24.423.21.11 e-mail: saverio.niccolini@netlab.nec.de, r.garroppo@iet.unipi.it, s.giordano@iet.unipi.it, g.risi@iet.unipi.it, stefano.ventura@heig-vd.ch among different new and legacy protocols, and interactions Abstract — As VoIP deployment are expected to grow, among multiple network elements. intrusion problems similar to those of which data networks Existing vulnerabilities including eavesdropping, connection experience will become very critical. In the early stages of hijacking, call fraud, and denial-of-service will take on new deployment, the intrusion and security problems have not been forms in a converged network. Other new vulnerabilities may seriously considered, although they could have a negative be able to exploit the signaling and media connections impact on VoIP deployment. In the paper, SIP Intrusion between the two types of networks. Voice services over Detection and Prevention requirements are analyzed and an wireless LANs (VoWLAN) may create additional IDS/IPS architecture is proposed. A prototype of the proposed vulnerabilities. Meantime, to switch over VoIP, legacy architecture was implemented using as a basis the very popular open-source software Snort, a Network-based telephone users demand the same Quality of Service (QoS) Intrusion Detection and Prevention System. The prototype of they receive from the traditional time division multiplexing the proposed architecture extends the basic functionality of (TDM) based public branch exchange (PBX). In this scenario, Snort, making use of the preprocessing feature that permits network intrusion is a serious security exposure that could analyzing protocols of layers above the TCP/UDP one. The result in not only losing a dial tone but also bad voice quality. preprocessors block is a very powerful one since it permits to Indeed, Intrusion Detection Systems (IDS) and Intrusion implement both knowledge and behavior based intrusion Prevention Systems (IPS) should control both signaling and detection and prevention techniques in Snort that basically RTP communication traffic in order to securing the network. adopts a network based technique. An important requirement In particular, from a security viewpoint, VoIP presents two of an IPS is that legitimate traffic should be forwarded to the main peculiar features: RTP communication can be routed recipient with no apparent disruption or delay of service. independently of the call setup path and security should Hence, the performance of the proposed architecture has been definitely be handled without sacrificing the quality of voice evaluated in terms of impact that its operation has on the QoS communication. The first characteristic implies a necessity for experienced by the VoIP users. a deep investigation to determine the validity of the RTP packets (e.g. call setup and live communications may need to Keywords— Intrusion Detection System, Intrusion Prevention be closely observed in order to verify its legitimacy). The System, Snort Inline, end-to-end delay, SIP, Quality of Service, Security. second feature is particular relevant since data transmission allows rather long transmission delays as long as its content is I. INTRODUCTION accurately analyzed. The VoIP is a high interactive service, where delay and jitter may result in unacceptable voice The convergence of data and voice on a single IP-based quality, significantly hampering its competitiveness with network architecture produces some benefits such as traditional voice communication systems like the Public deployment cost reduction and ease of management. On the Switch Telephone Network (PSTN). contrary, this convergence introduces new security The paper analyzes the VoIP requirements for intrusion vulnerabilities including those common to IP networks. In detection and prevention recommending the usage of a particular, security issues in VoIP (Voice over IP) are different network-based intrusion detection and prevention system and in ways more complex than security for data applications. characterized by the adoption of a two stage technique: first As an example, VoIP is a complex application involving the system applies knowledge-based techniques and then multiple layers of the protocol stack, requiring interoperability behavior-based ones on the packets passing the knowledge- 1-4244-0144-5/06/$20.00 ©2006 IEEE VoIP MaSe 2006 Authorized licensed use limited to: Universidad de Almeria. Downloaded on June 9, 2009 at 13:02 from IEEE Xplore. Restrictions apply.
  2. 2.  based step. The prototype implementation shows a first step or on signature-based detection, also known as behavior-based towards the recommendations implementing a prototype and knowledge-based respectively. Statistical anomaly system which realizes the first of the two steps above cited. detection is based on the observation of a standard behavior The prototype is currently able to analyze the SIP protocol and later used as reference; an alarm is triggered when different not analyzes the RTP protocol. Further extensions of this work patterns deviating from the standard behavior are observed. are required to address the interaction and the attacks dealing Signature-based systems rely on a set of known rules defining with cross-protocol checks. the attack methods; these rules are compared to the observed Since network-based techniques should be implemented in data identifying suspicious traffic. Both techniques have pros devices able to observe the traffic to be analyzed, the system and cons: behavior-based techniques can detect previously should be positioned in the entry point of the SIP network. unknown attack methods but have a higher false-positive rate Therefore the candidate devices for intrusion detection and while knowledge based techniques can detect only known prevention implementation are mainly SIP-aware firewall and attacks but the false-positive rate is much lower. Both gateways protecting the border of a network and Session techniques are, in principle, applicable in real-time. Border Controllers (SBCs); other devices like SIP proxy IDS and IPS mechanisms and systems are necessary tools servers could be used in intrusion detection and prevention but for today’s secure networks and are currently starting being may miss some of the traffic to be observed therefore we implemented and deployed. Anyway the threats to the VoIP regard them as a second choice for the application of intrusion architectures briefly introduced in the previous section also detection and prevention techniques. exploit specific vulnerabilities of the VoIP protocols that are The proposed systems solution has been analyzed both in not currently taken into account by state-of-the-art IDS and terms of ability to discover attacks and to the impact on QoS IPS systems (for a detailed taxonomy of vulnerabilities and experienced by communication traffic. attacks scenarios see [1]). The paper is organised as follows. Section II presents a brief VoIP deployments have peculiarities that need to be description SIP Intrusion Detection and Prevention Systems. analyzed in order to understand which the IDS type that better Section III describes the developed Snort SIP Processor matches the requirements is (as of today there are only few prototype, while Section IV discusses the performance research papers [11] currently addressing the issue and some analysis of the proposed IPS architecture, obtained including books [12]). Actually VoIP deployments are characterized by the developed pre-processor in the basic Snort software. different characteristics with respect to traditional server Finally, Section V summarizes the main results of the paper oriented applications where the security target is only the while delineating next improvements planned. server (e.g. HTTP, FTP, E-MAIL): • a much higher number of systems to be protected (in II. SIP INTRUSION DETECTION AND PREVENTION addition to multiple VoIP servers, e.g. Proxies and An IDS is a system able to detect and log malicious or Gateways, all the terminals are possible objects of suspicious intents. There are three common types of IDS attacks); systems (host-based, network-based and stack-based); these • stricter requirements in terms of security checks (DoS categories are not mutually exclusive and approaches can be attacks are possible in VoIP case without the need of combined one with each other resulting in hybrid systems. In sending high rates of messages, few messages are in order to introduce the requirements in the SIP case a short principle able to cause the devices under attack to crash overview of the three types of IDS is reported here. A host- or reboot). based IDS is running on a single host. The tasks of the host- SIP Intrusion Detection and Prevention requirements are based IDS are mainly to log suspicious and unauthorized therefore better matched if network-based IDS systems are activities and changes to system files and configurations. A used; there is a clear advantage in terms of scalability if IDS network-based IDS captures network packets and inspects systems are implemented using a network-based solution. In them. The packet capture has to be performed on relevant addition host-based solutions are not suited to effectively network segments in order to observe the traffic to be prevent the DoS attacks because of their logging nature (not analyzed. A stack-based IDS is a more recent approach tightly effective in promptly block of the recognized attacks). Stack- integrated into the TCP/IP protocol stack giving the system the based IDs are also suited and can be used in combinations chance to intercept attack packets before they can reach with network-based solutions as long as they are not intended important parts of either the operating system or the to be deployed in a large number of devices. As regards as applications. intrusion detection and prevention techniques both of the two An Intrusion Prevention System (IPS) instead is a system techniques previously cited meet the requirement of being able to take a preemptive approach. In addition to the applicable in real-time. We regard knowledge-based characteristics of an IDS, an IPS also has the ability to take techniques as the first ones to be implemented, given that a immediate action (for example, dropping a packet that was security attack taxonomy and implementation study is regarded to be malicious along with the possible blocking of available (see [1] for more high level details on this). In our all further traffic from that IP address or port). opinion the behavior-based techniques should only be applied As regards as techniques, intrusion detection and prevention on top of knowledge-based techniques once they have filtered techniques are either based on statistical anomaly observation out the malicious packets, this allows to increase the 1-4244-0144-5/06/$20.00 ©2006 IEEE VoIP MaSe 2006 Authorized licensed use limited to: Universidad de Almeria. Downloaded on June 9, 2009 at 13:02 from IEEE Xplore. Restrictions apply.
  3. 3.  scalability of the solution while keeping the advantages of the clarify their scopes: behavior-based techniques. Hence, behavior-based techniques • Packet Capture block: it is the block responsible to should be used to refine the effectiveness of the knowledge- capture the packets and pass them to following blocks, based methods while deploying them in a second stage is a it uses either libpcap or iptables depending on the Snort way of reducing the false-positive rate. mode. Therefore to resume our recommendations for SIP intrusion • Decoder block: it is the block responsible to perform detection and prevention based on our considerations: we the syntax analysis at layer 2, 3 and 4 of the IP packet suggest using network-based intrusion detection and (MAC, IP and TCP/UDP layer). Each header field of prevention systems with a two stage technique (first apply these layers (IP address, TCP/UDP ports, etc.) is knowledge-based techniques and then apply behavior-based inserted by this block in a structure accessible by the techniques on the packets passing the knowledge-based step in following blocks. order to reduce false positives). • Preprocessors block: it is the block where multiple Network-based techniques must be implemented in devices preprocessors can be loaded at boot time to analyze able to observe the traffic to be analyzed; therefore, from a protocols of layers above the TCP/UDP one with SIP application point of view, we regard the entry point of the custom made C/C++ programs. Additional SIP network as the most suited one to implement intrusion preprocessors can be added to this block to perform detection and detection. Therefore the candidate devices for advanced task in addition to the default ones. The intrusion detection and prevention implementation are mainly preprocessors block is a very powerful one since it can SIP-aware firewall and gateways protecting the border of a be used to implement both knowledge and behavior network and Session Border Controllers (SBCs); other devices based intrusion detection and prevention techniques like SIP proxy servers could be used in intrusion detection and (since it works in stateful mode). prevention but may miss some of the traffic to be observed • Detection Engine block: it is the block where signatures therefore we regard them as a second choice for the and rules are checked (signature based detection and application of intrusion detection and prevention techniques. prevention) to analyze protocols of layers above the TCP/UDP one. Additional detection plug-in can be defined to perform advanced task in addition to the default ones. The detection engine block can be used to Output implement only knowledge based intrusion detection and prevention techniques since it relies on rule sets Detection Engine defined before start time. • Output block: it is the block managing the log output. The output log is configurable depending on user Preprocessors needs. Available output logs are text files, databases or user-defined ones. When working in the IDS mode, Snort is able to capture Decoder traffic from the Network Interface Card (NIC) (Packet Capture Block) using the libpcap libraries [3]; while when working in the IPS mode, it is able to act as a transparent bridge routing Packet Capture all the traffic at application level using iptables and the ip_queue module [4]. When using Snort the syntax analysis (parsing) of higher IP packets layers protocols (like SIP or RTP) is not performed in the Decoder block (the syntax analysis stops at TCP/UDP layer). Figure 1- Block scheme of Snort architecture In order to perform syntax analysis and additional security check when using Snort, we developed a SIP preprocessor (placed architecturally in the preprocessor block) implementing additional security checks on the SIP packet. III. SNORT SIP PREPROCESSOR PROTOTYPE A block scheme of our preprocessor is depicted in Figure 2. A prototype of a SIP intrusion detection and prevention The packet is passed to the SIP preprocessor only if system was implemented using the Snort software [2] [13] as predefined configurable conditions on TCP/UDP port numbers basis. Snort is a very popular open-source Network-based are met (e.g. packets sent on port 5060 and 5061) otherwise Intrusion Detection and Prevention System written in C the SIP preprocessor is ignored (from the decoder block the language. packet is passed directly to the Detection Engine block); the We report in Figure 1 the reference architecture of Snort configuration of port numbers is passed to the SIP depicted as a block scheme. preprocessor at startup time from a configuration file. The first Details of the single blocks are reported here to better block the packet encounters in the SIP preprocessor logic is 1-4244-0144-5/06/$20.00 ©2006 IEEE VoIP MaSe 2006 Authorized licensed use limited to: Universidad de Almeria. Downloaded on June 9, 2009 at 13:02 from IEEE Xplore. Restrictions apply.
  4. 4.  again a filter which decides if the packet should be analyzed decrease in performance with respect to the usage of plain by the preprocessor or not (this filter is much more rich in iptables filter rules but we believe this is an unavoidable configurability with respect to the previous one able to filter tradeoff in the case of application layer protocols like SIP on the TCP/UDP port numbers only). where flexibility in defining checks is mandatory if security attacks are to be detected and prevented. The next section details our findings in term of performance evaluation performed on the implemented solution. A related work [7] has also shown performance measurement on top of Snort implementation but they performed test on plain Snort code stressing the system without the additional SIP preprocessor we programmed and that we believe it is mandatory to detect and prevent SIP security attacks. We are therefore interested to show the feasibility of our recommendations and understand what is the performance level achievable by our solution; an additional question we are trying to answer is if this solution could be implemented in IDS/IPS solutions (SME segment is the best target because of the low costs and acceptable performances); we are perfectly Figure 2- Block scheme of SIP preprocessor logic aware that such a solution is not made to be deployed in environments where high performance are mandatory since In addition to the filtering, multiple checks are implemented there hardware-based solutions should be considered as (the SIP library used to analyze the SIP packet is the oSIP [5]) mandatory. in order to distinguish legitimate requests from illegitimate We foresee anyway a topic for further development of our ones: work: a hybrid solution where simple knowledge-based checks • SIP Syntax analysis check: the message is parsed are implemented at OS kernel level (modification to iptables following the SIP rules, such a check is implemented could be considered) while behavior-based techniques could using an oSIP library function (osip_message_parse); be kept in user space because of the flexibility required; we • SIP security analysis check on mandatory fields: the foresee this as a way to improve the performance and the message is analyzed looking for the presence and the scalability of the system. correctness of the SIP mandatory fields and their size (see [6] for more details), moreover a cross check among the Cseq header and the SIP method is performed; • SIP stateful analysis check: a state table is kept in the memory of the SIP preprocessor if the message is an INVITE, an ACK or a BYE, each SIP transaction is kept as a soft state for a configurable amount of time (set at startup time), the check performs a rate limitation on the number of transactions an user can initiate in the time period and perform a stateful analysis to check if SIP requests are following patterns defined in the standards (if a BYE is seen without having seen the related INVITE, etc.). If a check fails an alert is generated (a Snort event producing a log) and, if the “action drop” flag was set at startup time in the configuration file, the packet is dropped; Figure 3- Test-bed architecture our preprocessor is therefore always working IDS and, if configured to do so, as IPS. This preprocessor is therefore able to perform SIP IV. PERFORMANCE E VALUATION knowledge-based checks (SIP syntax analysis, SIP security checks on mandatory fields, SIP pattern analysis) as well as it In order to evaluate the impact on QoS of the proposed IPS incorporates a basis for the behavior-based checks thanks to architecture, the test-bed shown in Figure 3 has been set up. the stateful implementation keeping trace of active The test-bed is composed by a SIP proxy based on SER (Sip transactions. Our prototype implementation is a basis for the Express Router) software running on a HP 9005n notebook. recommendations we gave above of realizing a two steps The SIP soft-phones used during the experiments to produce system (knowledge-based and behavior-based). user traffic, run on two notebooks with Linux O.S., having the We are aware of the increase in complexity and foreseen same characteristics of the SIP proxy device. 1-4244-0144-5/06/$20.00 ©2006 IEEE VoIP MaSe 2006 Authorized licensed use limited to: Universidad de Almeria. Downloaded on June 9, 2009 at 13:02 from IEEE Xplore. Restrictions apply.
  5. 5.  In order to evaluate the end-to-end delay introduced by the 0.0011 IPS operations, the two UAs are synchronized by means of 0.001 GPS systems. In both UAs, the Linux O.S. has been patched using the nano-kernel module that permits to achieve an 0.0009 accuracy gain of the synchronization process of three orders of 0.0008 magnitude with respect to the basic Linux O.S. (see [8]). E[Delay] (sec.) The UAs belong to two different network domains. 0.0007 Between the two domains the IPS prototype based on the 0.0006 proposed architecture is running. 0.0005 The Attacker has been implemented by means of a Linux- based PC running the BRUTE (Browny and RobUst Traffic 0.0004 Engine) traffic generator [9], opportunely modified to generate 0.0003 malformed INVITE messages. The choice of sending INVITE message is just dependent on how we modified the message 0.0002 0 100 200 300 400 500 600 700 800 900 generator; the results shown in Figure 4 are general and not INVITE (mps) depending on the fact that we are sending INVITE messages Figure 4 - Mean end-to-end delay measured for different since the prototype implementation checks in the same way INVITE generation rate each SIP message and not just INVITES. The use of BRUTE tool is related to its precision on the control of frame rate The figure clearly highlights that until the malformed generation. Generate traffic workloads at high rates in a INVITE generation rate is lower than 850 mps, the mean end- reliable manner is a critical task and few tools are available. to-end delay inserted by the IPS prototype is negligible. For BRUTE takes advantage of the Linux kernel potential in order the Attacker generation rate of 860 malformed INVITE per to accurately generate traffic flows up to very high bit-rates. second, the mean end-to-end delay experienced by the UA’s This software is an extensible framework that provides a RTP traffic increases to about 1 ms, which is negligible too. In number of optimized functions that easily allow the all these experimental sessions, no RTP packet losses have implementation of ad-hoc modules for customized traffic been observed. On the contrary for values of generation rates patterns generation. A number of library modules higher than 860 mps, the prototype IPS crashes and no RTP implementing common traffic profiles (like CBR, Poisson packets reach the receiving UA (Snort looses packets since the process and Poissonian Arrival of Burst process) are already ip_queue through which the packets are passed to user space implemented and integrated into the package. Performance of from the iptables becomes full). BRUTE has been compared to several widespread traffic We observed a similar behavior of the curve “mean jitter vs. generators and the comparison results have shown the superior malformed INVITE generation rates”; the mean jitter is very performance of BRUTE in terms of both the achieved negligible when the malformed INVITE generation rate is throughput and the level of bitrate precision, under all possible lower than 860 mps. In particular, for a generation rate of 860 values of the frame size. In the considered scenario, only the IPS can introduces mps, we observed a mean jitter of only 180 µs. Similar results relevant end-to end delay, since the communication is on a are obtained when considering the percentage of packets Fast Ethernet LAN dedicated to the test-bed. experiencing a jitter higher than 50 ms. In this case the The considered performance parameters are the mean end- maximum value has been observed for a malformed INVITE to-end delay, the mean jitter, the percentage of packets generation rate of 860 mps. In particular, we observed that a experiencing a jitter higher than 50 ms, and the lost packet maximum of about 10 packets have experienced a jitter higher ratio introduced by the IPS on the RTP traffic produced by the than 50 ms; this observation has been obtained analysing the UAs. For jitter calculation we used [10] as reference. All these jitter experienced by about 15000 RTP packets. parameters have been measured while the Attacker generated As a conclusion, also the jitter analysis clearly highlights malformed INVITE addressed to the SIP Proxy. Different that the SIP IPS is not adding relevant impairment and measurement sessions have been carried out, using diverse therefore not hampering the QoS experienced by legitimate malformed INVITE generation rates. Each session is about VoIP users while an attack is ongoing, until the rate of the five minutes long. malformed INVITE messages is lower than 860 mps. The mean end-to-end delay experienced by the RTP traffic for the different malformed INVITE generation rates V. CONCLUSIONS AND FUTURE WORK (expressed in messages per second, mps) is shown in Figure 4. In the paper SIP Intrusion Detection and Prevention requirements were analyzed proposing an IDS/IPS architecture specific for VoIP applications. A prototype implementation of the proposed architecture was realized based on Snort software. The prototype is designed in an extensible and general way following the recommendations for VoIP IDS/IPS systems reported in the first sections of the 1-4244-0144-5/06/$20.00 ©2006 IEEE VoIP MaSe 2006 Authorized licensed use limited to: Universidad de Almeria. Downloaded on June 9, 2009 at 13:02 from IEEE Xplore. Restrictions apply.
  6. 6.  paper. This prototype extends the basic functionality of Snort implementing SIP knowledge-based security checks and poses REFERENCES the basis for the implementation of behavior-based ones [1] VOIP Security Alliance (VOIPSA) Security and Privacy thanks to a stateful analysis. Since an important requirement Threat Taxonomy, Public Release 1.0, 24 October 2005 of an IPS is that legitimate traffic should be forwarded to the [2] Snort home page, http://www.snort.org recipient with no apparent disruption or delay of service, the [3] Libpcap home page, performance analysis of the proposed architecture was http://sourceforge.net/projects/libpcap/ evaluated in terms of impact that its operation has on the QoS [4] Netfilter home page, http://www.netfilter.org experienced by the VoIP users over a test-bed. An extension [5] oSIP library home page, of the BRUTE traffic generator was also developed in order to http://www.gnu.org/software/osip/osip.html send malformed SIP messages with precise rates. Our findings [6] J. Rosenberg et al., “SIP: Session Initiation Protocol”, were that, as long as the queue were Snort receives packets IETF RFC 3261, June 2002 from the operating system was not full, our solution did not [7] Network Intrusion and QoS impact within VoIP, Qovia decrease at all the overall QoS experienced by the clients. We technical report, 2004 [8] V. Smotlacha, Measurement of Time Servers, CESNET therefore believe that our extension could constitute a good Tech. Rep. 18/2001, December, 2001 basis for further development of more advanced VoIP IDS/IPS [9] Nicola Bonelli, Stefano Giordano, Gregorio Procissi, solutions. The further steps planned are the investigation of Raffaello Secchi, BRUTE: A High Performance and possible performance improvements by using iptables to pre- Extensibile Traffic Generator, Proc. of International filter packets to be sent to Snort (while the others are only Symposium on Performance of Telecommunication forwarded by the kernel) as well as performing knowledge- Systems (SPECTS'05), July 24-28, 2005, Philadelphia based checks in the kernel space by modification of iptables in (PA), USA order to pass to Snort only the packet to be checked by [10] H. Schulzrine et al., “RTP: A Transport Protocol for behavior-based techniques. More advanced behavior-based Real-Time Applications”, IETF RFC 3550, July 2003 techniques for IDS could be also implemented using our [11] Yu-Sung Wu, Saurabh Bagchi, Sachin Garg, Navjot preprocessor coupled with an additional preprocessor Singh, Tim Tsai, “SCIDIVE: A Stateful and Cross analyzing the RTP flows in order to detect cross-protocol Protocol Intrusion Detection Architecture for Voice- (SIP/RTP) inconsistencies (call fraud) and security attacks. over-IP Environments”, Proc. of International Conference on Dependable Systems and Networks 2004 (DSN'04) VI. ACKNOWLEDGEMENTS [12] J. Ransome, “Voice over Internet Protcol (VoIP) The authors would like to thank Ms. L. Kuhn and Ms. P. Security”, Digital Press, November 2004 Viscarelli which helped in the realization of this work while [13] B. Caswell, G. Ramirez, J. Beale, N. Rathaus, “Nessus, being at University of Applied Science at Yverdon les Bains Snort and Ethereal power tools: customizing open source in Switzerland, at NEC Europe Network Laboratories in security applications”, September 2005 Heidelberg in Germany and at University of Pisa in Italy. 1-4244-0144-5/06/$20.00 ©2006 IEEE VoIP MaSe 2006 Authorized licensed use limited to: Universidad de Almeria. Downloaded on June 9, 2009 at 13:02 from IEEE Xplore. Restrictions apply.