8   IP Telephony

IP telephony, as one of the advanced services offered by the CESNET2 network, attracts more and more users. For this reason, CESNET puts an appropriate emphasis on further development of the IP telephony infrastructure and improving its quality. In 2005, our work focused on the following main topics:

Near the end of 2005, the IP telephony activity organised a seminar where the audience obtained up-to-date information about the extent of current services and prepared innovations.

More than 1.5 million voice calls through the CESNET2 network were carried out during 2005 and the total duration of the calls was 4.5 million minutes. From this amount, about 0.7 million minutes were placed between the CESNET members. These numbers clearly demonstrate the utility and popularity of this service.

8.1   Current Status

As in the previous years, we received new requests form CESNET members to connect their PBXs. These were: SLU Opava in Karviná, MZLU in Brno and three institutes of ASCR in Prague - Institute of Geology, Institute of Chemical Process Fundamentals and Institute of Experimental Botany. An up-to-date list of institutions participating in the IP telephony project can be obtained from our web pages. Connected institutions use the same phone numbers as for the public telephony network. CESNET also received an additional IP telephony network access prefix 950 0 from the Czech Telecommunication Office, so we now have 100 thousand numbers available for IP phones and other clients. Reachability of these numbers from the networks of Czech Telecom, GTS Novera and Oskar Vodafone was verified. However, a problem with PSTN calls arose in connection with the CESNET PSTN output transformation, as the caller identification is bound to the output located in the CESNET premises. Therefore, we suspended the distribution of these numbers.

[Figure]

Figure 8.1: Scheme of the IP telephony infrastructure

Figure 8.1 shows a diagram of the IP telephony infrastructure. Voice gateways of CESNET members are registered to the internal gatekeepers GK1 and GK2. Reachability from the Internet is provided by the border gatekeepers gk1ext and gk2ext. All gateways support bidirectional communication via H.323 and almost all are also able to accept incoming SIP calls. Connections requiring translation between SIP and H.323 pass through the translation gateway. Beside the control elements for H.323 (GK1, GK2, gk1ext and gk2ext), we also installed the SER SIP server for handling SIP protocol calls. All in all, we now have an operational network supporting both major VoIP protocols.

8.2   Call Quality

We use the R-factor and MOS as the criteria for assessing call quality. For their measurement, we use the Surveyor software analyser that can convert an obtained value of the R-factor to Mean Opinion Score (MOS), Listener Quality (MOS-LQ), Mean Opinion Score PESQ (MOS-PQ) and Conversational Quality parameters. The Network R-factor is generated on the basis of quality deterioration caused by physical devices. The User R-factor summarises the subjective effects of quality deterioration caused by devices, such as timeliness and delay. The components for the R-factor calculation are described in the ITU-T G.107 recommendation. The calculation is based on the E-model and combines all transfer parameters that are important for the considered connection. Call quality measurement could be generally divided into three basic types:

Reception Quality
A measurement of how users evaluate what they hear during the call.
Conversational Quality
A measurement of how users evaluate the overall quality of the call. Apart from the reception quality, this type also captures the ability to converse during the call.
Transmission Quality
A measurement of the quality of the network path used for the voice signal transmission. More specifically, it measures the quality of a network service as opposed to the quality of a specific call.
[Figure]

Figure 8.2: Details - Audio Channel Quality statistics

Figure 8.2 shows a sample output for Details - Audio Channel quality from the analyser. The measurement provides us the following qualitative connection parameters:

Our work in the area of call quality measurement resulted in two technical reports: [VoZ05a] deals with the voice quality in the VoIP environment and shows the practical results, and [VoZ05] describes the methods for analysing quality by means of the Surveyor analyser.

8.3   H.323 Support

During 2005, we made progress with reconfiguring the border gatekeeper gk1ext.cesnet.cz. We tried to solve the authentication problems, issues related to phones behind NAT and GDS integration.

At present, only clients directly registered with gk1ext are authenticated. Accounts are created upon request and the authentication is done by means of username and password (MD5 hash). We registered several requests for gatekeeper interconnections, of which the most important was the request from the Lithuanian national academical network. However, we consider bilateral agreements as rather uninteresting since the strategy of most NRENs is oriented towards the GDS (Global Dialling Scheme) and its successor. This involves installing national gatekeepers and registering them with the root gatekeepers. The important advantage of the latter approach is the reachability between all other networks (most significantly NRENs, universities and research institutes). CESNET also uses GDS - the Czech national gatekeeper is gk1ext.cesnet.cz.

We addressed the problems of users behind NAT by activating the proxy mode for private addresses on gk1ext. The mechanism works as follows: if the gatekeeper detects an attempt to register a client with a private address, it acts as a signalling and RTP proxy for this client and mediates henceforth all the traffic flows. We verified this functionality for the Full Cone NAT. However, this solution does not work for the symmetric NAT. A universal solution could use a VPN client for accessing a VPN concentrator of the corresponding institution. CESNET offers its staff members and part-time researchers a VPN concentrator with authentication via TACACS+.

The issues related to gk1ext gatekeeper configuration are summarised in the technical report [VoN05].

In the first half 2005, we tested IP phones borrowed from Czech VoIP operators. This cooperation was mediated by the Connect! magazine and the results were published in the May issue of that magazine. In short, we strongly recommend an IP phone with authentication support for use with H.323 and GnuGk. For phones that do not support this feature, an IP address verification could be used. This method is also described in the technical report [VoN05].

8.4   Asterisk

Other areas of interest in 2005 were: IAX2 protocol support, SIP protocol support and H.323 channel availability. We tested AT-320 phones and specifically their use in the IAX2, H.323 and SIP modes. In addition, we investigated minor but interesting topics such as Asterisk control via a Command Line Interface (CLI) or GnuGk control via Telnet.

IAX2 could be a good option for achieving NAT transparency. Its main problem, though, is that it has not been standardised yet. Recently, a new Internet Draft was published replacing the expired version. The standardisation process is supposed to be completed in mid 2006. The draft describes a protocol designed for controlling the application layer and media transport. Other important features are creation, modification and termination of the session through the IP network. IAX2 is primarily intended for controlling voice transfer over IP, although it may also be used for various types of data streaming (audio, video). The primary goal is to provide an ultimate solution to the issue of NAT transparency. The protocol uses a single well-known UDP port, which can be easily configured to pass through the firewall.

The essential characteristics of IAX2 are:

8.4.1   H.323 Channel

Several independent methods are available for integrating the H.323 channel into the Asterisk system: h323, oh323, ooh323c and woomera. We experimented with the oh323 channel implementation and tested its functions in communication with H.323 terminals. We were able to set up this channel together with the GnuGk system and achieve partial functionality. At present, we are able to connect SIP, IAX2 and H.323 terminals to the Asterisk system. We discovered a problem with the optiPoint phones (300 advance, 400 standard) - they do not correctly represent the incoming number. On the other hand, the SJPhone software phone provides a correct representation.

H.323
This channel is included in the Asterisk source distribution (directory channels/h323) and acts as an H.323 gateway only, not a gatekeeper.
Oh323
The very first H.323 channel implementation for Asterisk, named Asterisk-oh323; it is still actively developed by the InAccess Networks project.

We are currently trying to resolve the following problems in the H.323 implementations for the Asterisk system:

The Asterisk software exchange uses GnuGk for providing the gatekeeper functionality necessary for H.323 channel support. So far we only tested configurations allowing any terminal to register. The registration is limited by the required phone number format and a corresponding definition of the phone number in the dial plan file. A more advanced authorisation is addressed in the technical report [VoN05]. The Asterisk implementation of a software exchange is described in the technical report [WZV05].

8.5   SIP

The main control element of the SIP protocol implementation in the CESNET2 network is a SIP proxy based on Linux and SIP Express Router (SER). The proxy also functions as the registrar server. Software or hardware SIP clients can register with the proxy and communicate through it. The SIP proxy also routes the calls to the gateways of the connected institutions according to the telephone number prefixes. Most gateways now have a native SIP connection. For gateways that do not support SIP, the calls are routed through a SIP/H.323 gateway. The proxy also handles calls to and from other SIP domains like iptel.org, bts.sk, aarnet.edu.au.

[Figure]

Figure 8.3: Scheme of the SIP and H.323 network interconnection

Calls initiated from the PBXs behind the gateways, from PSTN and from H.323 VoIP clients whose destination is the SIP network also pass through the SIP/H.323 gateway. After deploying the new routing system, we will be able to get rid of such an unnecessary protocol translation. At present, we are using CISCO IOS IP2IPGW as the SIP/H.323 gateway, even though its capabilities in certain areas such as ENUM are not satisfactory. Another candidate is the Asterisk PBX, which however still has some gaps in the H.323 implementation.

The SIP proxy operates in the so-called multidomain mode. It means that besides its main domain cesnet.cz the proxy is ready to serve the domains of other institutions as well.

Our aim is to motivate the connected institutions to test the SIP system and then migrate the SIP proxy into their own infrastructure. This setup will allow for a better integration of SIP into their telephony systems compared to the existing solution with the multidomain SIP proxy.

For a domain to work properly with the multidomain SIP proxy, correct routing of requests must be ensured by means of a DNS SRV record in the institution's DNS zone. Interested users can create their accounts via a web form. Requester's identity is verified using the eduroam infrastructure that uses AA systems of requester's home organisation. In the near future, along with the deployment of a new distributed AAI, we expect even broader and more effective use of AAI, mainly in the area of interdomain authentication and shared service access.

Together with the SIP server we launched a new web site - IpTelWiki - dedicated primarily to the SIP implementation in the CESNET2 network. This includes information about the protocol itself and integration of SIP into the existing CESNET2 IP telephony network, and also a howto document on creating and using a SIP account. Our goal is to make this web site a focal point of IP telephony information for the broadest possible community of users and administrators. This web site will later also become the official portal of the IP telephony activity. Apart from documents, the new site also provides a web interface to the SIP proxy (SerWeb) where users can manage their SIP accounts and registrations and also obtain call statistics and other data.

8.6   ENUM

The CZ.NIC Association, being the holder of the national domain delegation (0.2.4.e164.arpa), is now getting ready for a test operation. The domain delegation for prefixes 234 680 and 950 0 that we obtained during the pre-testing period has so far been the only one in the whole 0.2.4.e164.arpa tree.

In order to fully exploit the potential of the ENUM technology, we are prepared to arrange delegations for CESNET members involved in the IP telephony project on their behalf. The ultimate goal is to cover the entire CESNET2 IP Telephony network with ENUM records. The institutions could keep their records on their own name servers or, alternatively, they may be managed centrally on CESNET name servers. During the transition to the production status, which is supposed to happen in early 2007, the institutions will only need to ask one of the registrars for a new registration according to the rules for the 0.2.4.e164.arpa domain and the existing records will remain functional. It is worth noting that the registration process in the 0.2.4.e164.arpa domain is different from a normal DNS domain registration because of the relationship to the public telephone numbers. The involved institutions responded positively to the proposed scenario so we hope to be able to manage all the delegations really soon.

We have been participating in the discussions within the TERENA TF-VVC group about the new routing system that should gradually replace the GDS hierarchy. One option is to use the ENUM technology. Disadvantage of GDS is its tight coupling to H.323, which could be solved by the ENUM. Due to different levels of progress in national ENUM implementations, a private ENUM tree is likely to be used for that purpose. This requires only a simple action on our side that will replicate the information published in the public tree in the private one.

8.7   CCM

In 2005 we established an experimental connection of the IVR (Interactive Voice Response) application to the interfaces of software and hardware clients. We first used the IVR integrated in CCM in conjunction with the VoiceBox voice messaging application. We faced some difficulties arising from the distributed architecture of the system components. The connection between CCM, which takes care of the signalling distribution part of the application, and the data storage was unstable. Next, we tried to build a system that could be connected to any common database for storing voice messages. We also tried to set up a unified authentication of VoIP clients for all supported applications and successfully tested the basic scenario based on LDAP. We expect to offer the voice message recorder as a production service in the first half of 2006. At the same time, we are going to test clients that use other signalling protocols and integration of common IVRs into this system.

previous
contents 		next
metacentrum elearning liberouter live shows videoserver eduroam