Internet Telephony Testing Network

Transcription

1 Teknillinen Korkeakoulu Teletekniikan laboratorio S Teletekniikan erikoistyö Internet Telephony Testing Network Tekijä: Antti Romppanen 43018c Ohjaaja: Vesa Kosonen Jätetty:

2 Abbreviations B-ISDN ETSI GUI IETF IP ISDN ISUP ITU-T sector IWF LAN MTU NIC PC PCM PSTN RFC RTCP RTP SIP Broadband ISDN European Telecommunications Standardisation Institute Graphical User Interface Internet Engineering Task Force Internet Protocol Integrated Service Digital Network ISDN User Part International Telecommunications Union - Telecommunications Interworking Functions Local Area Network Maximum Transfer Unit Network Interface Card Personal Computer Pulse Code Modulation Public Switched Telephone Network Request For Comments Real-time Transport Control Protocol Real-time Transport Protocol Session Initiation Protocol SS7 Signalling System 7 TCP Transmission Control Protocol II

3 TIPHON Networks UDP VoIP Telecommunications and Internet Protocol Harmonisation Over User Datagram Protocol Voice over IP III

4 Table of contents Abbreviations II Table of contents IV Abstract V 1. Introduction 1 2. Internet telephony Drivers for Internet telephony Internet telephony scenarios Standards related to Internet telephony Internet protocol Transmission Control Protocol User Datagram Protocol Real-time Transport Protocol H Internet telephony gateway 7 3. The testing network Requirements for the network Network plan The gateways The IP network Monitoring tools Setting up the network The gateway setup NISTNET emulator Monitoring tools Conclusion 15 IV

5 Abstract Internet telephony is a concept that unites the telephone network and the Internet. It requires new entities to be introduced to the networks in order to provide interworking between packet switched Internet and circuit switched telephone networks. These new components convert the telephone signalling and speech circuits into IP signalling and packetised speech transfer methods. This special study on telecommunications is a plan and an implementation description for an Internet telephony testing network. The purpose of the network is to provide a platform for evaluating different pieces of network equipment including testing and monitoring equipment. The network is constructed in Nokia laboratory premises in Helsinki. V

6 1. Introduction 1. Introduction Voice over Internet Protocol (VoIP) means transferring of voice traffic over networks utilizing Internet Protocol (IP) as a carrier. VoIP has become a considerable alternative for traditional telephony circuits. Some operators have already switched from Pulse Code Modulated (PCM) circuits to transferring their speech traffic over dedicated IP networks. This gives several advantages over circuit switched connections - and also some disadvantages that have to be dealt with. Internet telephony and VoIP have to some extent existed for some years now. But as main-stream applications they have not yet done well. VoIP has been a means of calling cheap long distance calls with Personal Computers (PC) over the public Internet. This has been enabled by the rapid development of the processing power and multimedia capabilities of PCs. Voice communication over the Internet has been accomplished with different kinds of packet telephony software. These have utilised proprietary methods of transferring voice in IP packets, and therefore the public success has not been met. But now the situation is different. New standards - such as the H.323 protocol family - have enabled software producers to implement packet telephony software that can interwork with software from other producers. Also the introduction of new network components, like Internet telephony gateways, have driven the technology nearer towars a normal private user. This is mostly due to the fact that users are very accustomed to the user interface of a telephone, and the gateways make it possible to make calls over the Internet with telephones connected to the Public Switched Telephone Network (PSTN). When a new technology is introduced to consumers, there has to be a certainty that the service platform and the services are working correctly. This study is about planning and implementing a test network for Internet telephony. The network will be used to gather information about the technology and to test and evaluate different tools that can be used in verifying the services. 1

7 2. Internet telephony 2. Internet telephony 2.1 Drivers for Internet telephony PSTN connections allocate 64kbit/s part of a 2Mbit/s PCM link for speech traffic. This allocation is called a timeslot in the PCM link. The timeslot is allocated for the speech stream for the whole duration of the connection. Therefore the link is utilised even if there is no speech traffic at all. This is considered as waste of bandwidth, because the 64kbit/s connection cannot be teared down and formed again for every speech burst. If the speech was transferred as packets, there would be no such problem. Packets can be multiplexed to the same link and therefore when one connection is silent another one could use its link for transmitting. This allows better utilisation of the link. With speech coding the required bandwidth for speech in the IP network is much less than the 64 kbit/s requirement in PSTN. That is why the 64 kbit/s link would be able to carry several connections even if they would all transmit 100% of their time. This is one the most important drivers for VoIP. Another advantage lies in the harmonisation of different network technologies onto a single platform. If IP is a common carrier for speech and data traffic, the network management can be a simpler task. In practise, however, the new network components introduced by Internet telephony can reduce this simplicity advantage. IP is seen as a common convergence layer for all traffic - in some ways similarly to Broadband Integrated Services Digital Network (B-ISDN) that was dreamed about a few years ago. The charging mode of Internet traffic helps in bringing more affordable services to end-users. Internet is charged according to the duration of the connection or according to the amount of packets exchanged. The distance that the packets are sent to is not conclusive, which makes long distance connections very costeffective. 2

8 2. Internet telephony 2.2 Internet telephony scenarios The major standard setting organisations in the telephone world are European Telecommunications Standardisation Institute (ETSI) and International Telecommunications Union - Telecommunications sector (ITU-T). ETSI has established a project called Telecommunications and Internet Protocol Harmonisation Over Networks (TIPHON) that has defined many things concerning Internet telephony. Many other definitions and recommendations have risen from the side of the Internet standardisation. The main Internet standard setting organisation is Internet Engineering Task Force (IETF), which has many groups that concentrate on Internet telephony issues. TIPHON has defined five architectural scenarios for Internet telephony connections. These are presented in Figures [1] IP IP Figure 1-1 Call over IP network PSTN IWF IP Figure 1-2 Call from PSTN to IP network and vice versa 3

9 2. Internet telephony PSTN IWF IP IWF PSTN Figure 1-3 Call from PSTN to PSTN over IP network IP IWF PSTN IWF IP Figure 1-4 Call from IP to IP over PSTN The IWF stands for Interworking functions. An example of these is an IP telephony gateway that converts PSTN connections to IP mode of networking. Another one is a gatekeeper. Gatekeeper is a component that provides authorisation, registration and address translation services for hosts and gateways. This study aims to implement a network that can be used for scenarios in Figures 1-1, 1-2 and 1-3. They are the most interesting ones when thinking about real world applications for Internet telephony. 4

10 2. Internet telephony 2.3 Standards related to Internet telephony This chapter is a short introduction of the standards that are related to IP telephony. Fist the network and transmission protocols are presented and then the interworking protocols Internet protocol IP is defined by the Request For Comments (RFC) 791. It is designed to be used in interconnecting networks. It defines the packet format and addressing and supports methods for segmentation of information to provide compatibility for networks with small Maximum Transfer Units (MTUs). IP does not provide mechanisms to augment end-to-end data reliability, flow control, sequencing, or other services commonly found in host-to-host protocols. IP version 4 header contains a 32bit address space that is divided to a network part and a host identity. The length of the network part depends on the class of the particular network. In IP version 6 the addresses are 128 bits long. [2] Transmission Control Protocol Transmission Control Protocol (TCP) is the most well-known transport protocol used together with IP. IP provides network level services for TCP, which takes care of the connection setup and teardown as well as the reliability of the transportation. [3] TCP uses sequence numbers and acknowledging to achieve a reliable transport system. TCP also performs some flow control operations. These and the retransmit system are the reasons why TCP is great for reliable transportation - but useless for real-time traffic. In Internet telephony applications TCP can only be used for signalling transportation. For speech transportation its flown control methods and re-transmission do not fullfill the necessary latency requirements. [3] 5

11 2. Internet telephony User Datagram Protocol User Datagram Protocol (UDP) is an unreliable transport protocol, which is an alternative for TCP. UDP does not do anything to secure the transmission - it only provides a similar best effort datagram service as IP. This also means that UDP is not restricted in the same way as TCP. UDP does not perform flow control, and therefore it is better suited for transferring speech traffic. UDP does not detect any missing or reordered packets and does not do any re-transmissions. This is perfectly acceptable with voice traffic, because when the re-transmitted packet would reach the destination, it would already be too late.[4] Real-time Transport Protocol Real-time Transport Protocol (RTP) is well-suited to be a supplement to UDP. When run on top of UDP it can provide important services for applications such as audio, video or simulation data. RTP provides information about the real-time traffic in the form of time stamping. RTP can be modified to meet the requirements of an application. Real-time Transport Control Protocol (RTCP) is a supplement to RTP that provides monitoring information about RTP traffic.[5] H.323 H.323 is an umbrella standard by ITU-T. Umbrella means that it references many other standards and provides as itself only a framework for the standards application. H.323 defines everything that is needed for providing audiovisual services in packet-based multimedia communication systems where service is not guaranteed. [6] Call control in H.323 is defined in H This standard defines signalling very close to Q.931 signalling used in Integrated Services Digital Network (ISDN). H.245 is protocol for negotiating the applicable speech codecs and other parameters between the H.323 nodes. H.248 is a protocol that can be used to control an external media gateway. This allows the separation of signalling and speech media. H.323 defines also many other things, such as the speech and video codecs and data transfer methods. [6] 6

12 2. Internet telephony 2.4 Internet telephony gateway As mentioned earlier Internet telephony gateway is a network component providing conversion of connections from PSTN to IP and vice versa. There are several functions that a gateway must perform. First it must have a PSTN interface that terminates or initiates PSTN connections. This interface can be for example ISDN primary rate or Signalling System 7 (SS7) interface such as ISDN User Part (ISUP). The PSTN signalling can be converted to H.323 or another emerging alternative, such as Session Initiation Protocol (SIP). The speech path in PSTN is coded with companded PCM, which can be used as such in IP network. This speech codec is called G.711. If the telephony interface is a mobile connection, the codec used is commonly GSM full rate. If the speech is wanted to be transcoded with another codec, the gateway performs the transcoding. Popular alternatives for G.711 are for example G and G.729, which compress the voice to about one tenth of the original G.711 stream. Next the coded voice is transferred across the IP interface packed in RTP streams. If a gatekeeper is used, there has to exist dialog between the gateway and the gatekeeper to get access to network resources and to perform the address translation from E.164 numbers in PSTN to IP addresses. In the receiving gateway the signalling is terminated and the speech packets are buffered. Buffering is conducted to even the irregular transmission times that have taken place in the IP network. From the buffer the speech packets are again converted to PCM voice, and PSTN signalling procedures are initiated to make the connection to the end node in PSTN. 7

13 3. The testing network 3. The testing network This chapter describes the requirements, planning and implementation of the testing network. 3.1 Requirements for the network The main requirements for the testing network were that the components should be affordable and the network should be able to implement the scenarios in Figures The network should be able to have variable IP characteristics. This means that there should be a way to control the load in IP network. Also monitoring of the protocols used in interworking between PSTN and IP should be possible. 3.2 Network plan The whole testing network plan is realised in Appendix A The gateways The fist step in planning the network was selecting the gateways for the network. After reviewing several candidates the target was set for Natural Microsystems Fusion platform. Fusion is used on Windows NT operating system. The system consists of a PCI card with 4 E1 links. E1 is an European standard for connecting 2Mbit/s PCM links. Fusion supports ISDN primary rate connections on the telephony interface. The selected version was an AG4000 card, which supported up to 30 simultaneous H.323 calls. With an additional processing board the capacity would have risen to 120 connections. However, in our testing network there was no need for larger capacity. [7] The system utilises the PC s Ethernet Network Interface Card (NIC) in communicating with the IP network. This configuration is called "Host Based Fusion". The gateway is not a real gateway product. Instead, it is a platform for developing gateway applications. There was, however, a sample gateway application provided with the board. This application contained all the necessary functions to run an Internet telephony gateway. 8

14 3. The testing network Our testing network required two gateways. Therefore two Fusion boards with appropriate software, protocol stacks and licences were needed The IP network The IP network part in our testing system should be able to emulate different characteristics of real world networks. Therefore it was clear that either some device that would be able to load the network would needed, or the load should be emulated. It was decided that network emulation would give us more liberty in configuring the network. After searching for usable IP network emulator, the NISTNET package for Linux operating system became a clear choice. The Linux operating system is free for use, as well as the NISTNET software. Therefore the requirement for affordable components was well met. NISTNET is able to emulate network delay, delay variation (jitter), packet loss and packet duplication. For NISTNET to be able to manipulate IP packets it has to be run in a machine that is configured as a router. Linux has good support for routing built into the operating system, and that made the choice even easier. [9] Monitoring tools Network monitoring was also one of the main requirements for the testing environment. There are many software based monitors for different protocols. These were naturally more appealing than more expensive systems requiring hardware support. For Linux there exists many monitoring programs that are free for use. In Linux router these would work just fine. The Linux operating system contains basic monitoring tools, such as TCP Dump. This is however very basic, and more advanced programs can be downloaded from the Internet. IPGrab is a good example of a simple, but very usable monitoring program for linux. It decodes many fields open from the IP datagrams. [9] For Windows NT IP telephony gateway machines an H.323 monitor was hoped for. One good candidate was found from a company called TTC. The Fireberd DNA H.323 monitoring software monitors many signalling protocols under the H.323 umbrella, and provides a nice Graphical User Interface (GUI) for message decoding. The software is free for evaluation for 45 days. [10] 9

15 3. The testing network 3.3 Setting up the network The gateway setup The network setup was begun with the gateways. The installation of the boards itself was straightforward thanks to the PCI bus interface, which helps a lot in setting up the interrupts and memory addresses for the board. The drivers and gateway application were not so easy to install. The drivers required a lot of configuration and overally they did not leave a very professional image. The gateway application was provided as source code only. The compilation to an executable application required Microsoft Visual C++ software and some configuring. When all the necessary software, including several codecs and H.323 stack by RadCom were installed, the system was ready for first testing. The gateway sample application desktop view is seen in Figure 3-1. Figure 3-1 Gateway application 10

16 3. The testing network As mentioned earlier the gateway used the PC s NIC card in connecting to the Local Area Network (LAN). The PSTN ISDN primary rate interface was connected to a Nokia DX220 telephony switch. Analog and ISDN basic rate subscribers were connected to DX220. With the subscriber interfaces it was possible to make calls that were routed to the ISDN primary rate route. The subscriber database of the gateway application was implemented with one simple text file. The database contained entries in the form:"880000, ,ptop,880000". This is translated as a call from number is routed to IP address The connection is from PSTN to PSTN and the number to call in the terminating gateway is This is a very simple subscriber database, but it is usable in our testing environment. The database contained different mode identifiers for pure IP calls and calls from IP network to PSTN and vice versa. In all cases the entry format was similar. After connecting the IP interfaces to an Ethernet switch first test calls could be made. The gateway required, that in PSTN to PSTN connections it had to receive all digits of a telephone number at once. Thus it did not support overlap sending of digits, and the switch had to be configured to so called En-block mode, where the whole E.164 called party number is transmitted in SETUP message. Soon it was found out, that the gateway worked fine except for the G.729 codec, which did not produce any traffic on the speech path. Next it was time to try a call between a H.323 and a PSTN client. The H.323 client that was used was Microsoft NetMeeting softeware on Windows NT machine connected to the Ethernet switch. The software was configured to use one of the H.323 gateways as its IP telephony gateway. Then a call could be made to PSTN - if the address entry was in the gateway s subscriber database. Besides some problems with echo from the PC s speakers to the microphone, the connection worked properly. The NetMeeting software did not seem very stable - it produced some freezes of the whole NT operating system. Now the IP telephony gateway system was operational, and it was time to set up the router and the emulation software. 11

17 3. The testing network NISTNET emulator Linux version used was Red Hat 5.2 distribution. Newer versions of Red Hat exist, but the compability of NISTNET is guaranteed only with certain older versions of the Linux kernel. Linux kernel had to be re-compiled to enable support for IP packet forwarding. Kernel compilation is documented in Linux How-to documents[11]. Kernel options that were needed in the compilation were: Prompt for development and/or incomplete drivers Enable loadable module support Networking support Network firewalls TCP/IP networking IP: forwarding/gatewaying IP: Firewalling IP: Masquerading IP: ipautofw masquerade support IP: ICMP masquerading IP: Always defragment Dummy net driver support After the kernel had been compiled and the new kernel made active, next thing to do was to configure the Ethernet cards. Two Ethernet cards were needed in the router machine to support two subnetwork interfaces. The Network Interface Cards (NIC) were 3COM 509 ISA-bus cards. Because the cards used ISA-bus, there were some incompatibility problems. One of the cards had to be programmed with an application provided by the manufacturer s support pages to use another interrupt and different memory area. After this alteration the system recognized the cards. 12

18 3. The testing network The cards were configured so that one of them had subnet and the other one The IP addresses of the cards were and respectively. The netmask for both cards was set to be The cabling had to be modified to support direct connections from the gateway machine s NIC to router machine s NIC. Following connections had to be made: [11] RJ45 Plug 1 Tx Rx+ 3 RJ45 Plug 2 Tx Rx- 6 3 Rx Tx+ 1 6 Rx Tx- 2 Figure 3-2 Crossover cabling NISTNET software installation was well documented in the package. First some kernel patches were installed, and then the actual application was compiled. The application is loaded to the kernel as a loadable module. This means that first a module is installed and then the application is started. The user interface in NISTNET is graphical. It contains entries for packet sources and destinations, as well as for the desired network characteristics. The possible characteristics that are adjustable are network delays, delay variation, packet loss percent, packet duplication percent and available bandwidth. NISTNET only handles those packets that the source and destination addresses define. With Ping tool it was possible to check the correct operation of NISTNET. Pinging showed that the packets indeed were delayed and duplicated etc. according to the settings. Pinging from the gateway machines also indicated that the router machine was routing packets correctly. 13

19 3. The testing network When the gateways and the router had been connected, first test calls through the emulated network could be made. It was soon found out, that the differences in voice were easy to spot, when the simulator introduced some IP inefficiencies to the network Installing monitoring tools The Windows NT Fireberd H.323 monitor was easy to install. Setup program was provided in the installation package, and the installation went without a hitch. The software is an off-line monitoring tool. This means that it records the signalling from the NIC and decodes it off-line. The software decodes H.225, H.245, Q.931, RAS, RTP, and RTCP protocols. A view of decoded H.323 messages can be seen in Appendix A. The linux network monitor IPGrab was a little harder to install. It required installation of libpcap library, before its installation could be started [13]. After compiling both the library and the application ipgrab worked perfectly. It decodes packets and frames for numerous protocols, such as IP, TCP, UDP, Address Resolution Protocol (ARP) and Ethernet. It is an on-line decoder, and it was able to decode large streams of packets without any slowdowns. 14

20 4. Conclusion 4. Conclusion The testing network worked properly. All the components achieved to fullfill the requirements set for them. Especially the NISTNET software proved to be an invaluable tool. With NISTNET emulation of large networks is possible, after you know the network characteristics. These characteristics can be found out for example by pinging network servers so much that statistics can be collected. Then the values can just be set to the simulator and the network is ready to be used in testing. Linux itself was a good platform for performing network tests. The router support in Linux worked fine, and the performance of the Linux router was very good. Linux also provided a stable working environment, and support was easy to find from the Internet. The free-of-charge idealism in Linux world is a great advantage. Software, such as IPGrab, can be really valuable in many applications, and further development of applications is easy thanks to the source code delivered with the packages. The gateways performed acceptably. The gateway application was adequate for small scale evaluation purposes. But as a private branch exchange it would not be powerful enough. The source code of all the gateway software was included in the package. This was of course a good thing for development of own applications. However, we did not have the resources required to study the software further. All in all the testing network worked fine, and it will be used for further evaluation and educational purposes. 15

21 References References [1] European Telecommunications Standards Institute, TR , Telecommunications and Internet Protocol Harmonization Over Network (TIPHON), Description of technical issues, 1999 [2] Defense Advanced Research Projects Agency, Internet Protocol Spefication, RFC 791, 1981 [3] Defense Advanced Research Projects Agency, Transmission Control Protocol Specification, RFC 793, 1981 [4] Postel J., User Datagram Protocol, RFC 768, USC/Information Sciences Institute, 1980 [5] Schulzrinne H., Casner S., Frederick R., Jacobson V., Network Working Group, RTP: A Transport Protocol for Real-Time Applications, RFC 1889, 1996 [6] Telecommunication standardisation sector of ITU, Packet-based multimedia communications systems, H.323, 1998 [7] Natural Microsystems, AG4000 board homepage, [8] NISTNET homepage, [9] IPGrab, [10] TTC, Fireberd DNA H.323 analysator homepage, [11] Linux Kernel How-To, HOWTO.html, 1999 [12] Data Cabling FAQ, [13] Libpcap library, ftp://ftp.ee.lbl.gov/libpcap.tar.z,

22 Appendix A Testing network Analog subscribers DX220 E1 - ISDN Primary rate E1 - ISDN Primary rate Gateway with NetMeeting 10Base T Ethernet ( ) 10Base T Ethernet ( ) Router and NISTNET simulator with IPGrab software 17

23 Appendix B: View of the H.323 monitoring software