Russian call center: Ekaterinburg Naumen + SIP-Gateway assembly Novosibirsk, the results

Gateway of domestic production (development, debugging, surface mounting)

Hello!

We have here tested the joint work of the contact center of the domestic vendor Naumen and the voice trunk gateway SMG-2 of the Russian company Eltex. These two pieces together give a full-fledged domestic call center.
')
This decision differs from others in that it fits the concept of "import substitution." When I hear this word, I am already twitching: on the market now, many are simply re-sticking a sticker and writing documentation in Russian. But everything is just as it should.

More details

So, I am from the department of telecommunications of the KROK company. Our team is engaged in the design and implementation of contact centers. Most of the work has historically been associated with Avaya - yet this vendor is well known to everyone on the Russian market. Now we have completed a fairly extensive testing of solutions from Yekaterinburg Naumen and Novosibirsk Eltex.

Naumen is a Russian company with 15 years of experience in developing software solutions in the contact center market. They do “all in one”, providing solutions to most tasks within a single product: auto-dialing, managing incoming and outgoing calls, IVR, recording conversations, questioning, quality management, support mail, fax, SMS, web chat, Skype and much more another. They promise five nines of reliability - 5 minutes of downtime per year maximum. The most important thing for us is the SIP protocol and the ability to use VoIP gateways and subscriber terminals of various manufacturers. At the same time, “Naumen” does not make its own iron, which means that contact centers still needed to be built (before that) on the iron of someone from the United States or China. And when it comes to iron from the United States, I immediately recall Avaya, which has related solutions.

As a VoIP gateway, we were interested in using equipment from Eltex , a Russian company with more than 23 years of history, a developer and manufacturer of telecommunications equipment with its own production, including surface-mounted lines. All Eltex hardware runs on its own developed software.

As for the “Russian production” ... - I think it is as Russian as it is generally possible today in principle. Naturally, the entire component base (chips, transistors, etc.) comes from the world's leading manufacturers. Here it is specifically Marvell Technology Group, Broadcom Corporation, Silicon Laboratories, PMC-Sierra International, Mindspeed Technologies, Inc., Infineon Technologies. But Eltex, unlike many other Russian manufacturers (who order assembly of products in the countries of Southeast Asia), not only design and make traces of printed circuit boards themselves, but also have their own surface-mount lines, i.e., electronic manufacturing lines printed circuit boards using element base. The full development cycle - from circuitry to debugging - is also in Russia. They themselves write their software.

Go!

What is the SMG-2 gateway? In fact, it is a protocol converter between TDM and VoIP-networks. SMG-2 in the base delivery supports one E1 stream (SS-7, DSS-1) and 32 VoIP channels (SIP). When you purchase an additional license, you can activate the second E1 stream and expand the number of VoIP channels to 64. The gateway provides rich call management capabilities (routing by the called and calling number, RADIUS routing, modification of the number before and after routing, use of several numbering plans), supports a large set of voice codecs (G.711, G.729, G.723.1, G.726) and hardware transcoding of media streams. Voice processing quality is also achieved due to the possibility of using echo cancellation mechanisms, silence detector, comfort noise generator, as well as traffic prioritization (QoS). All this is packaged in a small box of desktop execution. Here in this:

We used the gateway for outbound calls initiated by the Naumen contact center to route calls to the network of traditional TDM telephony.

From the Naumen Contact Center side, you need to register a gateway and configure call routing through this gateway. To do this, open the “Administration” tab and select the “Servers and Routing” item in the “Contact Center Configuration” section:

Next, to add a gateway to the system, select the Gateways tab, click the Add Gateway button, and in the window that opens, set the gateway parameters. In our case, we use the SIP protocol to work with the gateway, and SMG-2 with the IP address 172.23.32.44 expects us to receive SIP messages on the udp port 5060:

To route calls through a designated gateway, you need to add a routing rule of the type “Routing to an arbitrary number”:

In the rule we prescribe that all calls where the called number corresponds to pattern 98 ([0-9] {10}) (i.e. the called number starts at 98 and contains further 10 arbitrary digits), we do not change (what does the pattern actions $ {0}) redirect to the previously registered gateway:

For correct DTMF transmission, we used RFC2833, that is, DTMF transmission in RTP packets. By default, Naumen uses SIP INFO messages with DTMF MIME Type - application / dtmf for this purpose. To change the DTMF transmission method, you need to correct the configuration of the nautel service. To do this, you must set the FormatDTMF parameter in the nautel.xml contact center configuration file to the value "0":

[root@localhost ~]# cat /opt/naumen/nauphone/spool/nautel/cfg/nautel.xml <?xml version="1.0" encoding="utf-8" standalone="no" ?> <Config type="phone"> <Config type="h323"> <Var name="Enable" type="bool" value="false"/> </Config> <Config type="sip"> <Var name="Enable" type="bool" value="true"/> <Var name="AutoCalcListenUDPPort" type="bool" value="true"/> <Var name="AutoCalcListenTCPPort" type="bool" value="true"/> <Var name="ListenUDPPort" type="int" value="5070"/> <Var name="ListenTCPPort" type="int" value="5070"/> <Var name="FormatDTMF" type="int" value="0"/> </Config> </Config>    nautel    : [root@localhost ~]# naucore service nautel restart stopping service <nautel> ... service <nautel> offlined starting service: <nautel> ... service <nautel:0> started

On this, in fact, the settings from the Naumen Contact Center and ended.

Gateway Setup

Setting up the gateway will take a little longer. We need to configure the E1 flow for access to the TDM network, SIP interface, trunk groups and numbering plan for call routing.

For access to the TDM network, we used both the OKS-7 signaling system and Q.931 ISDN PRI signaling.
In the first case, the setting of the E1 stream looked like this:

Here we set the name, select the signaling protocol, the type of the linear code, the group of lines OKS-7, the channel number that is used as the D-channel (the 16th in our case), and turn on the stream. On the “Channel Setup” tab, we define the ISUP CIC channel ID codes. In our case, we use 15 E1 stream time slots:

The screenshot shows that we have given all 15 time slots to the TDM trunk group (which we will specify later).
Next, we need to register a group of lines ACS-7. It is necessary to set the access category if we use the differentiation of call rights from the incoming channel to the outgoing and numbering plan (by default, the system has 1 numbering plan). The remaining settings are largely dependent on the remote side, so I can not give clear recommendations on their values:

Configuring ISDN PRI is somewhat easier. We turn on the flow, select the signaling protocol (Eltex in our case acts as the user side), access category, numbering plan. The remaining parameters again depend on the remote side:

We use 15 time-slots of the stream and give them under the trunk group TDM. This is done on the “Channel Usage” tab:

Next, you need to create and configure a SIP interface, which sets the basic configuration parameters of the SIP stack. As in the E1 stream settings, we set the name, access category and numbering plan. The remaining settings are specific to the SIP protocol.

The “Mode” field sets the protocol for the interface (SIP / SIP-T / SIP-I), in the “Host name / IP address” field, enter the IP address of the Naumen contact center, “SIP signaling destination port” is set to the port value , which “listens” to the nautel service on the Naumen server, we do not change other parameters on this tab. We recall the fact that we use the recommendation of RFC 2833 for DTMF transmission, and go to the tab “Configure codecs / RTP”:

There, in addition to setting the value of the "DTMF transmission method" field, note the used codecs.
We left other parameters of the SIP interface unchanged.
In terms of numbering, prefixes for entering trunk groups are specified. There are 2 main criteria by which calls are routed on the device:
• search by caller's number - CgPN (Calling Party Number);
• search by callee number - CdPN (Called Party Number).

We will use direct prefix routing, i.e., access to the prefix without analyzing the number of the calling or called subscriber. This method is designed to switch all calls from one trunk group to another, regardless of the number dialed (without creating masks in the prefixes). Therefore, our prefixes look pretty simple:

The prefix type is a trunk group, but since we have not created a single trunk group, the “Object” field indicates a non-existent trunk group 255. Two prefixes were created - 0 and 1. The prefix 0 corresponds to the TDM trunk, and the prefix 1 - SIP trunk in the direction of Naumen. Trunks in prefixes we prescribe after creating trunks.

I will comment on already created trunk groups:

Trunk group 0 is a SIP trunk group that routes all incoming calls without analyzing the number of the calling or called subscribers to the previously created direct prefix 0, corresponding to the TDM direction:

Trunk group 1 connects 15 time slots of the E1 stream and routes all incoming calls to the direct prefix 1, corresponding to the SIP direction:

Let's go back to the numbering plan and write the trunk groups created in the numbering plan prefixes:

That's all. The above settings allow the gateway to successfully receive incoming SIP calls from the Naumen contact center and redirect them to the TDM network.

A couple of words about Eltex

One of our customers, a financial institution, has an outbound dialing system installed. Calls go on E1 flows to one telecom operator.

The bank had an idea to call through the big three operators, and the call to the subscriber, for example, MTS, should go through the MTS provider. This will significantly reduce the cost of communication tariffs. Also, one of the new telecom operators is streaming via SIP. The outgoing call system equipment allows you to make calls up to 100 cps.
Total we have a task:

Accept calls to E1 streams, distribute them to telecom operators depending on the number being dialed.
To ensure the conversion of traffic from ISDN to SIP for one of the telecom operators.
Ensure system performance in 100 cps.

Existing system configuration:

Target system configuration:

Call routing is provided by Eltex BKP-M equipment.

Conversion of traffic produces voice gateway SMG-2016M.

Thus, all calls made by the outgoing call system are directed to the telecom operator whose SIM card belongs to the called subscriber. Calls to subscribers who do not belong to the big three are sent to the telecom operator through which they are cheaper to make.

Another test

Before connecting Eltex, we together with Naumen conducted load testing of the Naumen Contact Center 6.2 solution in the VMware vSphere virtualization environment. We deployed KC on the resources of the virtual data center CROC. The phone calls were emulated, which are placed in one queue and distributed to a group of emulated operators. In accordance with the test scenario, each operator talked from 60 to 120 seconds and filled out a questionnaire consisting of 3 forms and 15 parameters. As an operating system for nodes installed Oracle Enterprise Linux 6.4 x64. On the load generating nodes (loader), Ubuntu 12.04lts was used.

According to the results - the average number of simultaneously serviced calls (operators + ivr) - 1080 of them 450 on operators and 630 on ivr coincide with the calculated value. "Iron" servers show performance by about 20% higher than when working under the VMWare hypervisor.

Summary

Thus, we can confidently say that the schemes where Russian software works side by side with Russian iron are successfully implemented. They are being implemented faster due to the already prepared Russian documentation and live engineering support at hand, the possibility of faster software adaptation by the vendor to your needs. Well, it is worth adding about quite adequate prices, little dependent on exchange rates.