Download PDF in english
	Скачать PDF версию на русском языке

Usage of COTS VoIP products

Dr. Nazarov A.G, IntegrIT This e-mail address is being protected from spambots. You need JavaScript enabled to view it

The complexity of development grows up continuously and this changing the focus from the hardware to the software design. This is the common trend and there are several reasons for that: new protocols, requirements to support multiple services, interoperability issues and many more. In nowadays telephony services it is highlighted very much. The amounts of code even in the relatively simple devices may be several hundred lines and in more complex systems reaches millions. Development from the scratch may take hundreds man-month power so usage of ready-to-use VoIP COTS (Commercial Off-The-Shelf) components really shortens the development time, reduces the risk and total workload.

The short table below shows typical size of source codes for some VoIP components

Component	Size, thousand lines
codec G.729.1	50
codec AMR-NB	50
acoustic echo compensator	25
line echo compensator	20
RTP streamer	10
SIP client (depending on services provided)	65-100

Recently, 10-15 years ago most companies tried to make everything on their own because considered that it provides longer life for their designs. However, rapid grows of complexity changed the market picture. Also, many big silicon players (Texas Instruments, Freescale, Marvell, etc.) trying to complete their silicon with accompanying software that enables the benefits of new processors. For that they organized eco-systems around their solutions and attracted third parties to sell building blocks optimized for their chips. This created new type of companies – suppliers of COTS products. Now we observe division of labor which shows the maturity of this industry.

IntegrIT company is one of such suppliers. We are third party of many silicon vendors and propose a range of components ready for integration into existing and projected VoIP systems.

This paper describes some issues of use VoIP COTS products, their features and hardware adaptation.

Software architecture requirements

Big amounts of code demands new requirements for system architecture as well as for testing methodology at all levels. First and most obvious list of requirements are:

• system should be divided by levels with own responsibilities and interconnections

• components should be isolated from functional point of view and should be provided with clear interfaces. Components should be tested autonomously

• connections between components should be minimized

• software should have means for internal diagnostics

Indirectly, there is big desire to have cross-platform implementation. Cross-platform idea is a little bit cloudy thing because many people understand it differently. It may mean support of different processors, compilers, operating system, graphics and so on. However whatever it would mean it gets always desirable feature for hardware manufacturers because it promises easier extension of product line or adaptation to the new hardware or silicon.

VoIP components work in a hard real-time environment and framework, so there are additional requirements:

• predictable resource consumption

• no memory fragmentation

• recovery procedures after malfunction

• flexible configuration

• standardized common API for better intersystem integration

The latest issue is very important if people to decide use components from different vendors in a one product. Silicon vendors developed own standards for common API, particularly, Texas Instruments introduced XDAIS interface. Although it does not specify functional level API it guaranties most important features of COTS components:

• means for initialization and memory allocation

• multiple instantiation

• resource consumption

• name conventions

• no access to peripherals, special registers, interrupts

• no hidden backdoors to other components or resources

IntegrIT company uses subset of XDAIS API additionally providing cross-platform implementation and low CPU/memory use. Components already optimized for most popular cores such as C64+, ARM9e, ARM11 and provide minimum possible resource consumption per one VoIP channel.

Typical MIPS consumption figures

Component	ARM9e	ARM11	C64xx
G.729 (coder+decoder)	27	18	4.2
Acoustic echo canceller	75	44	6
Voice activity detection	4.2	2.7	0.7

Unit tests (ability to test the components separately) play important role at the integration phase. You may expect adequate behavior if all parts already exposed to their own strong test schedules. Otherwise, equipment may work improperly at different exploitation conditions – on different lines, non-interoperable with legacy equipment, etc.

This is especially important for those components that interfacing with analogue lines: echo cancellers, noise suppressors, voice activity detectors, codecs. IntegrIT company pays attention on this issue. Each component is supplied with reach test set, particularly, only the line echo canceller has 300 Mbytes of test data. Also, some components already tested by special equipment for speech quality assessment.

Next chapters show typical VoIP system architecture and a list of necessary blocks.

VoIP solution as a whole

Look at the VoIP stack proposed by IntegrIT. It is foundation for many different devices with VoIP functions: gateways, IP-PBX, conference servers, dispatcher boards, digital telephones and softphones.

It is divided by following levels:

• network protocols

• IP-telephony and extension services

• voice path

• system functions and drivers

VoIP levels

Higher level provides packet-based interface with networks and set of necessary standard protocols (ICMP, Telnet, TCP/UDP, TFTP, etc.). It provides standardized networking functions for all other components. However, it also contains lower layer functionality of SIP protocols that handles SIP dialogs between SIP agents, establishes and maintains connections between them.

VoIP engine and its components

IP-telephony level contains components for call setup, numbering plans, group addressing, access to extended services via short numbers, etc. Extended services are the core of this part and include:

• higher-level SIP protocol functions responsible for call transfer, line hold, conferencing, intervention, etc.

• state machines and timers to support all the phases of telephone calls of different types

• voice path control

Voice path is a most computationally intensive part and includes

• speech processing (echo/noise cancellation, codecs, etc.)

• conference mixer for hold-on and conference modes

• analogue signaling (call progress tones, Caller ID, DTMF detector/regenerator/rejector, etc.)

• RTP-streamer for speech packetization

• RTP-receiver to convert asynchronous RTP data into synchronous audio/TDM signal with dejitter and packet loss concealment

It is the most computationally intensive part and should be designed very accurate if there are many simultaneous calls should be processed.

The lowest layer (system functions and drivers) is highly hardware and operating system dependent part which includes:

• bootloader and error recovery subsystem

• filesystem and memory manager

• support of xml, zip and other necessary file formats for configuration and control

• set of peripheral drivers and API to real-time OS

All the layers may work asynchronously and connected via messages. Voice path requires real-time servicing because processes uninterrupted synchronous audio streams. That design gives reasonable reliability, flexibility and independence of sub-layers. Besides, it may be ported to multicore processors like OMAP. In that case, heavily loaded voice path is moved to the DSP core and works under DSP-BIOS, other components still work under Linux or other OS.

The table below summarizes interesting properties of sub-layers on some parameters

Sub-layer	Network protocols	IP-telephony and extended services	Voice path	System functions and drivers
OS dependence	moderate	low	low	strong
Processor dependence	moderate	low	strong	strong
Application dependence	low	strong	low	low
Total amount	moderate	big	big	low

As expecting, the last layer strongly dependent on OS and CPU type. However, amount of code is small enough.

Voice path software depends a lot on the CPU type because requires strong optimization for all specific core to provide maximum performance. However, COTS product vendors like IntegrIT already did this task and propose highly optimized components for most popular CPUs. So, taking into account the fact that voice path software is huge, buying the ready to use solution will give serious savings.

IP-telephony level depends mostly on the higher level gateway or application functionality. Definitely, FXS and FXO gateways are different, but also have many similarities because both should work with same numbering plans, route calls, supports groups in the same manner, etc. There is some inheritance and that is why the adaptation of existing solutions will be done much faster than development it from the scratch.

Networking layer normally does not depend on operating system very much but not in all cases. Linux-like OSes already support TCP-IP in their kernels, but for many other OSes (DSP-BIOS, ucLinux, etc.) designers should use some separate TCP-IP implementation. In those cases the adaptation of VoIP software to operating system environment may take some time and some tuning, particularly to minimize total delay or reduce peak CPU load.

Networking layer also includes specific VoIP functionality for RTP connection management and SIP dialogs. This part may cause increasing the total delay, problems in sharing common resources (memory defragmentation, etc.). In the multichannel high-performance systems that factors take a special priority so using of approved commercial solutions and components seems to be necessary. IntegrIT proposes own VoIP networking layer implementation adopted for different operating systems which already takes in account all the factors above.

Example gateway

Look how VoIP solution would be adopted to the gateway. The main purpose of the gateway is to make a bridge between internal analogue local telephone network to PSTN via extension lines and integration of this with modern digital phones. Besides, gateway should support many extended services like conferencing, call transfers and so on.

The gateway architecture is driven mostly by reliability and scalability requirements. There are 2 most used architectures: server-based systems and homogeneous (server-less). In the homogeneous case all the nodes already know topology (have own copies of address books) and each node exclusively servicing the number of lines. So, if some part of system is broken it is not affect to others. In a server-based architecture there are special servers for call establishment (SIP-servers) and extended service units for conferencing, information and so on. In that case SIP server overload or unavailability causing total system outage. SIP signaling is capable to work in both architectures, so potentially homogeneous configuration may be added with additional SIP-servers or conference units. That is why we may consider it as more generic case.

Gateway nomenclature includes:

• FXS gateway providing the access to the analogue telephone endings (phone sets)

• FXO gateway providing the access to PSTN via the analogue telephone lines

• infrastructure equipment (routers, switched power supplies, etc.)

Each gateway should handle multiple connections in a same time and that is why it should use high performance DSP or modern ARM-based SoC running on the high clock rate (1 GHz or more)

In the FXS gateway we need to use almost all components considered above. The difference is in the voice path functionality:

• some small part of analogue signaling is not needed (CPT detectors, CallerID, DTMF rejector)

• the list of supporting codecs may be reduced to G.711+G.729 because most nowadays digital phones support them

• acoustic echocanceller is not needed. For FXS the echo compensation is done by line echo canceller

In contrary, in the FXO gateway we need those parts of signaling which is absent in the FXS. Also, IP-telephony layer is different because FXO require another way of calling and call bridging. Also, peripheral drivers are different (DAA instead of SLIC).

However, in general we may observe that software for both types of gateway is the same by 90% or more.

Time reduction

Development time is a serious factor affecting the project success. We live in the competitive world so the time to market sometimes much more important than the cost reduction. Huge amount of code creates a constant headache for project management and increases the risk.

We already mentioned that the adaptation of COTS solutions instead of making everything from the scratch shortens the time. But it is not all. The approach of IntegrIT company is adjusting of schedules for hardware and software development. Look how the process is organized in typical case:

• the first stage is prototyping. Usually, the result of this stage is the prototype of device or its most important part. At this stage designers check and approve general hardware solutions: schematics, interconnections, etc.

• the second stage is preproduction. At this stage engineers modify prototype to preproduction unit, produce several devices, clean up testing issues, prepare test plans and, finally, make preproduction testing

• the third stage is final design. At this stage engineers introduce small changes to the hardware to minimize nomenclature, production cost, etc. Also, some additional tests may be added to the test plan

First two stages are longest and typically take 3-6 months each depending on complexity. It is obvious if we begin software design after the second stage completion when hardware design will be stabilized enough it will increase the time so much. Besides, this approach does not give a possibility to check all hardware decisions at the earlier stages because in many cases you can not check the hardware without full-functional software running.

The way of IntegrIT is proposing engineering services together with licensing the software. We adapt our licensing solutions for customer’s hardware making it in parallel with hardware development schedule.

Typical software development schedule is also includes 3 stages:

• software prototype. The aim of this stage is running the licensed software at the basic functional level on the customer’s hardware prototype. Here we may omit some customer specific functions or something that not possible to check on this hardware. Also, at this stage we agree self-testing procedures for all hardware parts.

• at the second stage we add the software with additional blocks, optimize the performance and modify drivers to run the software on the preproduction unit. We also help customer to develop test plan allowing to check the functionality

• at the final stage we make small changes to the software and preparing needed documentation

Development schedules for hardware and software

Usually, at the first stage we need some hardware platform which is similar but not necessary identical to the prototype. As a rule, we may use evaluation boards with similar processor and small custom interface modules. It is enough to make prototype peripheral drivers. Migration to customers prototype may take few weeks if evaluation means already selected properly.

So, the hardware and software schedules may be adjusted well and total time is not increasing.

Conclusion

So, we may conclude that use of COTS software solutions in the development of telecommunication hardware provides faster time to market, better quality, higher performance and ensures interoperability. However, they should be based on approved APIs, well tested and specified to provide good quality level.

Buying ready to use components together with engineering services for their tuning and adaptation for projected hardware reduces workload and development costs as well as allows to adjust hardware/software development cycles minimizing the total schedule and the risks.

Company IntegrIT proposes wide selection of VoIP COTS components that may be used in wide range of applications and in different markets – from high-performance equipment to small mobile gadgets. The scalability is proven by cross-platform implementation and support of many processors: ARM9e, ARM11, Cortex, Marvell Kirkwood/Armada, C64xx/DaVinci/OMAP, Tensilica HiFi2/ConnXD2/BBE16, x86, operating system DSP-BIOS, Linux, Maemo/MeeGo, Windows, Windows CE/Mobile, Android.

Visit web-site www.integrit.com/products to know more about the IntegrIT products.