RSS
| IP Telephony in CZECH EDU |
 |
 |
 |
|
Autorem článku je: Miroslav Voznak, CESNET Prague, voznak at cesnet dot cz Abstract We will describe the most considerable VoIP implementations at Czech universities. In Czech EDU, IP telephony appears with the following features:
At first, we provide an brief overview of scenarios used. The motivation for deploying each scenario derives from user needs but what is the rationale behind implementing VoIP? We see two basic rationales:
University of West Bohemia (UWB) UWB is a university located in Pilsen. Its IP telephony is based on the openSER open-source solution and they are using an interesting auto-configuration system (AS). AS enables an automated installation of certain types of Linksys IP phones. It allows multiple phones to be installed without taking up administrators' time usually required to install such phones. The whole Auto-configuration System cooperates with an OpenSER which uses a MySQL database to store its configuration. Once the administrator submits a registration form, the registration systems creates the requested user account in the MySQL database and generates a specific configuration file using a template containing the complete configuration information for an IP phone. The configurations are distributed through TFTP protocol and are downloaded by IP phones when they start up for the first time. Very interesting technical reports were released in the framework of CESNET activity. These reports are by Michal Petrovic from UWB.
This new solution for IP telephony is based on Linux SIP server with openSER and RTP Proxy. Two identical SIP servers in redundancy mode ensure high availability, one is active and the other one in standby, the redundancy feature is controlled by HSRP protocol. Every server is equipped with two HDD in RAID1, and they are located in separate buildings and designed for 15 000 users. This solution enables a gradual migration from current Siemens hipath 4000 PBX to openSER. The new IP telephony infrastructure with openSER is built as parallel to legacy PBX. Original university telephony network consists of nine PBX Siemens hipath 4000 interconnected through H.323 with central Gatekeeper Siemens hipath 5000. The network management supports not only the mentioned migration from Siemens hipath to OpenSER but also IP telephony provisioning that is described in separate chapter.
Telco providers are connected to VoIP Gateways (voip-gw1 and voip-gw2) through ISDN, see the figure above, the main DDI is +420 37763 + four digits extensions. Incoming calls are handled by Voice Gateways (Cisco 2851) and forwarded to the appropriate telephone system, either to OpenSER or Siemens hipath. Outgoing traffic is routed through the Voice Gateways to PSTN. Individual gateways are selected based on the least cost routing principle.
SIP server and Voice gateway are the key elements of the presented solution. OpenSER SIP server is a project spawned from SIP Express Router (SER). It has recently forked into two projects, Kamailio and OpenSIPS. The extent of the features is generally defined by the OpenSER - Kamalio every configuration of openSER is unique and the system can be customized to fulfil any expectation. We briefly summarise the features in this list:
The provisioning system at this university allows an automated configuration and installation of certain types of 9xx range IP phones by Linksys (SPA921,SPA922,SPA941,SPA942,SPA962). The system consists of several parts:
The System relies on information entered into the Web Interface consisting of a simple form used to register users and generate configuration files to be stored on the TFTP server. Once the registration form is filled in, the Web Interface also submits a request for an IP address and a domain name to the Request Tracker. Subsequently, appropriate records are created in DHCP and DNS. The IP phone can be connected to the network after the message “registration is successful” was sent to user.
The key component of the presented provisioning system is the Web administration. Before an IP phone is connected, the administrator has to specify the user's login name. This login is checked against the university information system to get important information for automatic configuration. A simple form follows with most fields pre-filled with information acquired from the LDAP server based on the login name provided earlier. The Administrator actually only needs to fill in the passwords for the user's SIP account. MAC addresses have to be specified for hardware phones, SW IP phones do not require that. Other fields are optional, however it is advisable to fill them in since they provide references to other information systems. These include records such as IP Phone serial number, domain name (hostname), inventory number, or user permission settings. SIP Passwords are generated automatically since they are only used to configure the IP phones and users do not need to know them. Besides that, the IP phone MAC address and serial number can be now filled in semi-automatically using a bar code scanner. This minimizes the risk of typing errors. All Linksys phones carry appropriate bar codes printed on the outside of their packaging so that it is not even necessary to unwrap them.
Every IP Phone must be registered in DHCP and DNS services to obtain IP address automatically. The presented provisioning system relies on DHCP records extended with optional attributes. The number of the relevant attribute is 66 “tftp-server-name” and it contains the IP address of a TFTP server. For example, using the dhcpd.conf configuration file in Linux, the appropriate record looks like this:
The TFTP Server needs to be set up to listen to and receive data on UDP port 69. The root TFTP directory contains the initial configuration file used to instruct each IP phone to download its specific configuration. The initial configuration file's name follows the spa.cfg pattern (for example, Linksys SPA922 would require a file named spa922.cfg). IP phones select their specific configurations referring to MAC addresses stored in the $MA format. For example, a specific configuration for a phone whose MAC address is 001122334455 will be found in a file named spa001122334455.cfg, which is referred to in the initial configuration file as /spa$MA.cfg. Other formats may also be used to store MAC addresses. For example, referring the phone to /spa$MAC.cfg will make it look for a file named spa00:11:22:33:44:55.cfg. The contents of the initial file:
The provisioning system cooperates with OpenSER 1.3 using a MySQL database to store its configuration. Once the administrator submits a registration form, the registration systems creates the requested user account in the MySQL database and generates the specific configuration file. User-specific configuration files are generated using a template containing the complete configuration information for an IP phone. The generator simply adds user-related data and stores the resulting XML under the appropriate name. The submitting requests are sent to Request Tracker, DNS and DHCP administrators process such requests and provide DHCP configurations assigning the given IP addresses to phones depending on their MAC addresses. Registration also involves DNS records, which allow the IP addresses to be translated into domain names. When generating requests, newly registered users are given as requesters, which allows them to be notified once the requests for DNS and DHCP registration have been processed.
An automatic attendant allows callers to be automatically transferred to an extension without the intervention of an operator (typically a receptionist). Department of cybernetics of West Bohemia University applied their own speech recognition algorithms (ASR) to ensure that the called person is recognised and the call transferred to the called party. The automatic attendant at this university is a result of long-term research. The first version was developed in 2003. In addition to ASR technology, the automatic attendant involves using dialogue system based on VoiceXML, Oracle database and text to speech (TTS) technology. The SIP interoperability of automatic attendant is ensured by PJSIP open-source client library, the library is multi-platform and enables to include Asterisk in the overall solution.
Asterisk enables to greet the caller and to replay an announcement. In case the caller is waiting in a call queue, the Asterisk informs him about his position in the queue and finally asks to enter a name of the called person. The task of auto-attendant is to analyse the speech data, to look the record up in the database and to ensure that the call is transferred to the called party. Auto-attendant at West Bohemia University was launched in 2008 and nowadays is able to handle four calls simultaneously.
Czech Technical University in Prague (CTU) CTU has been using a solution based on Cisco Call Manager (CCM) as an extension of current PBX (Ericsson MD110). Unfortunately, this solution is based on the SCCP proprietary protocol defined by Cisco Systems (originally developed by Selsius Corporation). Besides CCM, this university provides voice services for other CESNET members (more than 20) and this solution is based on H.323. This project began ten years ago and within five years nearly all universities had become involved in it. Every CESNET member owns a PBX which can be equipped with a Voice Gateway (VoGW). This VoGW is registered with Gatekeeper and outbound calls to PSTN are routed through VoGW at CTU. CTU makes out the invoices for voice services. The billing system is fed call detail records (CDR's) from every single gateway through RADIUS protocol, CDR's are stored in Postgree SQL database.
In 1999, CESNET launched a project offering voice services based on h323 for universities in the Czech Republic. Every member could connect PBX via Voice gateway to the CESNET network and CESNET provided the key elements including gatekeepers. Two gatekeepers ensured the routing between universities and one gatekeeper offered peering to next NREN's and foreign R&E institutions, calls within this infrastructure were free of charge. The infrastructure was gradually extended by additional gateways and in 2001, it was interconnected to a commercial telecommunications operator. The technical solution of the interconnection to a public telephony network required no investments by CESNET2 (connected through the NIX.CZ exchange point). In the same year, the pilot project for calling into the public network was launched and since January 2002, the access to PSTN has been offered as a service to other members involved in the IP telephony project. Nearly all universities joined in this project and about 40 PBX's connected through gateways were registered in 2005. More than 1.5 million voice calls through the CESNET2 network were carried out, with total duration of 4.5 million minutes a year. It was decided to move the paid voice services (peering to PSTN) to another institution because the CESNET's legal status did not allow for providing the services which are commonly available on the market and many IP telephony providers have arisen at that time. Since 2006, Czech Technical University has been providing the voice services with peering to PSTN.
The infrastructure is natively based on h323 because its design dates back to 1999. Nowadays, there are gateways without appropriate support - widely used SIP protocol. SIP elements have been fully supported by CESNET during the last five years and cooperation with h323 VoIP infrastructure is realised through SIP/H.323 gateways based on Cisco IP2IP located at CESNET. Certain equipment is able to support both protocols, e.g. Asterisk can serves as SIP/H.323 gateway too.
Provision of paid services needs an application enabling administering tariff tables and accounting for calls made by a particular entity. Czech Technical University operates TAS-IP IP telephony accounting application based on data collected from voice gateways which send information about individual calls through the RADIUS protocol.
TAS-IP enables generating both call detail reports and summary reports. Invoices are sent to individual institutions, the calls performed between universities within the CESNET network are free of charge and calls to PSTN are processed by the TAS-IP billing engine which rates and bills.
Through RADIUS, CTU collects not only information for billing but also data about the quality of individual calls. Records are imported into an SQL database which serves as the data resource for own evaluation of the web interface. Cisco gateways evaluates sent Icpif value (Calculated Planning Impairment Factor) calculating estimated speech quality. This speech quality monitoring system is described in Technical Report 18/2006.
CESNET has been focusing on IP telephony for a considerable period of time.. The activity IP telephony in its research plan was established in 1999, in the first period this activity aimed at implementing H.323, later SIP infrastructure have been built up as a parallel to H.323 with translation gateways based on Cisco IP2IP and Asterisk (oh323 channel). Nowadays, advanced services have been implemented. Following technical reports regarding CESNET IP telephony were published in the last couple of years:
SIP Proxy is the key element of every SIP infrastructure. SIP Proxy at CESNET is powered by SIP Express Router (SER). SER provides functionality of REGISTRAR and PROXY server. SIP clients can register with REGISTRAR and communicate through PROXY, the routing is based on a dedicated number prefixes which are assigned to individual institutions within CESNET. We did not compose a new numbering plan but we adopted the well-known public telephone numbering plan ITU-T E.164. Almost every phone at any Czech university is available at the same number both within the CESNET network and through PSTN. Where it is not possible to communicate with a particular Voice gateway on SIP, then the call is routed through SIP/H.323 gateway. SIP Proxy also handles entire incoming SIP traffic and certain outgoing traffic to other SIP domains such as iptel.org or bts.sk.
The H.323 calls initiated from gateways and from H.323 IP clients are routed through SIP/H.323 gateway based on Cisco IP2IP IOS. CESNET SIP Proxy operates in a multidomain mode. It means that CESNET SER, in addition to its native domain cesnet.cz, is able to handle also other domains of particular universities. Nowadays, CESNET SIP server handles the following domains:
Since 2004, CESNET owns a range of public telephone numbers.The Czech Telecommunication Office assigned an access prefix 950 0 to CESNET, which in the nine-digits national numbering scheme it represents one hundred thousand numbers. These numbers can be used as non-geographical numbers. It means there are suitable for IP phones and for this purpose, an account can be created for any staff at Czech universities. An account is registered at SerWeb (SIP Express Router Web interface). The new requests are authenticated through the Czech academic identity federation eduID.cz. This federation provides an inter-organizational identity management and access control to network services. The eduID.cz federation is operated by CESNET.
The users registered at CESNET SER are available at SIP URI with username or telephone number and relevant domain. The telephone number is assigned when the account is created.
An user, who is registered in cesnet.cz domain with username miroslav.voznak and alias 950072003 is available under: miroslav.voznak (within CESNET) SIP URI sip:
Táto e-mailová adresa je chránená pred spambotmi. Ak ju chcete vidieť, je potrebné aby ste mali zapnutý JavaScript.
420950079999
CESNET SIP server provides peering with several VoIP operators in Czech Republic, the calls are free of charge. These operators are listed below: VoIPex
In addition to access prefix +420 950 0, more then forty PBX's behind Voice gateways are available through CESNET SIP Proxy. The list is provided below: Czech Technical University and CESNET, Prague - 224 35x xxx
CESNET was very active while ENUM was tested in the Czech Republic. It ensured delegation of appropriate NAPTR records for almost all Cczech universities. We recommend to verify the availability of particular numbers.
Czech ENUM was fully released in 2007, delegation of ENUM 420 prefix was made in 2003 and CZ NIC is the holder of 0.2.4.e164.arpa. CESNET DNS answered the query above and offered both SIP and H.323 service.
In spite of the fact that an ENUM record exists, it does not mean that it is available. In this case, CESNET ENUM monitoring system seems to be useful. Monitoring of ENUM records is based on NAGIOS with check_enum module (plugin) created in PERL. Every prefix is tested using the following procedure:
If the status returned is WARNING or CRITICAL, the supervisor is informed by email and can subsequently easily find out the reason of fault on the ENUM monitoring web.
VSB-Technical University of Ostrava (VSB-TUO) VSB-TUO is the third biggest university located in north-east of the Czech Republic. Its IP telephony services are based on two technologies, either on proprietary Hipath technology delivered by Siemens and or on open-source Asterisk. The second one is interesting because its implementation offers many options, e.g. the help-desk of CIT (Centre for Information Technology): the agents of help-desk can log on the call centre based on Asterisk, callers get voice announcement and music on hold while searching for a free agent, if nobody is able to answer the call, another announcement is replayed and the caller can leave a message which is delivered in mp3 format to the helpdesk's email address. They focus on Spam over Internet Telephony (SPIT) as a real threat for the future. They have developed both a tool generating SPIT attacks and AntiSPIT tool defending communication systems against SPIT attacks. AntiSPIT represents an effective protection based on statistical blacklist and works without participation of the called party which is its significant advantage.
SPITFFILE puts much emphasis on the simplicity of using and generating SPIT attacks. SPITFILE was programmed in Python using wxPython GUI and the objective of the designed application is to generate phone calls and to replay a pre-recorded voice message. We adopted the SIPp application which focuses on testing and simulating SIP calls in VoIP infrastructure. SIPp is a open-source test tool or traffic generator for the SIP protocol and can read custom XML scenario files describing from very simple to complex call flows and also send media traffic through RTP. SPITFILE implements a graphic interface for SIPp and works with ready-made .xml diagrams. Thus, the simulation of a SPIT attack is much simpler. Its control is very intuitive – the requested values are submitted into relevant fields and the SPIT attack is launched by clicking the SEND button. SPITFILE is available both for Linux and for MS Windows. SPITFILE can generate spam in two modes.
Before SPITFILE can be opened, preconfigured .xml diagrams should be imported into /etc/ directory. Afterwards we can launch SPITFILE and choose one of the two above mentioned attacks that we want to carry out. To run SPITFILE, just type the following command to the terminal:
We designed and created our own security application model based on a blacklist which would provide an efficient defence against SPIT. We called the new application AntiSPIT.
AntiSPIT is able to analyse and process input data from Call Detail Records (CDR’s) and consequently determine whether the used source will be inserted into a blacklist. CDR's are an integral part of every PBX and it was decided to implement AntiSPIT also into Asterisk PBX. The application gives an output which is inserted as a command which can control the blacklist. Asterisk provides CLI interface enabling us to create or delete the particular records in the blacklist database. The call duration from CDR’s is monitored and if the call duration is less than a certain interval (duration), the source of the calls will receive the status of a suspicious caller and a record with rating is created. In the case of repeated suspicious behaviour the rating will be increased. The maximum achieved rating factor represents a threshold limit value that makes a decision about whether the record is put into a blacklist table. AntiSPIT has been created in LAMP environment and offers user-friendly administration through a web front-end enabling a user to set the key parameters such as length of call interval (duration), maximum achieved rating factor (max rating), ban time (time). The web front-end also enables monitoring and the management of both SCT table and BLT table.
The AntiSPIT can be downloaded and freely distributed under the GPL. The CESNET technical report TR 8/2009 deals with security risks in IP telephony, both SPITFILE and ANTISPITE are described in this TR.
Ostravian University (OU) provides IP telephony for their employees with its own developed user-friendly web interface POSERA (PHP OpenSER Administrator). POSERA was implemented in PHP and enables to set up user accounts in OpenSER through the web (HTTPS). The users are verified through LDAP in a corporate directory and then can fill in a form and the new account in OpenSER is created after confirmation. POSERA enables not only creating SIP accounts but also their administration, such as administration of personal information or displaying missed calls.
Topology at OU is not simple, there is a legacy PBX Siemens Hicom300, Cisco Call Manager and OpenSER, Cisco gateways provide the communication between IP and PBX. OU's SIP server was installed in the XEN virtual environment at CentOS. The RTP traffic is routed through the RTP Proxy and it communicates with MySQL DB. OpenSER supports ENUM lookup at OU, the following SRV records are stated in OU's DNS.
The basic OpenSER configuration was created in user-friendly generator SIP wizard. Compared to the default generated in SIP wizard, some changes to the configuration were made. The missed calls are stored in a missed_calls table.
The default 'base-route-invite' configurationdefinining how to handle requests from the Internet enables accepting only requests from pre-defined IP addresses. This behaviour was changed.
The default 'normalize-e164'configuration in SIP wizard is defined to work with a two-digit international prefix. Therefore, a change to accommodate our three-digits prefix 420 had to be made. The used configuration supports the authorization of calls routed to PSTN and the users are authorized in a 'invite-to-external' section route.
POSERA is PHP OpenSER Administrator system keeping the same style as the Ostravian University website. Users communicate with the web interface of the SIP server through HTTPS and they are authenticated in LDAP.
Download POSERA and have a look at more screenshots.
1. interconnecting Asterisk PBX with a PSTN using a Signalling System #7 (SS7), Libss7 represents a library replacing libpri and making use of chan_zap as channel driver for Asterisk and a zaptel hardware as an interface to SS7 network. Asterisk with the SS7 channel driver to a live PSTN switch the Ericsson AXE platform was interconnected in specific project at Research and Development Centre for Mobile Applications (RDC) in Prague
2. describing a system of penetration tests which was developed as a tool for testing the key component of the VoIP infrastructure against the most wide-spread security threats, the system tests a SIP server for several types of attacks and based on the number of successful and failed penetrations prepares an assessment on the overall security, the system is designed as a web application with a modular structure, thus enabling access independently on the operational system’s platform, and can be extended by other modules |
