This Masters Thesis is about how to gather information from IP telephony signaling and use this information to get statistics about calls and to configure measurements of these IP telephony calls data traffic. To measure the traffic a traffic flow meter called NeTraMet was used.
A laboratory test bed has been configured in order to development a measurement prototype. An IP telephony server was set up, different IP telephony traffic scenarios was run and the traffic from these was investigated with the help of a so called sniffer and protocol analyzer. The necessary information needed to configure and start the measurements of the calls data traffic was studied and decided.. In the SIP messages that were sent, there was information about what parties was involved in the call plus information about the media that was used and on what port the media was sent. By looking at the status messages that are sent, it.s also possible to get information if a call can.t be connected etc. and why.
The flow meter NeTraMet and different methods to generate the monitoring packets were tested. The monitoring packets were implemented by using the program ngen to generate packets from one client to the echo port of the other client.
A prototype was implemented in Perl to gather information from the SIP messages, configure and start the measurements. This prototype exists in two versions: one client version where the IP telephony client that started the call administrated the measurements and a server version where the SIP proxy administrates it. When the server version is used the SIP proxy must be set as record-route to make all the SIP messages pass through the proxy.
To test the prototype some measurements of IP telephony calls was done between two computers, one in Haninge and the other in Karlskrona. In the measurements information about delays, processing times in the destination node, delay variations and throughput was computed. Then it comes to the processing time, this time has a big impact on the delay of the packets, this probably because that the port that the monitoring packets was sent towards have a lower priority in the computer system. The throughput did not vary a lot, since the RTP traffic is sent at a constant speed.