The essence and problems of IP telephony, its use in secure mode. Protection against eavesdropping - we build secure SIP telephony with our own hands

• Tutorial

Hello, Habr!
This time I want to talk about the technologies for encrypting VoIP calls, what kind of protection different approaches provide, and how to organize the most secure one from eavesdropping. voice communication with technological safety guarantees.
In this article I will try to clearly explain the features of such technologies as SIP\TLS, SRTP and ZRTP. And I will demonstrate specific usage patterns using our service ppbbxx.com as an example.

A little theory

So, what is an encrypted VoIP call? Next we will talk about the SIP protocol as the most popular.
As we have already found out, a call consists of a signal and media parts, each of which can be encrypted separately using special protocol methods. SIP\TLS is used to encrypt signaling information, and ZRTP and SRTP protocols are used to encrypt “voice”.

SIP\TLS- roughly speaking, an analogue of HTTPS for regular SIP. The protocol allows the client to verify that it is communicating with the right server provided that the client trusts the certificate provided by the server. You can read more on Wikipedia

SRTP And ZRTP- these are two different ways to encrypt RTP streams. The fundamental difference between the two is that the key exchange for SRTP occurs in signaling (at the first signaling stage of call setup). And for ZRTP, immediately at the beginning of the exchange of RTP packets (in the second, “media” part) using a special protocol based on the Diffie-Hellman cryptography method.
It is important that for SRTP, a prerequisite for reliable call encryption is the simultaneous use of SIP\TLS + SRTP, otherwise it will not be difficult for an attacker to obtain the keys (which will be transmitted over unencrypted SIP) and listen to the conversation. While this is not important for ZRTP, the RTP stream will be securely encrypted regardless of whether the signaling is encrypted or not. Moreover, the protocol can detect the presence of “man in the middle” (including service servers!) between directly speaking clients. This ensures that the conversation cannot be eavesdropped, at least from a network/media eavesdropping perspective.

Connection diagram for SIP clients with different encryption settings:

The following schemes for installing an encrypted call can be distinguished:

1. Both users use SIP\TLS and SRTP. In this case, the exchange of keys for media encryption occurs via a secure signaling protocol. Trust in the server involved in establishing the connection is assumed. Outsiders cannot access either signaling information or voice data. The disadvantage is that the user is not informed at the protocol (client) level and is not convinced that the second user is also using an encrypted connection to the server.
2. Both users use ZRTP, while the voice passes through the server. In this case, the server is defined by the ZRTP protocol as Trusted MitM (man in the middle). Keys are exchanged using an algorithm based on the Diffie-Hellman method (which guarantees the impossibility of wiretapping) via the RTP protocol. If secure SIP\TLS is used, outsiders also cannot access either the signaling information or the “voice”. As in the first option, trust in the switching server is assumed, but unlike it, for reliable voice encryption Not mandatory use of secure SIP\TLS is required. Also, unlike the first option, each user sees that the conversation is encrypted to the server on both sides, and also that both are connected to the same (trusted) server.
3. Both users use ZRTP, but media is installed directly between clients. Since the key exchange takes place directly between clients, even the server that performed the switching cannot listen to the conversation. In this case, both clients display information that a secure direct communication session has been established. You can verify this by checking the SAS (short authorization strings) - they will be the same. If you need to hide signaling information from outsiders, you should use SIP\TLS. This is the most safe option, but in this case the server will not be able to perform many functions that are performed on it in other situations, for example, recording a conversation directly, voice transcoding for clients with different settings audio codecs, etc.
4. One user uses the first method described above, and the other uses the second. In this case, trust in the server is also required. Signaling information is encrypted using SIP\TLS. For a user with ZRTP, the protocol will report that an encrypted connection has been established to the server (End at MitM). It is impossible to find out whether encryption is used on the other side at the protocol level.

Let's finish with the theory and move on to practice! Let's set up our own SIP server, create SIP users, install SIP clients and learn how to make encrypted calls using free

Server setup

First of all, let's go to the section " Internal network -> Domains" and create your own domain so as not to be limited in the choice of SIP user names. You can park your domain or create a personal subdomain in one of the service zones.
Further it is necessary in the section " Internal network -> Sip Users"create SIP users and configure some parameters of their clients. The names of SIP users can be arbitrary, but since it is more convenient to dial numbers on soft and hardware phones, we will create identifiers of the form [email protected] and the like. I entered 1000, 1001, 1002, 1003. After creating the SIP ID, you must remember to click the “Save” button. If there are no unfilled forms left in the settings interface, the system will not complain and will show the change log with the status “Done”.

Next you need to configure the codecs and encryption methods used. To do this, click the gear icon to the left of the SIP ID. I plan to use a SIP client (CSipSimple) on a smartphone and want to use the ZRTP encryption method so in " basic"in the settings tab I select the G729 and SILK codecs, and in the " tab protection"ZRTP method.

You can choose other options. It is only important to note that the settings for the SIP account in the service interface must comply settings in the SIP client. This is necessary to ensure correct communication between clients with different codec and encryption settings. Also, do not forget to save the created configuration.

In general, this is enough to set up the simplest configuration. You can configure SIP clients and call between them by dialing their numbers 1000, 1001, 1002, 1003. If desired, you can add a general SIP gateway to this for calls to the telephone network and configure appropriate call routing. But, in this case, this is a slightly different scheme for using the service, which requires a different kind of security measures rather than encrypting traffic to the gateway.

Let's move on to setting up SIP clients

Launch CSipSimple and go to the configuration interface. Select the “Basic” wizard and configure it using data from the web interface. It should look like this:

Further in the general settings of CSipSimple in the section " Media -> Audio codecs"You need to select your preferred codecs. For calls via 3G, I recommend using SILK, OPUS, iLBC, G729. Since the settings are in the server interface and in the client interface must match, and on the server I selected SILK and G729, then in the list of CSipSimple audio codecs I only check the boxes next to these codecs, and uncheck the rest.
In the client section" Network -> Secure Protocol"You need to select the desired encryption parameters. I turn on only ZRTP. I leave the rest turned off. If desired, you can use SIP\TLS - you need to take into account that the server expects a TLS connection on port 443. This is made specifically for overly smart operators mobile communications, blocking standard VoIP ports.
You also need to take into account that SRTP and ZRTP are not always compatible and it is highly advisable to select only one of them in the client.

Making calls using ZRTP

Immediately after following the instructions, the SIP call from user 1001 to user 1000 will look like this.
CSipSimple shows that the call involves a MitM server to which both clients are connected. EC25 means that the Elliptic Curve Diffie-Hellman protocol is used with a 256-bit parameter. AES-256 is the symmetric encryption algorithm that is used. The ZRTP - Verified status means that the SAS control string has been verified by the user.

Let's change the media transfer mode in the ppbbxx settings for both clients. Setting direct media = yes will allow you to transmit voice directly. In this case, the parties see the same SAS strings, the Twofish-256 symmetric encryption algorithm is used. Using ZRTP in this mode requires much greater compatibility from clients and is less reliable in terms of establishing communications, since the server is not involved in the data transfer. It is mandatory to use the same audio codecs on all clients and ensure that NAT works correctly.

If SIP user 1001 has no encryption installed, while 1000 uses ZRTP, then the second client will show that encrypted voice transmission occurs only up to the server (End at MitM).

Let's summarize

A very interesting article about security in IP telephony was published on the website linkmeup.ru. We are posting it without changes, so to speak, from the author.

=======================

Hello, colleagues and friends, I, Vadim Semenov, together with the network-class.net project team, present a review article that touches on the main trends and threats in IP telephony, and most importantly, those protection tools that at the moment is offered by the manufacturer as protection (in the language of security specialists, let’s consider what tools the manufacturer offers to reduce vulnerabilities that can be exploited by illegitimate individuals). So, fewer words - let's get down to business.
For many readers, the term IP telephony has long been formed, and also the fact that this telephony is “better”, cheaper compared to public telephony (PSTN), is rich in various additional features etc. And this is true, however... partly. As we move from analogue (digital) telephony with our subscriber lines(from the subscriber telephone to the station or station extension) and connecting lines (inter-station communication line) were no less than only in the access and control zone of the telephony provider. In other words, ordinary people had no access there (or practically so, if you do not take into account the cable duct). I remember one question on the good old hacker forum: “Tell me how to get access to the PBX? - answer: “Well, you take a bulldozer, ram the wall of the telephone exchange building and voila.” And this joke has its share of truth) However, with the transfer of telephony to a cheap IP environment, we also received in addition the threats that an open IP environment poses. An example of acquired threats is the following:

• Sniffing signal ports to commit toll calls at someone else's expense
• Eavesdropping by intercepting IP voice packets
• Call interception, illegitimate user posing as legitimate user, man-in-the-middle attack
• DDOS attacks on station signaling servers in order to disable all telephony
• Spam attacks, sending a large number of phantom calls to a station in order to occupy all its free resources

Despite the obvious need to eliminate all possible vulnerabilities in order to reduce the likelihood of a particular attack, in fact, the implementation of certain protection measures must begin with drawing up a schedule that takes into account the cost of implementing protective measures against a specific threat and the enterprise’s losses from the implementation of this threat by attackers. After all, it is stupid to spend more money on the security of an asset than the value of the asset itself that we are protecting.
Having determined the security budget, we will begin to eliminate exactly those threats that are most likely for the company; for example, for a small organization, the most painful thing will be to receive a large bill for imperfect long-distance and international calls, while for public companies it is most important to maintain the confidentiality of conversations. Let us begin our gradual consideration in the current article with basic things - this is the provision in a safe way delivery of service data from station to telephone. Next, we will consider the authentication of phones before connecting them to the station, the authentication of the station from the phones, and the encryption of signaling traffic (to hide information about who is calling and where) and the encryption of conversational traffic.
Many voice equipment manufacturers (including Cisco Systems) already have integrated security tools, from the usual restriction of the range of IP addresses from which calls can be made to the authentication of end devices using a certificate. For example, the manufacturer Cisco Systems with its voice product line CUCM (Cisco Unified CallManager) began to integrate the “Security by Default” function from product version 8.0 (release date May 2010; version 10.5 dated May 2014 is currently available). What it includes:

• Authentication of all files downloaded via TFTP (configuration files, firmware files for phones, etc.)
• Encryption of configuration files
• Checking the certificate with the phone initializing the HTTPS connection

Let's look at an example of a “man in the middle” attack, when an illegitimate person intercepts configuration files for phones, from which the phone learns which station to register with, which protocol to work on, which firmware to download, etc. Having intercepted the file, the attacker will be able to make his own changes to it or completely erase the configuration file, thereby preventing the phones of the entire office (see figure) from registering at the station, and, consequently, depriving the office of the ability to make calls.

Fig.1 Man-in-the-middle attack

To protect against this, we will need knowledge of asymmetric encryption, public key infrastructure, and an understanding of the components of Security by Default, which we will now introduce: Identity Trust List (ITL) and Trust Verification Service (TVS). TVS is a service designed to process requests from IP phones that do not have an ITL or CTL file in the internal memory. The IP phone contacts TVS if it needs to make sure whether it can trust a particular service before starting to access it. The station also acts as a repository storing certificates of trusted servers. In turn, ITL is a list of public keys of the station elements that make up the cluster, but it is important for us that the public key of the TFTP server and the public key of the TVS service are stored there. When the phone initially boots, when the phone has received its IP address and TFTP server address, it requests the presence of an ITL file (Fig. 2). If it is on the TFTP server, then, blindly trusting, it loads it into its internal memory and stores it until the next reboot. After downloading the ITL file, the phone requests a signed configuration file.

Now let's look at how we can use cryptography tools - signing a file using the MD5 or SHA hash functions and encrypting using the private key of the TFTP server (Fig. 3). The special thing about hash functions is that they are one-way functions. Based on the received hash from any file, it is impossible to perform the reverse operation and get exactly original file. When a file is changed, the hash obtained from this file also changes. It is worth noting that the hash is not written to the file itself, but is simply appended to it and transmitted along with it.

Fig.3 Signing the phone configuration file

When forming a signature, the configuration file itself is taken, the hash is extracted from it and encrypted with the private key of the TFTP server (which only the TFTP server has).
When receiving this settings file, the phone initially checks it for integrity. We remember that a hash is a one-way function, so the phone has nothing left to do except separate the hash encrypted by the TFTP server from the configuration file, decrypt it using the TFTP public key (and how does the IP phone know it? - and just from the ITL file ), from a clean configuration file, calculate the hash and compare it with what we received during decryption. If the hash matches, it means that no changes were made to the file during transmission and it can be safely used on the phone (Fig. 4).

Fig.4 Checking the configuration file with an IP phone

The signed configuration file for the phone is shown below:

Rice. 5 Signed IP phone file in Wireshark

By signing the configuration file, we were able to ensure the integrity of the transferred settings file, but we did not protect it from viewing. You can get quite a lot from the captured configuration file useful information, for example, the IP address of a telephone exchange (in our example it is 192.168.1.66) and open ports at the exchange (2427), etc. Isn’t it quite important information that you wouldn’t want to just “shine” on the Internet? To hide this information, manufacturers provide the use of symmetric encryption (the same key is used for encryption and decryption). In one case, the key can be entered into the phone manually; in another case, the phone’s configuration file is encrypted at the station using the phone’s public key. Before sending the file to the phone, the tftp server on which this file is stored encrypts it using the phone’s public key and signs it using its private key (thus we ensure not only secrecy, but also integrity transferred files). The main thing here is not to get confused about who is using which key, but let’s take it in order: the tftp server, by encrypting the file with the public key of the IP phone, ensured that only the owner of the paired public key can open this file. By signing the file with its private key, the tftp server confirms that it was he who created it. The encrypted file is shown in Figure 6:

Fig.6 Encrypted IP phone file

So at this point we've looked at protecting our phone configuration files from being viewed and ensuring their integrity. This is where the Security by Default functionality ends. To ensure encryption of voice traffic and hiding signaling information (about who is calling and where they are calling), additional tools are needed based on the list of trusted certificates - CTL, which we will consider further.

Telephone exchange authentication

When a phone needs to communicate with a telephone exchange (for example, to negotiate a TLS connection for signaling exchange), the IP phone needs to authenticate the exchange. As you might guess, certificates are also widely used to solve this problem. At the moment, modern IP stations consist of a large number of elements: several signaling servers for processing calls, a dedicated administration server (new phones, users, gateways, routing rules, etc. are added through it), a dedicated TFTP server for storing configuration files and software for phones, a server for broadcasting music on hold, etc., in addition, the voice infrastructure may include voicemail, a server for determining the current state of the subscriber (online, offline, “at lunch”) - the list is impressive and, most importantly, every the server has its own self-signed certificate and each acts as a root certification authority (Fig. 7). For this reason, any server in the voice infrastructure will not trust the certificate of another server, for example, a voice server does not trust a TFTP server, voice mail does not trust a signaling server, and besides, phones must store the certificates of all elements participating in the exchange of signaling traffic. Telephone exchange certificates are shown in Figure 7.

Fig.7 Self-signed Cisco IP station certificates

For the tasks of establishing trust relationships between the above-described elements in voice infrastructures, as well as encrypting voice and signaling traffic, the so-called Certificate Trust List (CTL) comes into play. The CTL contains all self-signed certificates of all servers in the voice station cluster, as well as those participating in the exchange of telephony signaling messages (for example, a firewall) and this file is signed with the private key of a trusted certification authority (Fig. 8). The CTL file is equivalent to the installed certificates that are used in web browsers when working with the https protocol.

Fig.8 List of trusted certificates

In order to create a CTL file on Cisco equipment, you will need a PC with a USB connector, the CTL client program installed on it, and the Site Administrator Security Token (SAST) itself (Fig. 9), containing a private key and an X.509v3 certificate signed by an authentication center manufacturer (Cisco).

Fig.9 eToken Cisco

CTL client is a program that is installed on a Windows PC and with which you can transfer the ENTIRE telephone exchange to the so-called mixed mode, that is, a mixed mode supporting the registration of end devices in secure and unsafe modes. We launch the client, specify the IP address of the telephone exchange, enter the administrator login/password and the CTL client establishes a TCP connection on port 2444 with the station (Fig. 10). After this, only two actions will be offered:

Fig.10 Cisco CTL Client

After creating the CTL file, all that remains is to reboot the TFTP servers so that they download the new created CTL file, and then reboot the voice servers so that the IP phones also reboot and download the new CTL file (32 kilobytes). The downloaded CTL file can be viewed from the IP phone settings (Fig. 11)

Fig. 11 CTL file on an IP phone

Endpoint authentication

To ensure that only trusted endpoints are connected and registered, device authentication must be implemented. In this case, many manufacturers use an already proven method - device authentication using certificates (Fig. 12). For example, in the Cisco voice architecture this is implemented as follows: there are two types of certificates for authentication with corresponding public and private keys that are stored on the phone:
Manufacturer Installed Certificate – (MIC). The certificate installed by the manufacturer contains a 2048-bit key, which is signed by the manufacturer's certification authority (Cisco). This certificate is not installed on all phone models, and if it is installed, then there is no need to have another certificate (LSC).
Locally Significant Certificate – (LSC) A locally significant certificate contains the public key of the IP phone, which is signed by the private key of the local authentication center, which runs on the telephone exchange itself, the Certificate Authority Proxy Function (CAPF).
So, if we have phones with a pre-installed MIC certificate, then every time the phone registers with a station, the station will request a certificate pre-installed by the manufacturer for authentication. However, if the MIC is compromised, replacing it requires contacting the manufacturer's certification center, which may require a lot of time. In order not to depend on the response time of the manufacturer's certification authority to reissue a compromised phone certificate, it is preferable to use a local certificate.

Fig. 12 Certificates for authentication of end devices

By default, an LSC certificate is not installed on an IP phone and its installation can be done using a MIB certificate (if available), or through a TLS connection (Transport Layer Security) using a shared public key manually generated by the administrator at the station and entered on the phone.
The process of installing a locally significant certificate (LSC) on the phone containing the phone's public key signed by a local certification authority is shown in Figure 13:

Fig.13 Installation process of a locally valid LSC certificate

1. After loading the IP phone, it requests a trusted list of certificates (CTL file) and a configuration file
2. The station sends the requested files
3. From the received configuration, the phone determines whether it needs to download a locally significant certificate (LSC) from the station
4. If we at the station set up for the phone to install an LSC certificate (see below), which the station will use to authenticate this IP phone, then we must make sure that upon a request to issue an LSC certificate, the station issues it to that person. to whom it is intended. For these purposes, we can use a MIC certificate (if there is one), generate a one-time password for each phone and enter it manually on the phone, or not use authorization at all.
The example demonstrates the process of installing LSC using the generated

Powered by SEO CMS ver.: 23.1 TOP 2 (opencartadmin.com)

Submitting your good work to the knowledge base is easy. Use the form below

Students, graduate students, young scientists who use the knowledge base in their studies and work will be very grateful to you.

Posted on http://www.allbest.ru/

Introduction

1 Construction of an IP telephony network

1.1 Transport technologies packet switching

1.2 Levels of IP telephony architecture

1.3 Different approaches to building IP telephony networks

1.3.1 Network based on the H.323 protocol

1.3.2 SIP-based network

1.3.3 MGCP based network

1.4 Comparison of approaches to building an IP telephony network

1.5 Options for IP telephony systems (scenarios)

2. Types of threats in IP telephony and methods to combat them

2.1 Types of threats in IP telephony

2.2 Methods of cryptographic information protection

2.3 Protection against eavesdropping

2.4 Access network security

2.5 Authentication technologies

3. Ensuring security in terms of checking resource access rights (AAA). Comparison of TACACS+ and RADIUS protocols

3.1 Indirect authentication

3.2 AAA technologies based on the TACACS+ protocol

3.2.1 TACACS+ protocol

3.2.2 Properties of the TACACS+ protocol

3.2.3 AAA processes in the TACACS+ protocol

3.3 AAA technologies based on the RADIUS protocol

3.3.1 RADIUS protocol

3.3.2 Properties and capabilities of the RADIUS protocol

3.3.4 RADIUS audit process

3.3.5 Comparison of the capabilities of the TACACS+ and RADIUS protocols

3.3.6 Technical inconsistencies with the theoretical characteristics of the TACACS and RADIUS protocols

Conclusion

List of sources used

Introduction

IP telephony has enough advantages to soon spread throughout our country; taking into account the economic aspects and the message of the President of the Republic of Kazakhstan Nursultan Abishevich Nazarbayev to the people of Kazakhstan “New decade, new economic recovery, new opportunities for Kazakhstan”: “The leading economies of the world will operate in more complex, competitive conditions and will take preventive measures to prepare for the next economic cycle, increasing workforce productivity, investing in infrastructure and telecommunications, strengthening financial systems, improving government efficiency, and creating an enabling environment for business development.”

VoIP is a communication system that provides voice signal transmission over the Internet or any other IP networks. The signal over the communication channel is transmitted in digital form and, as a rule, is converted (compressed) before transmission in order to remove redundancy.

Gone are the days when operators were wary of using IP telephony, considering the level of security of such networks to be low. Today we can already say that IP telephony has become a kind of standard in telephone communications. This is explained by the convenience, relative reliability and relatively low cost of IP telephony compared to analog communication. It can be argued that IP telephony improves business efficiency and allows for previously unavailable operations such as integration with various business applications.

If we talk about the shortcomings and vulnerabilities of IP telephony, first of all, we should note the same “diseases” that other services using the IP protocol suffer from. This is exposure to worms and viruses, DoS attacks, unauthorized remote access, etc.

Despite the fact that when building an IP telephony infrastructure, this service is usually separated from network segments in which non-voice data flows, this is not a guarantee of security. Today large number Companies are integrating IP telephony with other applications, such as email. On the one hand, this creates additional conveniences, but on the other hand, it also creates new vulnerabilities. In addition, the operation of an IP telephony network requires a large number of components, such as support servers, switches, routers, firewalls, IP phones, etc.

Among the main threats to which the IP telephone network is exposed are:

Registration of someone else's terminal, allowing you to make calls at someone else's expense;

Subscriber substitution;

Ending a communication session;

Denial of service;

Remote unauthorized access to IP telephony infrastructure components;

Unauthorized software update on an IP phone (for example, for the purpose of introducing a Trojan or spyware);

Hacking the billing system (for operator telephony).

This is not a complete list possible problems related to the use of IP telephony. The VoIP Security Alliance (VOIPSA) has developed a document describing a wide range of IP telephony threats, which in addition to technical threats includes VoIP extortion, spam, etc.

And yet the main weak point of IP telephony is the annoying human factor. Security issue when deploying IP telephone network often relegated to the background, and the choice of solution takes place without the participation of security specialists. In addition, specialists do not always configure the solution properly, even if it has the appropriate protection mechanisms, or they purchase protection tools that are not designed to effectively process voice traffic (for example, firewalls may not understand the proprietary signaling protocol used in the IP telephony solution ). Ultimately, the organization is forced to expend additional financial and human resources to protect the deployed solution or accept its insecurity.

1 . Network buildingIP-telephony

1.1 Packet Switching Transport Technologies

Most manufacturers with a wide range of package telephony products are technology neutral and allow the customer to choose the technology that best suits their integration strategy. The main technologies of packet voice transmission - Frame Relay, ATM and IP packet routing - differ in the efficiency of using communication channels, the degree of coverage of different sections of the network, reliability, manageability, information and access protection, as well as cost.

Figure 1.1. Speech on ATM

Figure 1.2. Speech over Frame Relay

Figure 1.3. Speech over IP

ATM transport technology has been successfully used for several years in public backbone networks and in corporate networks, and now it is being actively used for high-speed access via xDSL channels (for small offices) and SDH/Sonet (for large enterprises).

The main advantages of this technology are its maturity, reliability and the availability of developed means of operational network management. It has mechanisms for managing the quality of service and monitoring the use of network resources that are unsurpassed in their effectiveness. However, the limited prevalence and high cost of equipment do not allow ATM to be considered best choice for organizing end-to-end telephone connections from one end node to another. Frame Relay technology was destined to play the same role in packet telephony that quasi-electronic PBXs played in circuit-switched telephony: they provided an example of efficient software-controlled technology, but had limited opportunities further development.

Many enterprise networks have adopted Frame Relay's low-cost, predictable performance services, and most are happy with their choice. In the short term, voice transmission technology over Frame Relay will be quite effective for organizing multiservice access and long-distance communication channels. But Frame Relay networks are not widespread: as a rule, in practice, non-switched point-to-point connections are used.

The technology for transmitting voice information over networks with IP packet routing is attractive, first of all, for its versatility - speech can be converted into a stream of IP packets at any point in the network infrastructure: on the operator’s network backbone, at the edge of a geographically distributed network, in corporate network and even directly in the end user terminal. Ultimately, it will become the most widely adopted packet telephony technology because it can cover all market segments while being highly adaptable to new applications. Despite the universality of the IP protocol, the implementation of IP telephony systems is hampered by the fact that many operators consider them to be insufficiently reliable, poorly managed and not very effective. But a well-designed network infrastructure with effective mechanisms for ensuring quality of service makes these shortcomings insignificant. Per port, the cost of IP telephony systems is at the level (or slightly lower) of the cost of Frame Relay systems, and is certainly lower than the cost of ATM equipment. At the same time, it is already clear that prices for IP telephony products are falling faster than for other products, and that there is a significant intensification of competition in this market.

1.2 IP telephony architecture levels

The architecture of Voice over IP technology can be simplified into two planes. The lower plane is the core network with IP packet routing, the upper plane is the open architecture for call service control (communication requests).

The lower plane, to put it simply, is a combination of well-known Internet protocols: it is RTP (Real Time Transport Protocol), which operates on top of the UDP (User Datagram Protocol), located, in turn, in the TCP/IP protocol stack above the IP protocol.

Thus, the RTP/UDP/IP hierarchy represents a kind of transport mechanism for voice traffic. Here we note that in networks with routing IP packets for data transmission, mechanisms are always provided for retransmitting packets in the event of their loss.

When transmitting information in real time, the use of such mechanisms will only worsen the situation, therefore, for the transmission of information that is sensitive to delays, but less sensitive to losses, such as speech and video information, the mechanism of non-guaranteed delivery of information RTP/UDPD/IP is used. ITU-T recommendations allow delays in one direction not exceeding 150 ms. If the receiving station requests retransmission of the IP packet, the delay will be too long.

Now let's move on to the upper plane of management of servicing communication requests. Generally speaking, call service control involves making decisions about where the call should be routed and how the connection between subscribers should be established.

A tool for such management is telephone systems signaling, starting with systems supported by decade-step PBXs and providing for the combination of routing functions and functions for creating a switched voice channel in the same decade-step finders. Further, the principles of signaling evolved to signaling systems over dedicated signaling channels, to multi-frequency signaling, to general-channel signaling protocols No. 7 and to the transfer of routing functions to the corresponding service processing nodes of the Intelligent Network.

In packet-switched networks the situation is more complex. An IP routing network fundamentally supports a number of different routing protocols simultaneously.

Such protocols today are: RIP - Routing Information Protocol, IGRP - Interior Gateway Routing Protocol, EIGRP - Enhanced Interior Gateway Routing Protocol, IS-IS - Intermediate System-to-intermediate System, OSPF - Open Shortest Path First, BGP - Border Gateway Protocol, etc. In the same way, a number of protocols have been developed for IP telephony.

The most common is the protocol specified in ITU-T recommendation H.323, in particular because it came into use earlier than other protocols, which, moreover, did not exist at all before the introduction of H.323.

Another call service control plane protocol, SIP, aims to make endpoints and gateways more intelligent and support additional services for users.

Another protocol, SGCP, has been developed since 1998 in order to reduce the cost of gateways by implementing intelligent call processing functions in centralized equipment. IPDC is very similar to SGCP, but has many more operational management mechanisms (OAM&P) than SGCP. At the end of 1998, the MEGACO working group of the IETF committee developed the MGCP protocol, based mainly on the SGCP protocol, but with some additions in the OAM&P part.

The MEGACO working group did not stop there, continued to improve the gateway management protocol and developed the MEGACO protocol, which is more functional than MGCP.

1.3 Various approaches to building IP telephony networks

To make it clear how exactly the protocols differ from each other, I will briefly consider the architecture of networks built on the basis of these protocols, and the procedures for establishing and terminating connections using them.

1.3 .1 Network based on H.323 protocol

The first ever approach to building IP telephony networks on a standardized basis was proposed by the International Telecommunication Union (ITU) in recommendation H.323. Networks based on H.323 protocols are aimed at integration with telephone networks and can be considered as ISDN networks superimposed on data networks.

In particular, the connection establishment procedure in such IP telephony networks is based on the Q.931 recommendation and is similar to the procedure used in ISDN networks.

Recommendation H.323 provides a rather complex set of protocols, which are intended not just for transmitting voice information over packet-switched IP networks. Its purpose is to enable multimedia applications to operate on networks with unguaranteed quality of service. Voice traffic is just one of the applications of H.323, along with video and data.

The option for building IP telephony networks, proposed by the International Telecommunication Union in recommendation H.323, is well suited to those local telephone network operators who are interested in using a packet-switched network (IP network) to provide long-distance and international communication services. The RAS protocol, part of the H.323 protocol family, provides control over the use of network resources, supports user authentication, and can provide charging for services.

Figure 1.4 shows the network architecture based on the H.323 recommendation. The main network devices are: Terminal, Gateway, Gatekeeper and Multipoint Control Unit (MCU).

Figure 1.4. H.323 network architecture

An H.323 terminal is a user endpoint of an IP telephony network that provides two-way voice (multimedia) communication with another H.323 terminal, gateway or conference control device.

The IP telephony gateway implements the transmission of voice traffic over networks with routing of IP packets using the H.323 protocol. The main purpose of the gateway is to convert voice information coming from the PSTN into a form suitable for transmission over networks with IP packet routing. In addition, the gateway converts DSS1 and SS7 signaling messages into H.323 signaling messages and performs the reverse conversion in accordance with ITU H.246 recommendation.

The gatekeeper contains all the intelligence of the IP telephony network.

A network built in accordance with recommendation H.323 has a zone architecture (Figure 1.5). The gatekeeper performs the functions of managing one zone of the IP telephony network, which includes: terminals, gateways, conference control devices registered with this gatekeeper. Individual fragments of the H.323 network zone can be geographically separated and connected to each other through routers.

Figure 1.5. H.323 network area

The most important functions of a gatekeeper are:

Registration of terminals and other devices;

Control of access of system users to IP telephony services using RAS signaling;

Converting the called user (announced subscriber name, telephone number, email address, etc.) into the transport address of networks with IP packet routing (IP address + TCP port number);

Monitoring, management and reservation of network capacity;

Relay of H.323 signaling messages between terminals.

In one IP telephony network that meets the requirements of ITU recommendation H.323, there can be several gatekeepers interacting with each other using the RAS protocol.

In addition to the basic functions defined by the H.323 recommendation, the gatekeeper may be responsible for user authentication and billing for telephone connections. A conference control device provides the ability to organize communications between three or more participants.

Recommendation H.323 provides for three types of conference (Figure 1.6): centralized (i.e. controlled by an MCU, with which each conference participant is connected in point-to-point mode), decentralized (when each conference participant is connected to the rest of its participants in point-to-point mode). group of points) and mixed.

The advantage of a centralized conference is the relatively simple terminal equipment, the disadvantage is the high cost of the conference control device.

A decentralized conference requires more complex terminal equipment and it is desirable that the IP network supports the transmission of IP packets in IP multicasting mode. If this mode is not supported on the network, the terminal must transmit voice information to each of the other participants in the conference in point-to-point mode.

The conference control device consists of one mandatory element - a conference controller (Multipoint Controller - MC), and, in addition, may include one or more processors for processing user information (Multipoint Processor - MP). The controller may be physically associated with a gatekeeper, gateway, or conference control device, which in turn may be associated with a gateway or gatekeeper.

Drawing. 1.6. Types of conferences in H.323 networks

The conference controller is used to organize any type of conference. It organizes the exchange between conference participants of data about the modes supported by their terminals, and indicates in what mode conference participants can transmit information, and this mode can change during the conference, for example, when a new participant joins it.

Since there can be several controllers on the network, for each newly created conference a special procedure identifying the controller that will manage this conference.

When organizing a centralized conference, in addition to the MS controller, an MP processor must be used to process user information. The MP processor is responsible for switching or mixing speech streams, video information and data. A decentralized conference does not require a processor.

There is another element of the H.323 network - the H.323 proxy server, i.e. intermediary server. This server operates at the application layer and can inspect packets of information exchanged between two applications.

The proxy server can determine which application (H.323 or other) the call is associated with and make the desired connection. The proxy server performs the following key functions:

Connection via dial-up means or local networks of terminals that do not support the Resource Reservation Protocol (RSVP). Two such proxy servers can form a tunnel connection in an IP network with a given quality of service;

Routing H.323 traffic separately from regular data traffic;

Ensuring compatibility with Network Address Translator, since H.323 equipment can be placed in networks with private network address space;

Access protection - availability only for H.323 traffic.

The RAS (Registration Admission Status) protocol ensures the interaction of endpoints and other devices with the gatekeeper.

The main functions of the protocol are: registering a device in the system, controlling its access to network resources, changing the bandwidth during communication, polling and indicating the current state of the device. The transport protocol is a protocol with non-guaranteed delivery of information UDP.

The H.225.0 (Q.931) protocol supports connection establishment, maintenance, and termination procedures. The transport protocol is a connection-based protocol with guaranteed delivery of TCP information.

According to the H.245 protocol, information is exchanged between the participants in the connection, which is necessary to create logical channels. These channels transmit voice information packaged in RTP/UDP/IP packets.

Performing the procedures provided by the RAS protocol is the initial phase of establishing a connection using H.323 signaling. This is followed by the H.225.0 signaling phase (Q.931) and the exchange of H.245 control messages. The destruction of the connection occurs in the reverse order: first, the H.245 control channel and the H.225.0 signaling channel are closed, after which the gatekeeper is notified via the RAS channel that the previously occupied bandwidth has been released.

The complexity of the H.323 protocol is demonstrated in Figure 1.7, which shows a simplified scenario for establishing a connection between two users. In this scenario it is assumed that end users already know each other's IP addresses. In a typical case, there are more steps because gatekeepers and gateways are involved in establishing the connection.

Let's walk through this simplified scenario step by step.

1) User terminal A sends a connection request - a SETUP message - to user terminal B on TCP port 1720;

2) The terminal device of the called user B responds to the SETUP message with an ALERTING message, indicating that the device is free and the called user is alerted to an incoming call;

3) After user B accepts the call, a CONNECT message is sent to calling party A with the TCP port number of the H.245 control channel;

4) The end devices exchange information via the H.245 channel about the types of speech codecs used (G.729, G.723.1, etc.), as well as other functionality of the equipment, and notify each other about the RTP port numbers to which information should be conveyed;

5) Logical channels are opened for transmitting voice information;

6) Voice information is transmitted in both directions in RTP protocol messages; In addition, the transmission of information is controlled using the RTCP protocol.

Figure 1.7. Simplified scenario for establishing a connection in the H.323 network

The above call servicing procedure is based on the H.323 protocol version 1. Version 2 of the H.323 protocol allows you to transmit the information necessary to create logical channels directly in the H.225.0 protocol SETUP message without using the H.245 protocol.

This procedure is called " quick start» (Fast Start) and allows you to reduce the number of information exchange cycles when establishing a connection. In addition to organizing a basic connection, H.323 networks provide additional services in accordance with ITU H.450.X recommendations.

Another important problem worth noting is the quality of service in H.323 networks. An endpoint requesting access from a gatekeeper may use the transportQoS field in the RAS ARQ message to indicate its ability to reserve network resources.

Recommendation H.323 defines the Resource Reservation Protocol (RSVP) as a means of providing guaranteed quality of service, which requires terminals to support the RSVP protocol. Unfortunately, RSVP is not widely used, leaving H.323 networks without a core mechanism for ensuring guaranteed quality of service. This - common problem IP telephony networks, which is typical not only for H.323 networks.

1.3.2 Protocol-based networkSIP

The second approach to building IP telephony networks, proposed by the MMUSIC working group of the IETF committee in RFC 2543, is based on the use of the SIP - Session Initiation Protocol.

SIP is a text-based protocol that is part of the global multimedia architecture developed by the Internet Engineering Task Force (IETF).

This architecture also includes the Resource Reservation Protocol (RSVP, RFC 2205), the Real-Time Transport Protocol (RTP, RFC 1889), the Real-Time Streaming Protocol, RTSP, RFC 2326), Session Description Protocol (SDP, RFC 2327), Session Announcement Protocol (SAP). However, the functionality of SIP is independent of any of these protocols.

It should be noted right away that although the H.323 protocol is the most widely used today, an increasing number of manufacturers are trying to provide support for the SIP protocol in their new products.

So far these are isolated phenomena and cannot seriously compete with the H.323 protocol. However, given the growth rate of the popularity of the SIP protocol, it is very likely that in the near future solutions based on it will occupy a significant niche in the IP telephony market.

The SIP approach to building IP telephony networks is much simpler to implement than H.323, but is less suitable for organizing interaction with telephone networks. This is mainly due to the fact that the SIP signaling protocol, which is based on the HTTP protocol, does not fit well with the signaling systems used in the PSTN. Therefore, SIP is more suitable for Internet service providers to provide IP telephony services, and this service will be just part of a package of services.

However, SIP supports intelligent network (IN) services such as name mapping, forwarding and routing, which are essential for using SIP as a signaling protocol in a public network where the operator's priority is to provide a wide range of telephone services .

Another important feature of the SIP protocol is its support for user mobility, i.e. its ability to access ordered services anywhere and from any terminal, and the ability of the network to identify and authenticate the user as he moves from one location to another.

This feature of SIP is not unique, and, for example, the H.323 protocol also largely supports this feature. Now is the time when this opportunity will become the main attractive feature of next-generation IP telephony networks. This mode of operation will require remote registration of users on the identification and authentication server.

Let's move directly to the architecture of networks based on the SIP protocol (Figure 1.8).

Figure 1.8. Example of a SIP-based network

A SIP network contains three main types of elements: user agents, proxy servers, and forwarding servers.

User agents (User Agent or SIP client) are terminal equipment applications and include two components: a user agent client (UAC) and a user agent server (UAS), otherwise known as client and server respectively.

The UAC client initiates SIP requests, i.e. acts as the calling party. The UAS server accepts requests and returns responses, i.e. acts as the called party.

Additionally, there are two types of SIP network servers: proxy servers (intermediary servers) and forwarding servers.

SIP servers can operate in both stateful mode (statefull) and stateless mode (stateless).

A SIP server operating in stateless mode can serve an arbitrarily large number of users, unlike an H.323 gatekeeper, which can work with a limited number of users simultaneously.

A proxy server (Proxy-server) acts “on behalf of other clients” and contains client (UAC) and server (UAS) functions. This server interprets and can rewrite request headers before sending them to other servers (Figure 1.9). Reply messages follow the same path back to the proxy server rather than to the client.

Figure 1.9. SIP network with proxy server

Figure 1.9 shows the algorithm for establishing a connection using the SIP protocol with the participation of a proxy server:

1) The proxy server receives an INVITE connection request from the calling user's equipment;

2) The proxy server establishes the client's location using a location server;

3) The proxy server passes the INVITE request to the called user;

4) The called user's equipment notifies the latter of the incoming call and returns a message to the proxy server that the INVITE request is being processed (code 100). The proxy server, in turn, forwards this information to the calling user's equipment;

5) When the called subscriber receives a call, his equipment notifies the proxy server (code 200), which forwards information that the call has been accepted to the calling user's equipment;

6) The calling party confirms the establishment of the connection by sending an ACK request, which the proxy server forwards to the called party. The connection has been established and the subscribers can exchange voice information.

The Redirect server determines the current location of the called subscriber and reports it to the calling user (Figure 1.10). To determine the current location of the called subscriber, the redirection server contacts the location server, the principles of operation of which are not specified in RFC 2543.

The algorithm for establishing a connection using the SIP protocol with the participation of a forwarding server is as follows:

1) The forwarding server receives an INVITE connection request from the calling party and contacts the location server, which provides the current address of the called client;

2) The forwarder forwards this address to the calling party. Unlike a proxy server, the redirection server does not transmit an INVITE request to the equipment of the called user;

3) The calling user’s equipment confirms the completion of the transaction with the redirection server with an ACK request;

5) The called user's equipment notifies the latter of the incoming call and returns a message to the calling equipment that the INVITE request is being processed (code 100);

6) When the called subscriber accepts the call, the calling user's equipment is notified (code 200). The connection is established, the subscribers can exchange voice information.

Figure 1.10. SIP network with forwarding server

There is also a serverless connection option, when one terminal can send a request to another terminal directly.

SIP signaling enables user agents and network servers to determine location, issue requests, and manage connections.

INVITE - a request invites a user or service to participate in a communication session and contains a description of the parameters of this communication. With this request, the user can determine the functionality of his communication partner's terminal and begin a communication session using a limited number of messages and their acknowledgments.

ACK - the request confirms receipt of the response to the INVITE command from the called party and completes the transaction.

OPTIONS - the request allows you to obtain information about the functionality of user agents and network servers. However, this request is not used to establish communication sessions.

BYE - The request is used by the caller and callee to destroy the connection. Before destroying the connection, user agents send this request to the server, indicating their intent to terminate the communication session.

A CANCEL request allows user agents and network servers to cancel any previously sent request if a response has not yet been received.

1. 3.3 Network basedMGCP

The third approach to building IP telephony networks, based on the use of the MGCP protocol, was also proposed by the IETF committee, the MEGACO working group.

When developing this protocol, the MEGACO working group relied on a network architecture containing three types of main functional blocks (Figure 1.11):

Gateway - Media Gateway (MG), which performs the functions of converting voice information coming from the PSTN at a constant transmission rate into a form suitable for transmission over networks with IP packet routing (encoding and packaging of voice information into RTP/UDP/IP packets, as well as the inverse transformation);

Gateway controller - Call Agent, which performs gateway management functions;

Signaling Gateway (SG), which ensures the delivery of signaling information coming from the PSTN to the gateway controller and the transfer of signaling information in the opposite direction.

Thus, all the intelligence of a functionally distributed gateway is concentrated in the controller, the functions of which can be distributed across several computer platforms.

Figure 1.11. Network architecture based on the MGCP protocol

The signaling gateway performs the functions of STP - a transit point of the SS7 signaling network. The gateways themselves perform only the functions of converting speech information. One controller controls several gateways simultaneously.

There may be several controllers on the network. It is assumed that they are synchronized with each other and consistently control the gateways participating in the connection. However, MEGACO does not define a protocol for synchronizing the operation of controllers.

In a number of works devoted to the study of the capabilities of the MGCP protocol, it is proposed to use the H.323, SIP or ISUP/IP protocols for this purpose. MGCP messages are carried by the protocol without guaranteed delivery of UDP messages. The IETF SIGTRAN Working Group is currently developing a mechanism for the gateway controller and signaling gateway to interact.

The signaling gateway must receive packets arriving from the PSTN from the three lower levels of the SS7 signaling system (levels of the MTP message transfer subsystem) and transmit signaling messages from the upper, user level to the gateway controller. The signaling gateway must also be able to transmit Q.931 signaling messages coming from the PSTN over the IP network.

The main focus of the SIGTRAN working group is on developing the most efficient mechanism for transmitting signaling information over IP networks.

It should be noted that there are several reasons why we had to abandon the use of TCP for this purpose. The SIGTRAN working group proposes to use the Stream Control Transport Protocol (SCTP) for transmitting signaling information, which has a number of advantages over the TCP protocol, the main one of which is a significant reduction in the delivery time of signaling information and, consequently, the connection establishment time - one of the most important parameters quality of service.

If the PSTN uses signaling over dedicated signaling channels (DSC), then the signals first arrive along with user information at the transport gateway, and then are transmitted to the gateway controller without the mediation of the signaling gateway.

Note that MGCP is an internal protocol for exchanging information between functional blocks of a distributed gateway, which externally appears to be a single gateway. The MGCP protocol is a master/slave protocol. This means that the gateway controller is the master, and the gateway itself is the slave device, which must execute all commands coming from the Call Agent controller.

The above solution provides network scalability and ease of network management through the gateway controller. Gateways do not have to be smart devices, require less processor power, and therefore become less expensive. In addition, new signaling protocols or additional services are introduced very quickly, since these changes only affect the gateway controller and not the gateways themselves.

The third approach, proposed by the IETF (MEGACO Working Group), is well suited for the deployment of global IP telephony networks that replace traditional telephone networks.

Let's consider algorithms for establishing and destroying connections using the MGCP protocol. The first example covers the interaction of the MGCP protocol with the SS7 protocol (Figure 1.12).

Figure 1.12. Establishing and tearing down a connection using MGCP (Example 1)

1) A connection request is received from the telephone exchange ATS-A to the signaling gateway SG1 via a common signaling channel in the form of an IAM message of the ISUP protocol. In Figure 1.12, signaling gateways SG1 and SG2 are combined with transport gateways TGW1 and TGW2, respectively. Gateway SG1 transmits the IAM message to the gateway controller, which processes the request and determines that the call should be routed to the ATS-B through TGW2.

2) The controller reserves the TGW1 gateway port (talk channel). For this purpose, it sends the CreateConnection command to the gateway. Note that the TGW1 gateway port can only receive information (“recvonly” mode), since it is not yet aware of which address and how it should transmit information.

3) In response to this command, the TGW1 gateway returns a description of the communication session parameters.

4) Having accepted the response from TGW1, the controller sends a CRCX command to the second gateway TGW2 in order to reserve a port in this gateway.

5) TGW2 selects the port that will participate in the connection and acknowledges receipt of the CRCX command. Using two CRCX commands, a unidirectional conversation channel is created for transmission to the caller acoustic signals or voice prompts and notifications. At the same time, the TGW2 gateway port can not only receive, but also transmit information, since it has received a description of the communication parameters from the oncoming gateway.

7) The ATS-B station responds to the IAM message with an ACM confirmation, which is immediately forwarded to the ATS-A station.

8) After the called subscriber accepts the call, ATS-B sends an ANM message to the gateway controller.

10) TGW1 performs and confirms the mode change.

11) The controller transmits the ANM message to the ATS-A, after which the conversational phase of the connection begins.

12) Completion of the conversational phase occurs as follows. In our case, caller B hangs up first. ATS-B transmits a REL message through the signaling gateway to the gateway controller.

13) Having received the REL message, the gateway controller terminates the connection with the called subscriber.

14) The gateway confirms the completion of the connection and transmits the statistical data collected during the connection to the controller.

15) The gateway controller transmits an RLC message to the ATS-B to confirm the release.

16) In parallel, the controller terminates the connection with the calling party

17) Gateway TGW1 confirms the completion of the connection and transmits statistical data collected during the connection to the controller.

18) ATS-A confirms the completion of the connection by sending an RLC message, after which the connection is considered destroyed.

Figure 1.13. Establishing and tearing down a connection using MGCP (Example 2)

The second example illustrates the interaction of the MGCP protocol with the SS7 and H.323 protocols (Figure 1.13).

1) A connection request (IAM message) is received from the telephone exchange ATS-A to the signaling gateway SG1 via a common signaling channel. In Figure 1.13, signaling gateway SG1 is also combined with transport gateway TGW1. Gateway SG1 transmits the IAM message to the Gateway Controller, which processes the request and determines that the call should be routed to the called user's endpoint, an H.323 terminal.

2) The gateway controller reserves the TGW1 gateway port (talk channel). For this purpose, it sends the CreateConnec-tion command to the gateway. And in this example, the TGW1 gateway port can only receive information (“recvonly” mode).

3) In response to the received command, the TGW1 gateway returns a description of the communication parameters.

4) Having received the response from the TGW1 gateway, the controller sends an ARQ message with the alias address of the called subscriber to the H.323 network gatekeeper.

5) In response to the ARQ message, the gatekeeper sends an ACF message indicating the transport address of its signaling channel.

6) The controller sends a SETUP connection request to the transport address of the gatekeeper signaling channel, using the Fast Start procedure. The gatekeeper forwards the SETUP message to the called terminal.

7) The called terminal sends an ARQ request for access to network resources.

8) In response to the ARQ request, the gatekeeper sends an acknowledgment of the request to the ACF.

9) The called terminal sends an ALERTING message, which the gatekeeper routes to the gateway controller. In this case, the called user is given a visual or acoustic signal of an incoming call, and the calling user is given an indication that the called user is not busy and is receiving a call signal.

10) The controller converts the ALERTING message into an ACM message, which is immediately forwarded to the ATS-A.

11) After the called user accepts the incoming call, the controller will receive a CONNECT message.

12) The gateway controller changes the “recvoonly” mode in the TGW1 gateway to full duplex mode.

13) TGW1 performs and confirms the connection mode change.

14) The controller transmits the ANM message to the ATS-A, after which the conversational phase of the connection begins, during which the calling user’s equipment transmits voice information packaged in RTP/UDP/IP packets to the transport address of the RTP channel of the called subscriber’s terminal, and the latter transmits packetized voice information to the transport address of the RTP channel of the calling subscriber's terminal. Using the RTCP channel, information transmission over the RTP channel is controlled.

15) After the end of the conversation phase, the connection destruction phase begins. The user equipment initiating the connection failure must stop transmitting voice information, close the logical channels and send a RELEASE COMPLETE message, after which the signaling channel is closed.

16) The gateway controller sends a RELEASE message to ATS-A to terminate the connection.

17) In addition, the controller sends the DLCX command to the gateway.

18) The gateway confirms the completion of the connection and transmits the statistical data collected during the connection to the controller.

19) After the above actions, the controller and terminal equipment notify the gatekeeper about the release of the occupied bandwidth. For this purpose, each of the connection participants sends a DRQ connection exit request to the gatekeeper via the RAS channel, to which the gatekeeper must send a DCF confirmation.

20) A confirmation of RLC disconnection comes from ATS-A, after which the connection is considered destroyed.

It should be noted that the interaction algorithm between the SIP and MGCP protocols is not very different from the algorithm described above.

The MEGACO working group of the IETF continues to work on improving the gateway control protocol, within the framework of which the MEGACO protocol has been developed, which is more functional than MGCP.

The International Telecommunication Union, in draft version 4 of recommendation H.323, introduced the principle of gateway decomposition. The distributed gateway functional blocks will be controlled by the gateway controller - Media Gateway Controller - using the MEGACO protocol adapted to H.323, which is called Gateway Control Protocol in the H.248 recommendation.

The messages of the MEGACO protocol differ from those of the MGCP protocol, but the procedures for establishing and destroying connections using both protocols are identical, so a description of the procedure for establishing a connection based on the MEGACO protocol is not given here.

1.4 Comparison of approaches to building an IP telephony network

ip telephony cryptographic authentication tacacs+

Currently, the H.323 and MGCP protocols are suitable for building well-functioning and PSTN-compatible IP telephony networks. As already noted, the SIP protocol interacts somewhat worse with the signaling systems used in the PSTN.

The approach based on the use of the MGCP protocol has a very important advantage over the approach proposed by the ITU in recommendation H.323: the gateway controller supports SS7 signaling and other types of signaling, as well as transparent transmission of signaling information over the IP telephony network.

The main disadvantage of the third approach presented in this paragraph is the incompleteness of the standards.

The functional components of distributed gateways developed by different telecommunications equipment manufacturers are practically incompatible.

The functions of the gateway controller are not precisely defined. The mechanisms for transferring signaling information from the signaling gateway to the controller and in the opposite direction are not standardized.

Disadvantages also include the lack of a standardized protocol for interaction between controllers. In addition, MGCP is a gateway control protocol, but is not intended to control connections involving user terminal equipment (IP phones).

This means that in a network built on the MGCP protocol, a gatekeeper or SIP server must be present to manage the terminal equipment.

It is also worth noting that in existing applications For IP telephony, such as the provision of international and long-distance communication services, it is not practical to use the MGCP protocol (as well as the SIP protocol) due to the fact that the overwhelming majority of IP telephony networks today are built on the basis of the H.323 protocol. The operator will have to build a separate IP telephony network based on the MGCP (or SIP) protocol, which is associated with significant capital investments. At the same time, a telecom operator with H.323 standard equipment can join existing IP telephony networks.

In the last of the approaches mentioned (in draft version 4 of Recommendation H.323), ITU-T introduced the gate decomposition principle used in the third approach.

The distributed gateway functional blocks will be controlled by the gateway controller - MGC (Media Gateway Controller) using the MEGACO/H.248 protocol. The draft version 4 of the H.323 recommendation also provides for the possibility of transparent transmission of SS7 signaling and other types of signaling over IP telephony networks and processing of all types of signaling by the gatekeeper without conversion into H.225.0 signaling messages.

The information presented in this chapter is by no means sufficient to draw final conclusions regarding the prospects for using one or another IP telephony protocol, although the first impression may already be formed. In the following chapters, the authors will try to provide more in-depth information on this topic, but they undertake not to impose any one point of view on the reader, but to give him everything he needs to draw the appropriate conclusions himself.

1.5 System optionsIP telephony(scripts)

There are three most commonly used IP telephony scenarios:

- “computer-to-computer”;

- “computer-phone”;

- “telephone-telephone”.

The computer-to-computer scenario is implemented based on standard computers equipped with multimedia and connected to the Internet.

The components of the computer-to-computer IP telephony model are shown in Figure 1.14. In this scenario, analog speech signals from subscriber A's microphone are converted to digital form using an analog-to-digital converter (ADC), typically at 8000 samples/s, 8 bits/sample, resulting in 64 Kbps.

The digital speech data samples are then compressed by an encoder to reduce the bandwidth needed to transmit them by a ratio of 4:1, 8:1 or 10:1. Speech compression algorithms are discussed in detail in the next chapter. The output data after compression is formed into packets, to which protocol headers are added, after which the packets are transmitted through the IP network to the IP telephony system serving subscriber B.

When the packets are received by Subscriber B's system, the protocol headers are removed and the compressed speech data is sent to a device that decompresses it into its original form, after which the speech data is again converted to analog form using a digital-to-analog converter (DAC) and ends up in Subscriber B's phone.

For a typical connection between two subscribers, IP telephony systems simultaneously implement both transmit and receive functions at each end.

The IP network shown in Figure 1.14 means either global network Internet or corporate intranet of an enterprise. Description of the protocols used in IP networks, including protocols for transmitting voice information over an IP network.

Figure 1.14 Computer-to-Computer IP telephony scenario

To support the computer-to-computer scenario, it is desirable for the Internet service provider to have a separate server (gatekeeper) that converts user names into dynamic IP addresses. The scenario itself is aimed at a user who needs the network mainly for data transmission, and requires IP telephony software only occasionally for conversations with colleagues.

Effective use telephone communication in the computer-to-computer scenario, it is usually associated with increasing the productivity of large companies, for example, when organizing a virtual presentation on a corporate network with the ability not only to see documents on a Web server, but also to discuss their contents using an IP phone.

Similar documents

Consideration of the features of the development of a complex for automating the analysis of attempts at external penetration and control local connections for the telephony server. General characteristics of the SSH protocol, main versions. Analysis of basic password authentication.

course work, added 02/22/2013


Prospects for the development of IP telephony (Internet telephony). Internet network and IP protocol. History of the development of IP telephony. Advantages of using IP telephony. IP telephony quality indicator. Payment system for IP telephony billing and management services.

course work, added 05/16/2008


Structure of the TCP/IP protocol. Interaction of circuit and packet switching systems. Characteristics of a packet switching network. Services provided by OJSC MGTS using a packet switching network. Calculation of the implementation efficiency of the designed network.

thesis, added 05/22/2012


Basic concepts of IP telephony, structure of IP telephony networks. ASU network structure. Cisco Systems solutions for IP telephony. Cisco Routers Systems. Catalyst 2950 series switch. IP phone. Setting up a VPN network. Methods and means of protecting information.

thesis, added 09/10/2008


The emergence of the concept of a multi-level hierarchical structure of a telephone network. Electronic technology, which made it possible to transfer all means of telephony to element base. Development of IP telephony, providing voice transmission over packet switching networks.

abstract, added 12/06/2010


The use of an IP address in the TCP/IP protocol, its role in organizing a connection to the Internet. The concept of a subnet mask. Data required to configure the TCP/IP protocol. A mechanism for testing its configuration and connection to networks using utilities.

presentation, added 11/02/2014


Coordination of various IP telephony scenarios. Transmission of voice and video using IP telephony. Methods for viewing an image that is transmitted to the interlocutor. Size of audio buffers and subscriber call delay.

test, added 02/20/2011


Basics of IP telephony: communication methods, advantages and standards. Development of a scheme for the main communication channel for organizing IP telephony. Functions of a mobile control point. Development of a backup communication channel scheme for organizing IP telephony.

course work, added 10/11/2013


IP telephony and Wi-Fi technology. The need to introduce mobile office network IP telephony, its design plan. Setting up the Yeastar MyPBX 400 server to connect to the Zebra Telecom operator. Calculation of capital costs and operating costs.

thesis, added 02/19/2013


History of the activities of the Moscow city telephone network. Structure of the TCP/IP protocol. Interaction of circuit and packet switching systems. Characteristics of a packet switching network. Services of a promising network, economic efficiency of its implementation.

IP telephony is increasingly being used in companies. It increases the efficiency of doing business and allows you to carry out many previously impossible operations (for example, integration with CRM and other business applications, reducing the costs of building and operating telecommunications infrastructure, creating effective Call centers, reducing the total cost of system ownership, etc. ). However, the active development of IP telephony is hampered by the fact that many rumors about its low security circulate around this technology. Cisco Systems has proven that this is not the case and this publication is intended to debunk existing myths about the insecurity of IP telephony.

It should be noted right away that Cisco is the only manufacturer that provides protection for the IP telephony infrastructure at all its levels, from the transport environment to voice applications. This is achieved by implementing solutions as part of the Cisco Self-Defending Network initiative. High level The security of Cisco Systems solutions is confirmed by independent testing laboratories. In particular, NetworkWorld magazine (http://www.nwfusion.com/reviews/2004/0524voipsecurity.html) tested several IP telephony solutions and only Cisco gave the highest possible rating of "SECURE" ("secure").

1. IP telephony does not protect against eavesdropping

Cisco IP telephony solutions use several technologies and mechanisms to ensure the confidentiality of transactions. Firstly, it is the allocation of voice traffic to a dedicated network segment and delimitation of access to the voice stream by using access control rules on routers and firewalls. Secondly, all voice traffic can be protected from unauthorized eavesdropping using virtual private network (VPN) technology. The IPSec protocol allows you to protect telephone conversations even over public networks, such as the Internet. And finally, Cisco has implemented in its IP phones the SecureRTP (SRTP) protocol, specially designed to ensure the confidentiality of the voice stream, which does not allow outsiders to penetrate the secrets of telephone conversations.

2. IP telephony is susceptible to infection by worms, viruses and Trojans

To protect the IP telephony infrastructure from infection by various malware, Cisco offers a number of protective measures that allow you to build a layered defense that prevents not only the introduction, but also the spread of worms, viruses, Trojan horses and other types of malicious activity. The first line of defense is the use of firewalls and attack detection and prevention systems, along with antivirus software from Cisco partner companies, to restrict access to the IP telephony infrastructure.

The second line of defense is based on the use of antiviruses and attack prevention systems on end nodes participating in the IP telephony infrastructure - Cisco IP SoftPhone, Cisco CallManager, Cisco Unity, Cisco IP Contact Center (IPCC) Express, Cisco Personal Assistant, Cisco IP Interactive Voice Response etc.

The last, but not the least important line of defense is the Network Admission Control initiative proposed by Cisco Systems. As part of this initiative, all workstations and servers that do not comply with the security policy (including those with uninstalled anti-virus software) will not be able to access the corporate network and cause damage to its resources.

3. IP telephony does not protect against spoofing of phones and control servers

To protect against devices trying to disguise themselves as authorized IP phones or unauthorized connected to the network infrastructure, Cisco suggests using not only the above-mentioned access control rules on routers and firewalls, but also developed means of strict authentication of all subscribers of the IP telephony infrastructure ( including the Call Manager management server), which uses various standardized protocols to authenticate, including RADIUS, X.509 PKI certificates, etc.

4. An attacker with administrative rights can disrupt the functioning of the 1P telephony infrastructure

CallManager provides advanced capabilities to grant various system administrators only the rights they need to perform their responsibilities. Such rights may include read-only access to specific settings, complete lack of access to them, access to change, etc.). In addition, all actions performed by the administrator are recorded in a special log and can be analyzed at any time in search of traces of unauthorized activity.

The configuration of IP phones and their interaction with CallManager is managed via a channel protected from unauthorized access, preventing any attempts to read or modify control commands. To protect the control channel, various standardized protocols and algorithms are used - IPSec, TLS, SHA-1, etc.

5. CallManager is not secure because it is installed on the Windows platform

Despite the fact that the CallManager IP telephony infrastructure management server is installed on the Windows platform, it does not have any weaknesses inherent in this platform. This is due to the fact that CallManager runs a secure and optimized Windows versions in which:

• all unnecessary services and accounts are disabled,
• all necessary and regularly updated patches are installed,
• security policy is configured.

6. IP telephony is easy to fail

Although various components of IP telephony are potentially susceptible to denial of service attacks, Cisco Systems solutions offer a range of protective measures that prevent both DoS attacks and their consequences. To do this, you can use the provisioning mechanisms built into network equipment information security, as well as additional solutions offered by Cisco Systems:

• Dividing the corporate network into non-overlapping voice and data transmission segments, which prevents common attacks from occurring in the “voice” section, incl. and DoS.
• Application of special access control rules on routers and firewalls that protect the perimeter of the corporate network and its individual segments.
• Application of an attack prevention system on Cisco Secure Agent nodes.
• Application of a specialized protection system against DoS and DDoS attacks Cisco Guard and Cisco Traffic Anomaly Detector.
• Applying special settings to network equipment Cisco, which prevent address spoofing, which is often used in DoS attacks, and limit bandwidth, which does not allow the attacked resources to be disabled by a large flow of useless traffic.

IP phones themselves contain a number of special settings that prevent unauthorized access to them. Such settings include, for example, access to phone functions only after presenting an identifier and password, or prohibiting local changes to settings, etc.

In order to prevent the loading of unauthorized modified software and configuration files onto the IP phone, their integrity is controlled by an electronic digital signature and X.509 certificates.

8. CallManager can be overloaded with a large number of calls

The maximum number of calls per hour per CallManager server is up to 100,000 (depending on configuration) and this number can be increased to 250,000 when using a CallManager cluster. At the same time, there are special settings in CallManager that limit the number of incoming calls to the required value. In addition, in case of loss of connection with one of the CallManagers, automatic re-registration of the IP phone on the backup CallManager is possible, as well as automatic change call route.

9. It’s easy to commit fraud in IP telephony

The IP telephony infrastructure management server CallManager contains a number of features that help reduce the likelihood of telephone fraud depending on its type (theft of services, falsification of calls, refusal of payment, etc.). In particular, for each subscriber you can:

• block calls both to and from certain groups of numbers,
• block the ability to forward calls to various types of numbers - landline, mobile, intercity, international, etc.,
• filter calls based on various parameters,
• etc.

10.Traditional telephony is more secure than IP telephony

This is the most common myth that exists in the field of telephony. Traditional telephony, developed decades ago, is much less secure with the new and more advanced IP telephony technology. In traditional telephony, it is much easier to connect to someone else’s conversation, spoof a number, “flood” calls and many other threats, some of which have no analogues in IP telephony (for example, war dialing). The security of traditional telephony is provided by much more expensive tools and mechanisms than in IP telephony, in which these tools are built into the components of this technology themselves. For example, to protect against eavesdropping, the traditional one uses special devices - scramblers, the centralized control of which is impossible; not to mention the cost of purchasing and installing them in front of each telephone set.

Gone are the days when operators were wary of using IP telephony, considering the level of security of such networks to be low. Today we can already say that IP telephony has become a kind of de facto standard in telephone communications. This is explained by the convenience, reliability and relatively low cost of IP telephony compared to analog communications. It can be argued that IP telephony improves business efficiency and allows for previously unavailable operations such as integration with various business applications.

If we talk about the shortcomings and vulnerabilities of IP telephony, first of all we should note the same “diseases” that other services using the IP protocol suffer from. This is a susceptibility to attacks by worms and viruses, DoS attacks, unauthorized remote access, etc. Despite the fact that when building an IP telephony infrastructure, this service is usually separated from network segments that carry non-voice data, this is not a guarantee security. Today, a large number of companies integrate IP telephony with other applications, such as email. On the one hand, this creates additional conveniences, but on the other, new vulnerabilities. In addition, the functioning of an IP telephony network requires a large number of components, such as support servers, switches, routers, firewalls, IP phones, etc. At the same time, non-specialized operating systems are often used to support the functioning of an IP network. For example, most IP PBXs are built on common and well-known operating systems (Windows or Linux), which theoretically have all the vulnerabilities characteristic of these systems.

Some IP PBXs use DBMS and web servers that have their own vulnerabilities. And although for universal operating system or protocol stack, you can use well-known security tools - antiviruses, personal firewalls, attack prevention systems, etc., the lack of “tailored” such tools for working with IP telephony applications can negatively affect the level of security.

Among the main threats to which the IP telephone network is exposed are:

• registering someone else's terminal, allowing you to make calls at someone else's expense;
• subscriber substitution;
• making changes to voice or signaling traffic;
• reduction in the quality of voice traffic;
• redirection of voice or signaling traffic;
• interception of voice or signaling traffic;
• voice message spoofing;
• ending a communication session;
• denial of service;
• remote unauthorized access to IP telephony infrastructure components;
• unauthorized software update on an IP phone (for example, for the purpose of introducing a Trojan or spyware);
• hacking the billing system (for operator telephony).

This is not a complete list of possible problems associated with the use of IP telephony. The VoIP Security Alliance (VOIPSA) has developed a document describing a wide range of IP telephony threats, which in addition to technical threats includes VoIP extortion, spam, etc.

And yet, the main weak point of IP telephony is the annoying human factor. The problem of security when deploying an IP telephone network is often relegated to the background, and the choice of solution is made without the participation of security specialists. In addition, specialists do not always configure the solution properly, even if it has the appropriate protection mechanisms, or they purchase protection tools that are not designed to effectively process voice traffic (for example, firewalls may not understand the proprietary signaling protocol used in the IP telephony solution ). Ultimately, the organization is forced to expend additional financial and human resources to protect the deployed solution or accept its insecurity.

What to build?

From the point of view of manageability and performance, the most preferable IP telephony architecture seems to be one in which all security components are built into the elements of the network itself. If we consider an IP telephone network without using additional funds protection, then by using the security mechanisms built into network switches, it is possible to achieve relatively strong protection against attacks on the perimeter. Built-in functionality allows you to:

• the ability to create virtual local networks (VLANs) using the built-in capabilities of switches;
• use of built-in filtering and access control mechanisms;
• limitation and representation of guaranteed bandwidth, which allows you to effectively suppress DoS attacks;
• limiting the number of devices with different MAC addresses connected to one port;
• preventing attacks on the consumption of the DHCP service address pool;
• preventing ARP table clogging and address theft;
• preventing attacks from anonymous addresses;
• the use of access control lists that limit the addresses of hosts that can transmit data to IP phones.

In addition, the call control system built into the IP network architecture, which can connect to a special dedicated local network, isolated from the organization's production network, represents an additional “frontier” in protection. The disadvantages include the fact that the protective functions built into network equipment do not always provide the appropriate level of security and additional investments in upgrading the equipment may be required to increase it.

Despite the underlying use of the IP protocol, IP telephony cannot always be adequately protected by traditional solutions. This is due to the fact that they do not take into account its specifics - real-time traffic transmission, quality control and traffic at the application level, etc. Ideally, IP telephony applications and their security are inextricably linked and integrated into a single platform, including network infrastructure. This allows you to increase the effectiveness of protection and reduce its costs. Otherwise, you have to build four independent or practically non-overlapping infrastructures: LAN, IP telephone network, LAN security and IP telephony security infrastructure.

The use of specialized firewalls significantly increases the security of an IP telephone network, for example, by filtering traffic based on the connection state ( stateful inspection), which allows only necessary traffic and connections established in a certain direction (from server to client or vice versa) to pass through. In addition, the firewall provides the ability to:

• filtering traffic for managing the installation of IP telephone connections;
• transmission of control traffic through NAT and network tunnels;
• TCP interception, which ensures that TCP sessions are closed, allowing protection against a range of denial of service (DoS) attacks.

When designing a network that involves the use of additional security tools, for example, an attack detection or prevention system, special attention should be paid to the choice of the manufacturer of such tools, since the issue of managing a heterogeneous IP network cannot always be resolved effectively and quickly and almost always requires serious additional investments.

It is preferable to choose the manufacturer whose equipment already operates the network, since support and management of devices can be carried out in this case centrally and at lower costs.

Eavesdropping protection

The most advanced way to counter such manipulations is to use IP phones with built-in encryption. In addition, encryption of traffic between phones and gateways provides additional security. Today, almost all manufacturers, such as Avaya, Nortel and Cisco, offer built-in encryption for information flows and signaling. Traffic encryption is the most logical solution to protect against wiretapping, but this functionality also brings with it a number of difficulties that must be taken into account when building secure communications. The main problem may be the latency added by the process of encrypting and decrypting traffic. When working on a local network, such a problem, as a rule, does not make itself felt, but when communicating through a geographically distributed network it can cause inconvenience. In addition, signaling encryption that occurs at the application layer can make it difficult for firewalls to operate. When using stream encryption, the delays are much lower than when using block ciphers, although it will not be possible to completely get rid of them. A solution to the problem could be faster algorithms or the inclusion of QoS mechanisms in the encryption module.

QoS

Protection against spoofing of phones and control servers

Protection against DoS attacks

• division of the corporate network into non-overlapping segments of voice and data transmission, which prevents common attacks, including DoS, from occurring in the “voice” section;
• special access control rules on routers and firewalls that protect the perimeter of the corporate network and its individual segments;
• attack prevention system on the call control server and PC with voice applications;
• specialized protection systems against DoS and DDoS attacks;
• special settings on network equipment that prevent address spoofing and limit bandwidth, preventing the attacked resources from being damaged by a large flow of useless traffic.

IP phone protection

Protection against fraud in the IP telephone network

Standards in IP telephony

Conclusion

Among the primary requirements for ensuring the security of an IP telephone network is the need to separate voice and regular data. That is, IP telephony must be separated from the network where other data is transmitted using VLAN. Segmentation allows you to create an additional barrier that prevents attacks and abuses, including those whose source is on the internal network. Additionally, when designing an IP telephony network, it is important to ensure adequate bandwidth and not forget to use QoS mechanisms to prioritize IP telephony traffic.

And finally, the use of security tools focused on the specifics of IP telephony will help avoid not only “holes” in the security of the constructed network, such as “misunderstanding” of IP traffic security tools, but also additional financial expenses for upgrading existing equipment or purchasing new protective devices.