8   IP Telephony

IP telephony is an application running on packet switched data IP networks. Compared to a channel switching based telecommunication system, IP telephony is a more effective and advanced technology using up-to-date voice coding methods and communication protocols. The IP telephony project, started in mid 1999, allows this advanced method of voice communication to run within the CESNET2 network. In general, this activity aims to support the CESNET members in connecting and using the IP telephony network built by the CESNET Association. A research part of this project tests and develops the IP telephony applications and components.

8.1   Current state

By the end of 2004, 21 Association members became involved in this project with a total of 31 voice gateways. During 2004, the CESNET2 IP telephony network interconnected more than 1.3 million phone calls totalling over 4 million minutes. Fifteen percent of calls were toll-free internal calls within the CESNET2 network. The rest was routed to the PSTN and incurred costs were charged to the appropriate Association members. During 2004, the fifth year of the IP telephony project, the members' interest in IP phone calls reached its peak. Figure illustrates the duration of phone calls in hours made during past three years.

[Figure]

Figure 8.1: Duration of phone calls in hours between 2002 and 2004

A list of currently connected institutions can be found at the Project web site together with their prefixes and foreign peering.

8.2   Gatekeeper

Kerio, the supplier of the border gatekeepers deployed in the CESNET2 network, decided to terminate the VoIP product development and support. As a result, one of our goals in 2004 was replacement of the Kerio gatekeeper with a suitable alternative. We chose an open source solution based on the Debian/GNU Linux platform. We examined the current state of open source Linux gatekeeper applications by evaluating the following projects:

We deployed two GNU GK gatekeepers in the second half of the year. They can be accessed using the gk1ext.cesnet.cz and gk2ext.osanet.cz domain names. Servers are deployed at topologically and geographically distant locations: the gk1ext is located within the CESNET Association premises in Prague, while the gk2ext resides within the premises of the Technical University in Ostrava. Static records for all voice gateways in both gatekeepers were created and reachability of all gateways was checked. The H.323 endpoints wishing to communicate with their CESNET2 counterparts may register in these gatekeepers. This is of concern mainly for foreign research and educational institution gatekeepers, gateways and terminals. These two border gatekeepers allow them to connect only to the CESNET2 network; PSTN connection attempts are rejected. Two internal Cisco gatekeepers located also in Prague and Ostrava route local calls to the PSTN. The Gatekeeper diagram is shown in figure.

[Figure]

Figure 8.2: CESNET2 network Gatekeeper schema

Originally, connections were set up using a new IP2IP GW, but problems occurred at the H.245 level: only connections using the FastConnect method were set up correctly by the IOS. This method has been supported optionally since H.323v2, however, some applications (e.g., the NetMeeting) use H.245 explicitly. In the end we chose static routing in the border gatekeepers. Final setup of border gatekeepers should bring automatic redundancy. Turning off one of the GKs generates a URQ message and a subsequent RCF message to be sent to all endpoints. The URQ message requests for re-registration and the RCF message presents a list of alternative GKs. As a result, redundant mode is attained. Currently, experiments with DRC, GRX and Proxy mode are under way in the Ostrava GK. Therefore, only the gk1ext running in GRC mode is fully operational.

8.3   QoS research in the CESNET VoIP network

An IP phone monitoring application using the SNMP protocol has been developed. This allows IP phone MIB2 database lookups and receiving traps. Results are stored in the MySQL database and can be visualized using PHP scripts. Compared to SNMP, the ITU-T H.341 standard offers much better monitoring potential but unfortunately, almost no IP phone manufacturers implement it. Primarily, the SNMP monitoring application allows gathering packet loss information and IP phone network adapter status. This project was developed under the Linux OS using the following components:

In the second half of 2004 we targeted call quality measurements using the R-factor which was calculated using the new E-model. The Surveyor software analyzer was used for this purpose - the only one capable of R-factor measurement in mid 2004.

The R-factor is described in the ITU-T G.107 recommendation which defines a computing model known as an E-model. The R-factor is a well-tried tool for transmission planning and for determining the combined impact of various transmission parameters which influence the call quality. All appropriate transmission parameters are put together to calculate the R-factor as follows:

R = RO - IS - ID - IE-EFF + A

where

RO
is the basic signal-to-noise ratio,
IS
is a sum of all impairments occuring during speech transmission,
ID
is a degradation factor representing all impairments caused by the voice signal delay,
IE-EFF
includes packet loss,
A
is an advantage factor (permitted range is from 0 to 20)

Two sorts of R-factor were identified during measurement: Network R-factor comprising the device impact and User R-factor adding the susceptibility effects. Currently, the MOS parameter is mostly used for quoting the connection quality value; therefore, converting the R-factor to MOS is important. Our analyzer immediately converted the values measured to MOS. The VoIP connection parameters withing the CESNET2 network using different codecs were measured and the results were published in a report available at this web site.

As an example, the value of the MOS parameter of a phone call to the Louisiana State University reached 3.71. This roughly corresponds to the maximum MOS value achievable using a cell phone. The value of MOS during a call to the Hungarnet VoIP network reached 4.23 - this is the maximum value achievable during a PSTN call. These results prove that even the international calls made by the VoIP technology can be of excellent quality.

8.4   Numbering scheme

In the mid 2004, prefix 950 0 was assigned to the CESNET Association as its VoIP network access code by the Czech Telecommunication Office. As a result, CESNET acquired 100,000 assignable phone numbers. These numbers can be reached from public telephone network via the Technical University Ostrava and Czech Technical University Prague PBXs; this is a part of an experiment agreed to by the GTS Czech operator. These numbers should be available especially for IP phones and videoconferencing applications. Unfortunately, termination of these numbers from PSTN to the CESNET2 network is not yet possible. Number termination should be a part of voice service provider selection procedure.

[Figure]

Figure 8.3: The 950 0 access code assignment

The IP telephony prefix will be used for accessing the CESNET2 network not only from PSTN, but also from the Internet where especially the use of the ENUM protocol is expected.

8.5   Alternative call exits using CESNET VoGW

A voice gateway Cisco 2651-XM equipped with 2×ISDN/PRI was bought and installed in May 2004 in Ostrava where an alternative connection of the CESNET2 network has been deployed. The prices for the Moravian-Silesian and Prague telephone districts (TDs) are equivalent. Another exit into the Brno TD should be added in the first half of 2005. The interconnection agreement has not been signed yet.

8.6   Cisco Call Manager

During 2004 the Cisco Call Manager system (CCM) was upgraded from version 3.3 up to version 4.1.2; this brought significant interoperability improvement between the CCM, H.323 and SIP elements. System redundancy based on two hubs continues: the publisher (primary server) is located in Prague, the subscriber (spare server) in Ostrava. Because of these changes, compatibility problems arose on ICM 5.0 which is a fundamental part of the IPCC. This problem can be circumvented by using the IPCC Express version (CRS 3.5.1); however, this impacts the available functionality.

Configuration of several coexisting numbering plans within one CCM cluster has been tested successfully. This way, several device groups were set up and each of them could be assigned specific rules independently of the others. This coincided with solving the communication problems between the CCM and various gateways as well as with setup of codecs. Currently, this type of communication has been tested with C26xx, C1751 and M3810; this service will soon be ready for the Association members (accessing the network using the 420 950 0 prefix, connecting the members' IP phones). The Undefinite Messaging system represented by the Cisco Unity 4.0 and its interoperability with the CCM is being tested. Tests with SIP elements are being prepared. Initially, the Lotus Notes were used; however, this software did not meet our requirements and was replaced by the MS Exchange 2000. We were also concerned with the security issues - we used a newly installed independent experimental CCM server to test the service security parameters as well as communication security.

8.7   SIP

The main parts of the SIP infrastructure are represented by two SIP servers running the IPv4 as well as IPv6 protocols. These servers can route calls to the PBX gateways of the Association institutions, registered clients as well as remote IP phone domains, e.g., MIT (SIP.edu), SANET, NASK. We have advertised the general accessibility of our IP telephony network within the TERENA TF VVC and we have already detected several calls from the SANET network.

Accessibility of the SIP servers is supported by advanced DNS resource records. A basic method uses SRV records which provide service point propagation (server address or name and port of the target service). The SRV records also support load-balancing and service backup methods. In addition to the SRV records, we can also use the NAPTR records which provide a more advanced mechanism for locating the services. This way, users can determine which types of service the domain provides as well as the priority of services, and only then they will query the service point stored in the SRV records. So far, only several applications support the resolution of the NAPTR records. Should SRV records be resolvable but resolution of NAPTR records unavailable, the solution can be regarded as unsatisfactory. Experiments with these kinds of special records are going on to reach better service availability, simpler interdomain routing and easier client configuration; this should bring faster and easier IP telephony client deployment and administration.

The process of integrating SIP components into the AA infrastructure has advanced. A need to upgrade the existing LDAP modules of the server to provide at least secure communication (LDAPS) has been confirmed. We are testing the third version of our authentication module extension using a newly set up testing LDAP server. We also continued testing the SIP server and his advanced services but this system is not yet available for user registration. We postponed this phase because a new release of the SIP server scheduled for beginning of 2005 brings changes in functionality and module interface. We are working on upgrading modules for the new version and we are testing new server configuration.

We tested a Polycom Sound Point IP 500 SIP phone with very satisfactory results. Compared to Cisco phones, this device is equipped with advanced functionality like instant messaging, presence and interesting pricing. Its firmware is undergoing rapid development and we plan to continue its tests within the large IP clients' test planned for 2005. We also tested a complex audio-video client Wavethree Session which is used by the SIP.edu initiative members. The open source world was represented by the Linphone client which supports the IPv6 as well as the ENUM resolution, although in a rather nonstandard way. Its major problem is unsupported SRV record resolution. In the second half of 2004, we made basic tests of the Xten eyeBeam, Minisip, and SJPhone clients. In spite of qualitative improvement, these clients do not satisfy our needs in some areas (DNS SRV, etc.). We also made some basic tests of the GnomeMeeting client whose current version supports only H.323; however, its new version supports resolution of SRV records according to H.323v5 Annex O which is a very rare function. We also stored the SRV records for the H.323 service in main CESNET2 DNS servers for further testing.

Our newly installed test gateway allows us also verifying the IPv6 support. Results from our test show that Cisco gateways do not yet support the SIP signaling over the IPv6 protocol.

8.8   ENUM

A national ENUM domain (0.2.4.e164.arpa) has been delegated to the CZ.NIC Association. Based on our previous discussion with the CZ.NIC Association, we expected some progress in this field during the first half of 2004 but there was none. As a result, we continued our tests within a private E.164 domain within cesnet.cz. We are dealing with various possibilities of storing, converting and administering the records. The development version of the SIP servers can query several ENUM domains concurrently.

During the CZ.NIC's technical workshop we presented the need of testing delegations before the registration system starts operating. These test delegations were enabled during the third quarter of 2004. Active delegations for the 234 680 and 950 0 ranges, used directly by the CESNET Association for IP telephony applications, have been set up within the 0.2.4.e164.arpa domain. Most of these ranges are served by the CESNET main name servers, while testing subranges are delegated to the test name servers where the experiments with the records are going on. So far, the records are administered by hand because the results of our experiments influence the record layout. Experiments within the public tree significantly influence the general behavior of the query system, e.g., the total response time needed for queries sent from remote zones. The quality of ENUM support in Cisco gateways has not changed yet; this means that the gateways support only the old record format and can not assign calls to signaling protocols correctly. Therefore, we considered using TCL scripts and an auxiliary RADIUS server for external resolution.

previous
contents 		next
metacentrumliberouterlive showsvideoservereduroam