Diva ISDN IP chan_capi

bug in asterisk >= 1.8

2011-10-05T05:49:00.000-07:00

Compared with asterisk release 1.6 1.8 release is not stable.

The same test suite:

exten => _X.,1,NoOpexten => _X.,n,Answerexten => _X.,n,Echo

Using 30 channels and middle call duration of 5 sec results runs without problems with asterisk 1.6. But results in asterisk crash if using asterisk 1.8.Crash is caused by destruction of libc memory pool of by destruction of internal asterisk structures: CDR variables.

The solution for this problem is located inside of asterisk core:Multiple channel drivers are using "ast_set_callerid" from the context of internal thread. This is OK: "ast_set_callerid" calls ast_channel_lock and all changes on the channel variables are protected. After cid update is completed "ast_set_callerid" calls:

if (chan->cdr) { ast_cdr_setcid(chan->cdr, chan); }

At same time "__ast_pbx_run" ("main/pbx.c") calls:

if (c->cdr)
ast_cdr_update(c);

This call happens in the context of pbx own thread and the access to CDR is performed without any protection.

In the most of cases problem is caused by "freeing of already freed memory" and receives real problem if "freeing of freed and allocated by other memory".

The immediate solution is to change __ast_pbx_run in main/pbx.c and protect access to CDR:

ast_channel_lock(c); /* Add this line */
if (c->cdr)
ast_cdr_update(c);
ast_channel_unlock(c); /* Add this line */

This is multiple locations (inside of "__ast_pbx_run") where "ast_cdr_update" is called. You need to protect all accesses.

The newest available version of chan_capi (chan-capi-trunk 943) includes one work around for this problem:the code of "ast_set_callerid" is partially replicated and CDR is not updated if caller id changes (for example name is received from network).

But this is still problem if you use other channel driver (for example chan_sip). In this case you should modify "__ast_pbx_run" in "main/pbx.c", build and install asterisk.

chan_capi support for asterisk 10.0 BETA 1

2011-10-05T05:28:00.000-07:00

New chan-capi-trunk 943 contains support for asterisk 10.0 BETA1Changes are already tested and allows to use chan_capi together with new version of asterisk.

High Definition Conference using Diva System Release 9.6 and Wide Band audio codecs

2011-08-30T13:56:00.000-07:00

Diva System Release 9.6 and provided as part of release chan_capi (or from SVN trunk path) provides support for wide band codecs:

G.722
Siren7
Siren14
Linear16

This allows to use Diva hardware and chan_capi to create High Definition Conference servers.
Diva hardware supports mix of up to 900 TDM E.1/T.1/ISDN/POTS and VoIP (SIP/IAX/...) channels at same time.
Additional media processing can be applied to conference audio streams:
Echo cancellation
Noise Suppression
DTMF tome suppression
Part 168 Voice limiter
Automatic Gain Control for Rx and for Tx media streams

Together with quality of wide band codecs it allows to enhance the quality of conference signal and to achieve better use experience.

Very large conference with 900 members using Diva System Release 9.6 and chan_capi

2011-08-30T13:45:00.001-07:00

Using Diva system release 9.6 and new chan_capi (available as part of release and using SVN trunk path) this is possible to create full duplex conferences with up to 900 members.

By default the size of conference using Diva hardware is limited to 140 (With media processing) or to 360 (simple conference without media processing) members.

Introduction of "large conference" mode allows to increase size of conference up to 900 members with media processing active.

The new conferencing mode is activated using new "g" option for chan_capi "chat" command.

All media processing features, automatic gain control and active talker evaluation are available. User is free to create conference with up to 900 members, independent from the domain members connects from (E.1/T.1/ISDN/Analog or IP).

Media processing is performed using DSP of Diva hardware.

High Density Ultra Low Power HD Audo Gateway/IVR using Diva System Release 9.6

2011-08-30T13:04:00.000-07:00

Diva system release 9.6 offers new feature: diva streaming.
While this feature is hidden inside of the product core and use of this feature is nothing what requires and user/application actions the major effects from introduction of this feature are:

High reduction of host load
Low delay and delay variance of voice stream

Diva streaming is new media transport protocol. It is responsible for transfer of data between user application and Diva media processing resource. Diva streaming allows transport of data without host intervention and without overhead of system calls.
BUS Master DMA of Diva hardware performs direct transport of data between chan_capi and Diva media processing resources.

Provided reduction of host load allows to use smaller CPU and to reduce required power, space and price of the system. Moreover this is possible to create one passive cooled and free of maintenance system:

Dual core 1.2 or 1.6GHz Atom with 2 ... 4 GByte memory and 32Bit Ubuntu 10.04 LTS, updated to backport kernel with SSD support.
SSD or SD card with 4 ... 32 Gbyte as solid state disk.
Diva 4PRI PCIe HS (Half Size) or Diva 8PRI PCIe FS (Full Size) hardware.
Asterisk 1.8 compiled from sources.

In the test we used:
Dual core 1.6GHz Atom, 4GByte SD card, passive cooled, Diva 4PRI PCIe HS.

This results in one VoIP (SIP) Gateway with power usage of 40 WT and complete free of maintenance.

The space can be saved by use of PCIe connector cable. PCIe BUS allows to use cable as extension. This allows better place,ent of Diva hardware and as result smaller unit size.

The test shows that this is no problem to double channel density up to 240 channels.
This can be done by use of Diva 8PRI PCIe FS (Full Size) hardware.

Dialogic(R) Diva(R) System Release 9.6LIN is available

2011-08-30T12:25:00.000-07:00

The new release of Diva system release (http://www.dialogic.com/download/p/linux/source.9.6/111-82/download.htm) is available now. This 9.6 release provides huge amount of rand new features:

Support for Wide Band Audio (G.722 and related), inclusive support for chan_capi and Diva chan_capi WEB configuration. Now it is possible to create VoIP Gateways and conferences using Wide Band Audio codecs.
Wide band audio increases productivity and is one great enhancement for every conference server.

Diva streaming allows direct streaming of data between Diva media processing resources and running in user or in kernel mode applications with zero host intervention (using PCI/PCIe BUS Master DMA).
chan_capi supports Diva streaming. This reduces host load and allows to use low power dual core Atom boards to process up to 240 voice channels (IVR, Fax, SIP Gateway). This results 240 channels/40 WT: 0.167 WT for Channel, fully passive cooled system.

MWI (message waiting indication) support for chan_capi. chan_capi supports now MWI server and MWI client modes. This is possible to manage MWI atomatic by chan_capi or using dial plan commands.

chan_capi support for Asterisk 1.8

chan_capi support for extra huge conference with up to 900 members using single host.

Support for Blue Line
Support of Blue Line range of E.1/T.1 hardware:
Blue Line 1 PRI PCIe low profile with software echo cancellation
Blue Line 1/2/4/8 PRI PCIe Half Size with hardware echo cancellation

Blue Line range of hardware is optimized for use with chan_capi

Significant performance enhancement of Diva softIP. Now is possible to create up to 1024 channels on single host. No application change is necessary - all softIP channels are presented as N x E.1 or T.1 interfaces.

Diva softIP allows use of Diva T.30 and T.38 protocol stack with intelligent fax processing together with chan_capi, Hylafax and other applications.

Support for true Hot Plug operation fo all PCIe hardware:
Surprise removal without affecting the running applications
Free from human intervention insertion and replacement of Diva hardware

Blue line 1/2/4/8 PRI PCIe available from Dialogic

2011-07-25T07:15:00.000-07:00

Finally got in the hands new Dialogic hardware. All together it is a new family of host media processing hardware:

Low Profile Blue Line 1 PRI PCIe
Half Size Blue Line 2/4/8 PRI PCIe

The half size boards are equipped with DSP (Digital Signal Processor) for offload of most resource extensive and critical task - G.168 Echo Cancellation.

Boards are supported by standard Dialogic Diva product release and drivers and are exposing same API. This is no problem to use the board with chan_capi. This is just like to Diva boards, only certain media processing features which available on Diva are not available with Blue Line. But Blue Line is even more powerful compared to Diva PRI CTI boards: Echo cancellation is performed using hardware DSP, supporte real time media (RTP). Of cause processing extensive vocoders are not supported by Blue Line.

The Blue Line driver self is provided as binary toolkit and adapter to kernel at build time. This works without problems. Once loaded driver spreads his processing power across of multiple CPU and seems to run at software interrupt level.
At same time user mode driver provided just in case kernel mode driver can not be build. This is no difference taken a look from API which driver is used. But kernel mode scales better.

The conferencing is available too, chancapi "chat" command works without problems.

Taken all together is is very simple to use - just like Diva hardware, using same installation, build and configuratiuon tools.

Diva media streaming for chan_capi allows reduction of host load

2010-12-23T13:19:00.000-08:00

Using the Diva server board the only one processing overhead in the system is the transport of voice data between Asterisn and Diva hardware.

Diva media streaming allows to eliminate this overhead.
Diva media streaming allows to transport data between Diva hardware and the user application by PCI/PCIe BUS Master DMA. Due to mapping of DMA buffers to user mode this eliminates the overhead on copy of data (or remapping of data buffers) between address spaces and between host memory and system memory, strongly reduces the interrupt load.
With other words the overhead is eliminated at all by the fully new design of interface between Diva hardware and the user applications.

Diva streaming was used as the internal transport between Diva drivers, Diva hardware and Diva API. And now it is available under GPL license as part of the chan_capi code.

Very Large conference with chan_capi and Diva hardware

2010-12-23T13:09:00.001-08:00

Very large conference is one full duplex conference with 240 ... 900 members.
To implement such large conferences this is necessary to break the conference in the groups and to transmit only the summary group signel between groups (while inside of the group signal is built by any-to-any transmission of signals).

The most critical part if the creation of the groups, binding of certain media processing resources to groups and selection of the communication resources for transmission of signals between groups.

chan_capi implements the algorith to perform all mentioned tasks automatically. All the user has to do is to provide "g" option to capicommand "chat". With this option chan_capi will automatically create groups, distribute the required by groups media media processing tasks between available hardware resources and establish the paths betwee groups in the most efficient way. This allows to achive not only the best usage of the avvailable hardware but to minimize the introduces by transmission of summary signal delay.

New features

2010-12-23T13:01:00.000-08:00

Beside of compatibility with Asterisk 1.8 multiple new features are includded in the chan_capi:
+ "capi exec" cli command allows to execute any of ssupported "coimmands". This allows
for example control of media processing by conference operator.
+ "capi show resources" cli command allows to view media processing resources in use
+ Distributions of calls only to interfaces (E.1/T.1/S0/POTS/SS7) which are in active
state and are able to process the calls
+ "capi show ifcstate" cli command allows to control state of interfaces in use
+ AMI events for interface state
+ MeetMe compatible AMI interface (events, commands) for chan_capi conferencing
(capicommand(chat))

Asterisk 1.8 chan_capi support

2010-12-23T10:22:00.000-08:00

Newest available relase of chan capi (svn co svn://svn.chan-capi.org/chan-capi/trunk chan-capi-trunk) supports Asterisk 1.8.

Diva PCIe Hot Plug test

2010-10-10T07:50:00.000-07:00

Yes, it works. All Diva PCIe hardware ssupports PCIe Hot Plug inclusive surprise removal.

All you need is to load appropriate PCIe Hot Plug module (pciehp).

In case hot plug is not working please try to use pciehp_force=1 pciehp module parameter.

More about test, used mainboard will follow.

Diva 8PRI 4LANE PCIe 8 x E.1/T.1 1 x 450MHz MIPST RISC 24 x 600MHz DSP 20WT

2010-07-13T02:26:00.000-07:00

For unlimited voice, fax and modem, 20WT only

Large Asterisk PBX test using Diva and 480 switched channels

2010-02-14T23:42:00.000-08:00

The purpose of the test was to check usability of Asterisk with Diva hardware as solution for big enterprise switching systems (240 an more channels).

Following hardware used:

2 x Diva 8PRI PCIe in the system under test (16 x E.1 resulting in 480 channels)

2 x Diva 4PRI PCI and 2 x Diva 4PRI PCIe in the call generator

The system under test was used as PBX for switching calls between interfaces (between boards):

E.1[1...8] -> E.1[9...16]. Using "group" chan_capi syntax. This eliminates the need to check for free channel if switching the call, chan_capi provides management of channels within a group.

Two tests was used to check the quality of provided solution:

Long term load on all 480 channels with control of PESQ (voice quality)
High call frequency test on all 480 channels. Variable call length between 100 mSec and 2 Sec

Used Diva release: 9.02 (includes chan_capi)

Used Asterisk version: 1.6.1, 1.6.2, 1.4.29

OS: 64 Bit Debian lenny

Test results:

In the first test all Asterisk versions exposed same behavior. The switching done by cross board (direct board to board access) BUS master DMA of Diva hardware does not depends on the host CPU and on the Asterisk version. This is why no quality changes, compared to original signal was detected (with and without echo cancellation).
In the second test 1.6.X and 1.4.X versions of Asterisk exposed different behavior: while 1.4.29 was absolutely stable and no problem was detected 1.6.X crashed after several minutes of tests if used for more then 120 channels

Conclusion:

Using Diva 8PRI PCIe, Diva for Linux, chan_capi and Asterisk 1.4.29 this is possible to satisfy all needs of big enterprise marked using even one mid range server: the voice streaming is handled by Diva hardware in the independent from host CPU fashion, use of high density Diva hardware allows to provide 480 channels using only 2 x 4LANE PCIe slots.

Interesting aspect is the power consumption too. Every Diva 8PRI board uses approximately 20 W of power (20W for 240 channels). Combined with use of mid range CPU (1.2 ... 1.8 GHz) and use of power reduction technologies (ondemand power governer using SpeedStep, ...)

this provides significant reduction of power consumption.

Dialogic(R) Diva(R) System Release 9.0LIN Service Update 2

2009-11-21T13:08:00.000-08:00

Dialogic(R) Diva(R) System Release 9.0LIN Service Update 2 is available.

Includes newest version of chan_capi.

http://www.dialogic.com/download/p/linux/source.9.02/109-34/download.htm

Major changes:

Add Diva 8-PRI PCIe FS Board and Diva 4-PRI PCIe FS Board

Add software echo cancellation for Diva PRI CTI and Diva BRI CTI hardware

The new Diva 8-PRI and 4-PRI boards are PCIe x4 boards, every with 24 BF533 DSP (each with 32 MByte SDRAM memory), R7000 RISC MIPS CPU wich 128 MByte of DDR memory. This provides x3 and x6 DSP for every E.1/T.1 trunk respektively.

Software echo cancellation (Line Echo Cancellation, LEC) is provided for Diva CTI hardware (Diva PRI CTI, Diva BRI CTI and Diva BRI 2FX) which are not populated with DSP and missing this funktionality. Software echo cancellation available only if Board is assigned (by Diva configuration) for use with chan_capi.

Asterisk WEB Configuration GUI

2009-10-25T16:09:00.000-07:00

An example of Asterisk WEB based GUI is at http://demo.world-communication.de/sipconf.cgi

Looks like allows to create one hosted PBX, SIP/ISDN/PSTN gateway and/or SIP/ISDN/PSTN PBX with view mouse clicks. At same time provides the possibility for changing of several extended configuration settings of Asterisk to adapt the PBX to environment and to resolve compatibility problems.

The Asterisk WEB GUI is built at top of Diva WEB server which is distributed under GPL license and provides a possibility to create own customer specific extensions for configuration of customer own system.

This tool creates extensions.conf and other configuration files and uses sip.conf as storage of all necessary information.

And the most noce, the generated extensions.conf uses chan_capi and supposes the use of Diva hardware.

Long term chan_capi test with 1.5 Million calls completed with success

2009-09-09T01:47:00.000-07:00

Long term chan_capi test is completed with success.

Test was done using Asterisk as gateway between SIP and ISDN network:

Diva SoftIP - SIP -> Asterisk(chan_capi)-> Diva 4PRI <- 4 x E.1 -> 4 x E.1 -> Asterisk(chan_capi) - SIP -> Diva SoftIP

Good guide on Line echo canceller (LEC)

2009-08-19T08:29:00.000-07:00

Line echo canceller (http://www.audiodesignline.com/213000378?cid=RSSfeed_audiodesignline_adlRSS)

Use of chan_capi with Diva SS7

2009-08-18T14:02:00.000-07:00

Diva SS7 allows use of SS7 signaling with chan_capi. No changes to chan_capi or chan_capi configuration are necessary. Diva SS7 provides converion between SS7 protocol towards network and ETS 300 102-1 towards chan_capi. This allows use of existing chan_capi implementation and configuration without changes.

The solution allows simple implementation of gateways between SS7 and SIP, SS7 and local ISDN/PSTN networks.

Diva SS7 configuration (Diva demo system)

Diva chan_capi (capi.conf, modules.conf) configuration (Diva demo system)

chan_capi and chan_dialogicdiva 1.1.4 are released now

2009-08-18T13:56:00.000-07:00

New stable versions of chan_capi and chan_dialogicdiva are released as 1.1.4

chan_capi download

chan_dialogicdiva-1.1.4.tar.gz

Additional media processing by gateways

2009-08-14T04:26:00.000-07:00

Gateways are often taken as simple convertors between different media formats. Additional application servers are use to provide additional media processing capabilities. But use of additional application server is not always the best solution. In case changes to media should be applied as fast as possible (if possible no delay between user input and initiated by this input action), small and provided to all users (no accounting, billing) set of media control commands it may be better to ingegrate appropriate services in the gateway.

The best suited for this purpose media processing services are:

Manual gain control by user
Automatic gain control with possibility of activation/deactivation by user
Suppression of ambient noises with possibility of activation/deactivation by user
Mute/Un mute
Send information tone to peer

chan_capi and chan_dialogicdiva 1.1.3 are released now

2009-08-04T07:42:00.000-07:00

New stable versions of chan_capi and chan_dialogicdiva are released as 1.1.3

chan_capi download

chan_dialogicdiva download

Diva configuration allows to manage capi.conf

2009-07-16T08:08:00.001-07:00

Using Dialogic Diva System Release 9.0 for Linux this is possible to manage capi.conf using Diva configuration.

Diva chan_capi configuration

New command "chat_command" added to CHAN_CAPI

2009-07-16T07:54:00.000-07:00

(from README.media)

chat_command

Description:
Used to send command to conference.

Supported hardware:
Diva

Syntax:
capicommand(chat_command|options|roomname)
options - mandatory
r - Remove newest user from conference.
Command does not apply to calling member and be used by operators only.
l - Remove all listeners from conference.
Command does not apply to calling member and be used by operators only.
o - Remove all operators from conference.
Command does not apply to calling member and be used by operators only.
a - Remove all users from conference.
Command does not apply to calling member and be used by operators only.
roomname - optional, room caller assigned to is used if not present

Syntax example:
exten => s,n,capicommand(chat_command|r)
exten => s,n,capicommand(chat_command|lo|test)
exten => s,n,capicommand(chat_command|a|test)

Conference example:
/////////////////////////////////////////////////////////////////////
[isdn-in]
exten => _X.,1,Answer
exten => _X.,n,Authenticate(12345)
exten => _X.,n,Playback(vm-rec-name)
exten => _X.,n,Record(/tmp/name${UNIQUEID}.alaw,5,15) ; Record name
exten => _X.,n,capicommand(chat_play|c1||/tmp/name${UNIQUEID}.alaw|1-4) ; Play name to conference
exten => _X.,n,capicommand(resource|1-4) ; Create resource PLCI if call from IP
exten => _X.,n,capicommand(clamping|200) ; Activate suppression of DTMF codes
exten => _X.,n,capicommand(vc|chat_mute|1|yes) ; Voice command, key 1 - mute all members except operators
exten => _X.,n,capicommand(vc|chat_mute|2|no) ; Voice command, key 2 - unmute all members except operators
exten => _X.,n,capicommand(vc|chat_command|0|a|c1) ; Voice command, key 0 - remove all members from conference
exten => _X.,n,capicommand(vc|noisesuppressor|3|yes) ; Voice command, key 3 - turn noise suppression on
exten => _X.,n,capicommand(vc|noisesuppressor|4|no) ; Voice command, key 4 - turn noise suppression off
exten => _X.,n,capicommand(chat|c1|mo|1-4) ; Add caller to conference as operator

Asterisk Konferenzen / Timingdevice

2009-07-16T06:25:00.000-07:00

In case Diva is used for conferencing then "chat" chan_capi command should be used instead of MeetMe.

Using "chat" conference is done on Diva hardware and not on host. Diva hardware will use internal clock (from TDM or from internal clock source) if necessary. "chat" can span conferences over multiple Diva boards.

Using "chat" this is possible interconnect E.1/T.1/S.0 and IP members and to span conferences over multiple Diva board. This allows not only to offload host but provide for all participants (inclusive IP participants) conference with active talker evaluation and media processing (noise suppression, dtmf detection, digital gain control, ...)

Use of "chat" chan_capi command together with "vc" chan_capi command allows interactive change (in real time) of apllied to media streams media processing.

Please read more about "chat", "chat_play", "chat_mute", "vc" and "resource" chan_capi commands in README.media

Use of Diva hardware with XEN PVM

2009-07-03T00:31:00.000-07:00

XEN allows access to PCI and PCIe hardware from PVM guest (using PCI backend/frontend) drivers. This is well tested and works with Diva hardware (tested with XEN 3.2, reported previous versions and XEN 3.3 works too).

This is no differences in performance if using Diva hardware from PVM guest.

Important notice:

Virtual machines are known to be well isolated from the system (hypervisor, Domain 0, other guests) and this is supposed that crash of one VM guest affects this guest only.
This is not true if you access PCI hardware from PVM guest. PCI hardware can use DMA (Diva hardware uses DMA) and after PVM is terminated DMA on hardware remains active and accessing (writing) memory which free or assigned to other domain now.
The solution is to modify XEN hypervisor to erase master bit in PCI configuration space after PVM exit detected but before assigned to PVM memory is freed.
In the future this problem will be probably resolved using IOMMU/VT-D.

Before continue with set up procedure, please check for following originated by XEN limitations:

XEN can not share interrupts between assigned to different domains devices. Please ensure that Diva board you plan to use with PVM guest does not shares interrupt with other used by Domain 0 or by other domains devices
XEN does not allows to use DAC (Dual Address Cycle, PLCI) and Long Address Format (PCIe) from PVM guest. In case all memory below 4GByte is allocated PVM will fail to allocate DMA descriptors and Diva hardware will not start. To prevent this problem please start PVM which accesses PCI hardware as first and Start Diva hardware at PVM start
XEN does not allows use of MSI (Message signaling interrupt) by PVM guest
XEN does not allows to use AER (Advanced Error Reporting, PCIe) by PVM guest

Now the set up procedure:

Domain 0:
modprobe pciback
cd /sys/bus/pci/drivers/pciback
# Show information about Diva hardware
lspci
07:01.0 Network controller: Eicon Networks Corporation Diva Server 4PRI (rev 01)
07:02.0 Network controller: Eicon Networks Corporation Diva Server 4PRI (rev 01)
# Assign both Diva boards to PCI backend driver
echo -n "0000:07:01.0" > new_slot
echo -n "0000:07:01.0" > bind
echo -n "0000:07:02.0" > new_slot
echo -n "0000:07:02.0" > bind
# Allow access to configuration space.
# Diva drivers use VPD (Vital Product Data) PCI configuration space area
# Probably bettter to use xend-pci-permissive.sxp to allow access to VPD
# are only.
echo -n "0000:07:01.0" > permissive
echo -n "0000:07:02.0" > permissive

Now add to PVM guest configuration:
pci = [ '07:01.0', '07:02.0' ]

Finally start PVM, install, configure and start Diva drivers

PBX hunt group revisited

2009-07-01T13:49:00.000-07:00

Suppose one group of PBX is used to distribute calls to multiple application servers (voice mail, IVR, gateway, ...). PBX starts the distribution of the calls as soon as interface (E.1/T.1/S0) receives ready.
Now suppose at time interface receives ready application is still not ready to process the calls. This can happens due to multiple reasons: Application is about to start, application is restarted, unexpected termination of application, host OS problem, ... . The precise cause is not important. Most important is the fact that all distributed to this application server calls are lost, and this is in the time other application servers are ready to process the calls.

This problem is resolved by Diva support for Hunt Group. You can use Diva configuration to activate Hunt Group mode. Once active E.1/T.1/S0 interfaces of Diva hardware remains in hight impedance state (from the point of view of PBX it looks same as cable not connected to port) until user application receives ready (as soon as application can not process the calls). PBX distributes the calls to other ports (no calls are distributed to inactive port) and as result no calls are lost.
Once user application receives ready (again) Diva will change to normal operation and activate E.1/T.1/S0 interfaces. PBX will start call distribution to appropriate ports (again).

Diva hunt group support is available for each application which uses Diva CAPI or Diva API. This is no change to application is necessary. Information about the state of application is derived from the behavior of application.

You can get more information in Diva reference manual.

Diva System Release - Version 9.0LIN SU1 (final)

2009-05-19T09:15:00.000-07:00

Diva System Release - Version 9.0LIN SU1 (final)

Build:	109-82
Created:	Tue May 19 09:06:48 GMT 2009
Uploaded:	Tue May 19 09:52:02 GMT 2009
Status:	final
Access:	free

Download

Description

Dialogic® Diva® System Release 9.0 LIN SU1 is a service release, which includes support of new Dialogic® Diva® Media Boards, additional features, enhancements of existing features as well as fixes of known bugs.

System Release 9.0 LIN SU1 allows up to 8 Diva Media Boards to be installed on a computer running the Linux operating system distributions SuSE, Red Hat, Debian or generic Linux distributions as 32 or 64 bit variant. It supports unified messaging, voice, speech, conferencing applications, RAS & RRAS (client and server mode), modem and fax as well as Voice over IP (VoIP) and Fax over IP (FoIP).

The new features of System Release 9.0 LIN SU1 are:

Support of new Diva Media Boards
- Dialogic Diva V-1PRI/E1/T1-30 PCIe HS
- Dialogic Diva V-2PRI/E1/T1-60 PCIe HS
- Dialogic Diva V-4PRI/E1/T1-120 PCIe HS
chan_capi configuration wizard for Asterisk®
- Automatic generation of a capi.conf file per WEB GUI
- Simplified usage of enhanced DSP features with Asterisk®
- Support of
  - 256 ms Echo Cancellation
  - Suppression of ambient noises
  - Automatic Gain Control
  - Digital Gain Control
  - Codec Support (Automatic Transcoding) incl. G.729, G.726/32, GSM, iLBC and G.711
  - Detection of MF digits and Dialing Pulses Rate conversion (control of recording and playback pitch/speed)
  - Detection of special tones and human talker interactive control of voice stream
  - Control voice stream while recording or playing back
  - Use any available channel command
  - Conferencing
  - Using proven Diva Media Board Q.SIG and SS7 implementation
  - Noise suppression
  - Tone clamping
  - Automatic Gain Control (Rx, Tx)
  - Pitch Control (Rx, Tx) in combination with play/record funcionality on Asterisk
  - MF Tone Detection,
  - Pulse Dial Detection,
  - Transmit SIT Tones,
  - Detect SIT Tones,
  - Voice Control
  - DSP-based DTMF detection,
  - DSP-based echo cancellation,
  - Chat/Meet Me (Ad Hoc) Conferencing - (MOH).
  - Fax Send/Receive
New Dialogic® Diva® softIP features in Resource Board Mode
- When using Diva Media Boards with full DSPs, support of G.729, G.726/32, GSM, iLBC, G.711
- Clear Channel Fax and Modem supported up to full speed of 33.6kbps (V.34)
- NOTE: The use of G.729 requires the appropriate license from Dialogic
Dialogic® DSI SS7
- Provide high performance MTP2 on Diva Media Boards
- Run SS7 signaling and media processing on the same Diva Media Board
- Supports up to 16 E1 trunks with up to 496 bearer channels per installation
- Supports up to 4 signaling links and up to 4 linksets
- Supports CAPI interface and Dialogic® DSI SS7 interfaces
Miscellaneous
- Echo canceller up to 256ms tail length
- Diva Media Boards (with DSP) can be used as transcoding device in parallel to TDM access (e.g. Asterisk® )
- Tested XEN pci passthrough compatibility
- RTCP for SIPcontrol 2.0 SU2
- Interoperability with OCS 2007 R2
- Firmware support of Asymmetric Hold with SIPcontrol (send/receive only)
- Support for kernels up to 2.6.29

Software modules contained in System Release 9.0 LIN SU1

Dialogic® Diva® SIPcontrol™ 2.0 SU2
Dialogic® Diva® softIP 2.2 offers CAPI, TTY, Diva API or Dialplan (chan_capi) based applications to interface with SIP peers.
Dialogic® Diva® Interfaces for support of Dialogic DSI SS7 Software

For more information on software modules please refer to the documentation.

New command chat_play added to chan_capi

2009-05-15T05:49:00.000-07:00

'chat_play' command allows to play voice messages to conference while music on hold is optionally played to caller.

'chat_play' can be used to provide information about new members and to play announcements.

[isdn-in]
exten => _X.,1,Answer ; Answer the line
exten => _X.,n,Goto(s,1)
exten => s,1,capicommand(clamping|100) ; Activate suppression of DTMF tones
exten => s,n,Playback(record-name) ; Ask for name
exten => s,n,capicommand(rxagc|yes) ; Activate Rx AGC
exten => s,n,Record(/tmp/${UNIQUEID}-info:alaw) ; Record message
exten => s,n,capicommand(rxagc|no) ; Deactivate Rx AGC
exten => s,n,capicommand(chat_play|test|m|/tmp/${UNIQUEID}-info.alaw|1-4) ; Play message to conference,
; play music on hold to caller
exten => s,n,capicommand(chat|test|m|1-4) ; Create/enter conference room 'test'

Please read README.media for details

Conference with up to 360 channels

2009-05-11T06:21:00.000-07:00

chan_capi 'chat' command can be used to create full duplex (any to any) conferences with up to 360 members.

Using 3 x Diva 4PRI 360 members
Using 6 x Diva PRI v.3 180 members

'chat' command allows to manage conference and to switch between full duplex (any to any) and half duplex (operators to listeners) mode.

Please see README.media for more details

Preserve your Diva hardware by migration to IP

2009-05-04T01:49:00.000-07:00

By migration to IP this is always a decision about the choice of the hardware for new IP based platform and about the hardware to maintain still existing E.1/T.1/S0/PSTN infrastructure. Often E.1/T.1/S0/PSTN infrastructure is used in parallel with new IP infrastructure over longer period of time for different grounds: maintaining one backup solution, step by step transition to IP, ...

Diva hardware provides the optimal choice for such situations. Diva hardware can be used in E.1/T.1/S0/PSTN area as regular Voice/Fax hardware, in VoIP gateways by transition between E.1/T.1/S0/PSTN and IP network and in the IP network for clear channel fax, conferencing and voice compression.
This is possible to use same DIva board for all mentioned above use cases at same time using provided by Diva dynamic distribution of DSP resources. This allows implementors to share one node for implementation of multiple present in VoIP functions saving the necessary for multiple nodes costs for power and for maintenance of extra hardware.

The functionality is supported by multiple applications and available to user programming interfaces which allows fast development of own solution.

Available applications:

chan_capi

Can be used as IP gateway, as PSTN PBX, as IP PBX, Voice mail system, IVR in PSTN and/or IP network
Open source
Fax with V.34 (33600 Bps)
Clear channel fax with V.34 (33600 Bps)
G.168 with 256 mSec echo tail length to provide echo cancellation in case not provided by gateway
G.729, G.726, G.723 32K, GSM, iLBC, G.711 a/uLaw
Conferencing with active talker evaluation and conference AGC
Processing of DTMF tones, DTMF clamping
Suppression of Ambient noises
Digital gain control
Playback and recording speed control
Conferences between PSTN and IP conference members
Please read README.media and README.Diva.fax for details

softIP

Use of Diva hardware in IP network

SIP/UDP signaling
Clear Channel Fax with V.34 (33600 Bps)
T.38 Fax with v.34 (33600 Bps)
G.168 with 256 mSec echo tail length to provide echo cancellation in case not provided by gateway
G.729, G.726, G.723 32K, GSM, iLBC, G.711 a/uLaw
Conferencing with active talker evaluation and conference AGC
Processing of DTMF tones, DTMF clamping
Suppression of Ambient noises
Digital gain control
Playback and recording speed control
Kernel mode streaming to minimize delays and host load
Conferences between IP conference members
Simple migration of existing applications to IP

sipControl

Use of Diva hardware for VoIP gateway

SIP UDP/TCP/TLS signaling, early media, reliable responses
Secure RTP (encryption of RTP data)
RTCP
T.38 gateway with V.34 (33600 Bps)
G.168 with 256 mSec echo tail length
AMR-NB, G.729, G.726, G.723 32K, GSM, iLBC, G.711 a/uLaw
Processing of DTMF tones, DTMF clamping
Suppression of Ambient noises
Kernel mode streaming to minimize delays and host load

Development of own applications

The access to all provided by Diva hardware features is provided using one single API. User application can use API not only to access provided by Diva hardware features but to control the provided by Diva drivers kernel mode streaming. Processing of entire real time traffic (RTP and RTCP) by kernel mode frees the deveper fron need to deal with details of real time data transport between Diva hardware and IP protocol stack.

How to use clear channel fax over IP with Diva hardware and chan_capi

2009-05-03T08:07:00.000-07:00

Diva hardware allows use chan_capi 'receivefax' and 'sendfax' commands to receive/transmit fax documents over IP using clear channel fax.

No additional configuration of Diva hardware or significant changes to dial plan are necessary to actiate clear channel fax. Only one change in Dial Plan is the use of chan_capi 'resource' command for IP peers:

[handle_fax]
exten => s,1,capicommand(resource|1-4) ; Assign resource PLCI
exten => s,1,capicommand(receivefax|/tmp/${UNIQUEID}[|||])
exten => s,2,Hangup()
exten => h,1,deadagi,fax.php ; Run sfftobmp and mail it

[handle_sendfax]
exten => s,1,capicommand(resource|1-4) ; Assign resource PLCI
exten => s,n,capicommand(sendfax|/tmp/sendfax001.sff|1234 1234 1234|Outgoing Fax)
exten => s,n,deadagi,faxlog.php ; Log result and schedule restart if necessary
exten => s,n,Hangup

chan_capi 'resources' command is used to assign DSP resources to IP call. This command does not performs any action for E.1/T.1/S0/PSTN calls. This allows to use same context for processing any type of call.

Please read more about 'receivefax' and 'sendfax' commands in README.Diva.fax and more about 'resource' command in README.media

Diva conferencing AGC revisited

2009-05-01T09:06:00.001-07:00

Diva provides conferencing AGC (Automatic Gain Control) which is used in conjunction with active talker detection to gain the signals of active talkers and to suppress injected by inactive parties noise.

The evaluation of active talkers includes the identification of signal as originated by human talker. Only if source of signal is identified as human talker the appropriate conference member will partipiate in the evaluation of active talkers.
In opposite case (if originated by conference member signal is not originated by human talker) conference member is not identified as active talker even if providing signal with significant amplitude.

The use of human talked detection as part of the active talker evaluation procedure allows to protect conference signal from injected by conference members loud noises and significantly improves the quality of conference even with small amount of members.

Diva conferencing AGC and active talker evaluation receives automatically active for conferences with three or more members. Using Diva configuration is possible to deactivate conferencing AGC or to change the amount of members necessary to activate conferencing AGC.

Managed conference example

2009-05-01T08:10:00.000-07:00

Dial plan example (from README.media) shows how 'chat_mute' command can be used to manage conference.
The users calling to 1291 will join conference as operators, to 1292 as regular users and 1293 as listeners.
Operators can use '0' DTMF key to mute all regular users and '1' DTMF key to unmute all regular users. The state of operators self and of listeners remains unchanged.
Operators can use '2' to mute own signal and '3' to unmute own signal.
DTMF clamping is active and used to remove send by operators DTMF signals from conference voice stream.

Regular users can use DTMF keys 0 and 1 vor volume control.

Listener users use automatic gain control

In this example extensions (1291, 1292, 1293) are used to identify users. In the pactice this is more convient to use transmitted using DTMF digits passwords (or extensions and passwords together).

[isdn-in]
exten => 1291,1,Answer ; Accept call
exten => 1291,n,capicommand(resource|1-4) ; assign resource PLCI if call from IP
exten => 1291,n,capicommand(clamping|200) ; Activate DTMF suppression
exten => 1291,n,capicommand(vc|chat_mute|0|yes) ; Voice command, key 0 - change to half duplex mode
exten => 1291,n,capicommand(vc|chat_mute|1|no) ; Voice command, key 0 - change to full duplex mode
exten => 1291,n,capicommand(vc|txdgain|2|-128) ; Operator mute himself
exten => 1291,n,capicommand(vc|txdgain|3|0) ; Operator mute himself
exten => 1291,n,capicommand(chat|test_chat|mo|1-4) ; Add to conference as operator
exten => 1291,n,Hangup()

exten => 1292,1,Answer ; Accept call
exten => 1292,n,capicommand(resource|1-4) ; Assign resource PLCI if call from IP
exten => 1292,n,capicommand(clamping|200) ; Activate DTMF suppression
exten => 1292,n,capicommand(vc|incrxdgain|0|-1.5) ; Rx volume control
exten => 1292,n,capicommand(vc|incrxdgain|1|1.5) ; Rx volume control
exten => 1292,n,capicommand(chat|test_chat|m|1-4) ; Add to conference as regular user
exten => 1292,n,Hangup()

exten => 1293,1,Answer ; Accept call
exten => 1293,n,capicommand(resource|1-4) ; Assign resource PLCI if call from IP
exten => 1293,n,capicommand(clamping|200) ; Activate DTMF suppression
exten => 1293,n,capicommand(rxagc|yes) ; Rx Automatic gain control
exten => 1293,n,capicommand(chat|test_chat|m|1-4) ; Add to conference as listener
exten => 1293,n,Hangup()

exten => _X.,1,Answer
exten => _X.,n,Goto(s,1)
exten => s,1,Wait(1)
exten => s,n(restart),Playback(demo-instruct)
exten => s,n,Goto(s,restart)
exten => s,n,Hangup

Managed conferences using chan_capi

2009-05-01T08:07:00.000-07:00

By default chan_capi 'chat' command provides one "any-to-any" functionality. This is convient for conferences with relatively small amount of members. In the large conferences "any-to-any" functionality receives not useful. The problems in the large conferences are caused by multiple unexpected talkers which can not mute they signals or are not avare about caused by transmitted signal problems. In the conference with several hundert of members this is not time to ask the members to mute, and this is not time to identify the members who had not muted they equipment. This is desirable to have a control over are conference members and mute/unmute they signals if necessary.

To provide this functionality 'chat' command provides three types of conference members:

Regular users

Operators

Listeners

Regular users can receive voise stream from conference and send voice stream to conference.
Outgoing (from user to conference) voice stream from regular users can be muted (deactivated)
and unmuted (activated) if necessary by 'chat_mute' command.

Operators can receive voise stream from conference and send voice stream to conference.
Outgoing (from user to conference) voice stream from operators can not be muted (deactivated)
by 'chat_mute' command.

Listeners can only receive voice stream from conference.
Outgoing (from user to conference) voice stream is muted (decativated) and can not be unmuted (activated)
by 'chat_mute' command.

The 'chat_mute' command allows to control the state of the conference. It allows to mute and to unmute all regular
users without changing the state of operators and listeners.

The typical conference consists from the group of operators (moderators, ...) who remain always active and allowed
speak at any time and/or control they mute function (on phone equipment or using 'txdgain' chan_capi command )
self. This group of users is implemented as operators.

The other group of users are group leaders who are partipiating most of time listening to conference, but are
actively talking (questions, answers) if allowed by conference moderator. This group of users is implemented
as regular users.

The remainding users are partipating as listenuing only and are implemented as listeners.

The 'chan_capi' command can be used by any user, not only by operator and by conference member. This allows
to use one single user for managing multiple conferences and allows implementation of common conference
moderator.

Please read more in README.media

Dialogic(R) Diva(R) SoftIP use cases

2009-04-27T03:14:00.001-07:00

Dialogic(R) Diva(R) SoftIP use cases

Partial or full migration of existing installation and application environment to IP

One existing application with configuration can be migrated to IP environment is case phone numbers, media processing features and supplementary services are mapped (translated) between one use in IP network and one expected by developed in E.1/T.1/S0/PSTN application.

To achieve this mapping and translation softIP uses following techniques:

mapping between used by application phone numbers CPN/CiPN (DID, extensions, MSN) and SIP addresses

for incoming calls mapping of SIP urls to CPN/CiPN/Redirection numbers

for incoming calls mapping of SIP urls to CiPN and registering of SIP urls

for outgoing calls mapping of CPN to SIP url to create call using default outbound proxy

for outgoing calls mapping of CPN to SIP url and outbound proxy

translation of basic call signaling and supplementary services protocols between SIP and ISDN signaling protocols

Dialogic(R) Diva(R) translates SIP signaling messages to ISDN QSIG messages which are routed and processed by softIP using one virtual ISDN network. This translation allows to achieve high level of compatibility to existing application uses same QSIG implementation as Dialogic(R) Diva(R) hardware
- same source code
- same state machines
- same coding of messages

allows to use any other supported by Divalogic(R) Diva(R) ISDN protocol instead of QSIG, but this is suggested to use QSIG as most flexible and best suited for this purpose

if required provides access to SIP signaling to application

conversion of media protocols between used in IP and ISDN environment

softIP provides support for multiple voice codecs and performs transcoding between expected by user application G.711 aLaw/uLaw byte stream and used at IP side RTP packet stream with one of supported payloads

G.711 aLaw/uLaw, G.729, G.723 32k, GSM, iLBC

if required softIP provides access to compressed IP data and RTP data to user application

softIP uses T.38 and clear channel fax to provide to user application same T.30 capabilities and same support for formats of fax document media as in case of used in ISDN environment Dialogic(R) Diva(R) hardware

V.34 Fax with 33600 Bps

Provides high level of compatibility with by use of same T.30 implementation as Dialogic(R) Diva(R) hardware

V.34 (33600 Bps) clear channel fax

Provides high level of compatibility by use of the same fax modulation and T.30 implementation as Dialogic(R) Diva(R) hardware

Supports line interconnect (conferencing between different types of peer)

Between IP peers

Between IP and ISDN (E.1/T.1/S0/POTS) peers

Use of virtual E.1/T.1 interfaces

To ensure compatibility with existing application which are not supporting interfaces with more then 31 channels softIP present available (licensed) channels as number of virtual E.1 (T.1) interfaces every with not more then 30 (23) bearer channels

less 30 channels results in one virtual fractional E.1 interface

120 channels results in 4 x virtual E.1 interfaces

Reuse of existing device drivers and API at binary level and possibility to use softIP in one system with Dialogic(R) Diva(R) ISDN (E.1/T.1/S0) and POTS hardware ensures high level of compatibility to existing applications and environments and allows step by step migration from ISDN/POTS to IP.

SoftIP allows to use following Dialogic(R) Diva(R) ISDN/Analog hardware for media processing:

Diva 4PRI PCI, Diva 2PRI PCI, Diva 4PRI PCIe HS, Diva 2PRI PCIe HS, Diva 1PRI PCIe

Diva PRI v.3

Diva 4PRI Rev.2 PCI, Diva 4BRI PCIe, Diva BRI Rev.2 PCI, Diva BRI PCIe

Diva Analog PCI and PCIe

This allows to preserve hardware by migration to IP.

The mapping between SIP urls and ISDN numbers is held in one text file (CVS format) which can be created and changed by customer own tools if necessary.

Example Diva 4BRI -8M Rev.2

Using Diva 4BRI Rev.2 this is possible to use one or more interfaces (or all of interfaces) in resource board mode and allow use of DSP resources (two for every interface) by softIP. For example:
softIP license 8 channels
Diva 4BRI Rev. 2 two interfaces in resource board mode
Provides:
4 ISDN channels (2 x S0) with access to DSP resources
G.168 echo cancellation with 256 mSec tail
G.711, G.729, G.726, G.723
Extended tone processing
Suppression of ambient noises
V.34 (33600 Bps) Fax
4 IP channels with access to DSP resources
G.168 echo cancellation with 256 mSec tail
G.711, G.729, G.726, G.723
Extended tone processing
Suppression of ambient noises
V.34 (33600 Bps) clear channel fax
4 IP channels without access to DSP resources
G.711, DTMF processing, Fax calling ton detection
8 T.38 V.34 (33600 Bps) fax channels

Example Diva PRI Rev.3 30M

Using Diva PRI Rev.3 in resource board mode this is possible to use all provided (up to 30) DSP resources for processing of IP connections. For example:
120 softIP channels
2 x Diva PRI v.3 30M in resource board mode
Provides:
60 (2 x 30) IP channels with access to DSP resources
G.168 echo cancellation with 256 mSec tail
G.711, G.729, G.726, G.723
Extended tone processing
Suppression of ambient noises
V.34 (33600 Bps) clear channel fax
60 IP channels without access to DSP resources
G.711, DTMF processing, Fax calling ton detection
120 T.38 V.34 (33600 Bps) fax channels

Example Diva 4PRI PCI

Using Diva 4PRI PCI this is possible to use one or more interfaces (or all of interfaces) in resource board mode and allow use of DSP resources (30 for every interface) by softIP. For example:
120 channels softIP license
Diva 4PRI PCI with two interfaces in resource board mode
Provides:
Up to 60 ISDN channels (2 x E.1/T.1) with access to DSP resources
G.168 echo cancellation with 256 mSec tail
G.711, G.729, G.726, G.723, iLBC
Extended tone processing
Suppression of ambient noises
V.34 (33600 Bps) Fax
60 IP channels with access to DSP resources
G.168 echo cancellation with 256 mSec tail
G.711, G.729, G.726, G.723, iLBC
Extended tone processing
Suppression of ambient noises
V.34 (33600 Bps) clear channel fax
60 IP channels without access to DSP resources
G.711, DTMF processing, Fax calling ton detection
120 T.38 V.34 (33600 Bps) fax channels

Newest chan_capi sources

2009-04-20T02:42:00.000-07:00

The SVN ode repository is located at http://www.melware.org/ChanCapi where you can get access to stable and to development versions.

Use of Dialogic® Diva® softIP-SIP with chan_capi

2009-04-20T02:14:00.000-07:00

What is Diva softIP

The product Dialogic® Diva® softIP is Diva software which can be used for all Diva applications that have been developed for any of the many interfaces Diva supports. For Linux these interfaces are CAPI, extended CAPI, TTY and the Diva API.

NOTE: The Diva API is offered by the Dialogic® Diva® SDK.

In a pure IP/SIP environment the Diva softIP product replaces the Diva Media Board. In a hybrid environment softIP will be used together with a Diva Media Board.

NOTE: A Diva Media Board can be one of the following: Diva Analog, Diva BRI, Diva PRI or Diva V-xPRI Media Boards.

The beauty of softIP is that there is no need to change the application, except if it is required to access IP/SIP functionality directly from the application. This can be the case if you e.g. want to extract the email address from the SIP message.

Compared to a Diva Media Board, which exposes Analog, ISDN BRI, ISDN PRI or E1/T1 interfaces towards the network and the IDI interface towards the user application, Diva softIP exposes an IP/SIP/RTP/sRTP/T.38 interface towards the network and continues to expose the IDI interface towards the user.

From the point of view of user application this is no difference between one API interface which is connected to a Diva Media Board (hardware) and one which is connected to Diva softIP (software).

From the application point of view adding Diva softIP to the system (application) is the same as to add a Diva Media Board (hardware). For this reason in the remainder of the document Diva softIP is referred to as a “virtual board”.

NOTE: Also the Diva softIP (software) needs hardware in order to access the Ethernet (IP) network. It simply uses the Network Interface Card (NIC) also called Ethernet Card as its way into IP. In terms of application architecture you can see a Diva Media Board being replaced by Diva softIP plus and Ethernet board.

Diva softIP signaling features

The available number of channels depends on the quantity of activated softIP licenses.
- To ensure compatibility with existing application the available channels are presented to the application as a number of “virtual softIP boards”, each one with 30 channels or less.
- It is possible to join multiple “virtual softIP boards” and Diva media boards to one virtual board with the added number of channels.
Signaling features
- IP/UDP/SIP
  - HOLD/RETRIEVE with REINVITE (mapped to CAPI ETSI HOLD/RETRIEVE)
  - REFER in active state (mapped to CAPI ETSI call deflection)
  - Consultation call transfer with REFER (mapped to CAPI consultation call transfer)
  - Call deflection in non active state (send 302 to network, mapped to CAPI ETSI call deflection)
  - REGISTER as client
  - NOTIFY MWI (Message Waiting Indication) as server
  - Rx REFER and processing
  - Rx INVITE with Replaces header and processing
  - Remote-Party-ID processing
  - P-Asserted-Identity (under development)
  - old diversion-header

softIP media processing features

Media processing features
- RTP G.711 aLaw and uLaw
- DTMF detection and transmission
- Fax calling tone detection and transmission
- Line interconnect and conferencing
  - Conferencing AGC (Active talker evaluation)
  - Between IP peers
  - Between E.1/T.1/S0 and IP peers
    - Line interconnect between Diva Media Boards (hardware) and Diva softIP
      - Uses PCI/PCIe BUS master DMA of the Diva hardware for the transport of data between the Diva hardware and Diva softIP.
- T.38 up to V.34 (33600 Bps)
  - MR/MMR/T.6
  - Intelligent fax processing
  - Super/Ultra fine and Color fax
  - Polling
  - More documents

Acceleration of softIP by Diva hardware

It is possible to offload media processing tasks from the host to Diva media boards (hardware). In the case that all available Diva softIP channels are offloaded to Diva media boards (hardware) then the Diva softIP media processing part is not used.

To offload softIP media processing to Diva media boards it is necessary to change the configuration of the Diva media board to “Resource Board Mode”. In this case the TDM interface (BRI/PRI/E1/T1) of the Diva media board is deactivated and the Diva board can be used by the softIP signaling and media control part for media processing and streaming.

Using a Diva board for media processing, softIP can use all media processing features provided by the Diva board. This depends on the Diva hardware and the available CODEC licenses of the Diva Media Board (mainly used on Diva V-xPRI media boards):

G.168 Echo cancellation with up to 256 ms tail length
G.729, G.726 32 kbps, GSM-FR, iLBC
Extended tone detection

Human talker detection, MF detection, ...

Tone generation
Suppression of ambient noises
DTMF clamping (suppression)

Receive AGC (Automatic Gain Control)
Transmit AGC
Digital gain control
Clear channel fax
- Up to V.34 (33600)
- MR/MMR/T.6
- Intelligent fax processing
- Super/Ultra fine and Color fax
- Polling
- More documents

The Structure of Diva softIP

Diva softIP is built using two parts

SIP signaling and media control part
media processing and streaming part

The SIP signaling and media control part always runs in user mode.

The Media processing and streaming part can run in user mode (default) or in kernel mode.

Due to the “isolation” by the IDI interface Diva softIP uses the same Diva CAPI/TTY drivers as the Diva boards.

The Media processing and streaming part uses, if in kernel mode, the same Diva kernel mode streaming driver as the Diva board.

Diva softIP Licensing

Diva softIP uses licenses that are locked to the specific host (PC hardware). You need to activate the PPC (proof of purchase code) on the Dialogic Activation web page. In order to identify your PC you need to use the provided “softIP System DUID” (see licenses manager of the Diva WEB configuration manager). This then allows you to request the license file (LIC). The file will be sent to the email address you have specified.

Diva softIP Configuration

Once the license is applied “virtual softIP boards” will appear in the “Board configuration”.
After clicking on the softIP symbol you will proceed to the softIP configuration.

You need to edit the mapping table. This table allows to establish a mapping between the Calling and Called party numbers and SIP addresses and to create registrar entries.

Use of a Diva Media Board (HW) in Resourceboard-mode with softIP

Please use the configuration tool of the Diva media board to change the board configuration to “resourceboard”-mode.

After the configuration has been changed to resourceboard mode the ISDN BRI/PRI or E1/T1 interface of the Diva board is deactivated and the board resources are available for softIP (for media processing). The number of available media processing resources is equal to the number of supported channels. As a result of offload to the Diva board the softIP symbols in the board configuration will disappear, if media processing for all available softIP channels are moved to Diva hardware boards.

In case the Diva board (hardware) provides multiple ports (interfaces) you can change the configuration on a per port basis.

The provided Diva board media processing resources depend on the type of Diva board in use and/or on the installed licenses (Fax, Modem, G.729 and other CODECs).

softIP T.38 support

Diva softIP media processing provides support for T.38 in a fully transparent way. The application does not need to be changed. Applications that have been developed for Diva CAPI, Diva API and Diva TTY FAX CLASS 1 or FAX CLASS 2 can be used without any changes.

All Fax T.30 features that have been available on the Diva boards are available if using T.38 (V.34, ECM, MR/MMR/T.6, Ultra and Super fine resolutions, Color fax, non standard paper formats). Global Diva softIP fax T.30 configuration options can be used in the same way as when using Diva media boards (hardware).

Clear channel fax support with Diva softIP

The use of with softIP with a Diva board (hardware) for media processing allows using clear channel fax. The used Diva media board (hardware) needs to offer fax support.

Support for clear channel fax is provided fully transparent to the application. The application does not need to be changed. Applications that have been developed for Diva CAPI, Diva API and Diva TTY FAX CLASS 1 or FAX CLASS 2 can be used without any changes.

All available Diva fax T.30 features are available if using clear channel fax (V.34, ECM, MR/MMR/T.6, Ultra and Super fine resolutions, Color fax, non standard paper formats). Global Diva board fax T.30 configuration options can be used in the same way as if using ISDN BRI/PRI or E1/T1 interfaces.

Use of softIP with Chan_capi

From the point of view of Chan_capi softIP channels are available via one or more CAPI controllers each one with 1 to 30 channels.

No changes in Chan_capi are necessary to support softIP. All Chan_capi media commands can be used for softIP. The “receivefax” and “sendfax” Chan_capi commands can be used to receive and send fax documents using T.38 and/or clear channel fax.

Diva boards (provided by) and softIP can be installed and used by Chan_capi in one system. Chan_capi can use native bridging (line interconnect) and conferencing (chat) commands for interconnecting media streams (phone calls) between softIP and Diva boards (hardware).

The configuration of Chan_capi for softIP is provided in the Diva WEB configuration tool.

Diva softIP configuration and sip.conf

When activating SIP support (sip.conf) please ensure that softIP and sip.conf are using different ports to prevent IP port conflicts between sip.conf softIP SIP. Otherwise sip.conf may activate functionality that is then provided by softIP.

Diva softIP and G.168 echo cancellation

In IP networks it is the standard procedure to cancel echo at the gateway between the PSTN and the IP network. But certain gateways do not support G.168 echo cancellation. In this case it is necessary to cancel the echo in the IP network.

If Diva softIP is used with a Diva board (hardware) in resourceboard mode then it is possible to activate G.168 echo cancellation with a tail length of 256 ms to suppress echo in the IP network. Please use the Diva configuration tool to activate the echo tail length of 256 ms

Use of Diva and CHAN_CAPI for deployment of high quality PBX

2009-04-20T02:09:00.000-07:00

Use of Diva and CHAN_CAPI for deployment of high quality PBX

The modern PBX is not only a tool to switch between call parties and to forward the calls. And this is not only the PBX which is enriched by voice mail system. The requirement to modern PBX design are originated by the requirement to improve the user experience in the environments where telephony is used as major tool (support centers, sales, call centers, ...).

Following features are proven to improve the user experience:

Echo cancellation with 256 mSec tail length
Suppression of in band DTMF tones
Voice signal limiter (FCC Part 68)
Automatic gain control combined with digital gain control
Control of playback and recording speed (pitch control)
Suppression of ambient noises
Conferencing AGC (Automatic Gain Control)
Interactive media control, VC command
Use of IP resources for E.1/T.1/S0/PSTN and IP connections
Connections between E.1/T.1/S0/PSTN and IP

This document provides the in depth description of the features and the scenarios where (and how) the features can be used while the detailed description of commends can be found in README.media.

Echo cancellation with 256 mSec tail length

The vast majority of the public telephone system local loop wiring is done using two-wire connections whereby the same pair of wires carries voice signals in both directions. In the telephone company's central office or in an office PBX, a two-to-four wire conversion is done using a hybrid circuit. Hybrid circuits do not perform perfect impedance matches. The imperfection results in echo. The echo canceller's goal is to detect and remove echo as quickly and effectively, thereby minimizing any loss in voice quality due to the echo. The echo canceller must perform this function under all conditions including double-talk (when both parties are speaking at the same time) and in the presence of background noise. Furthermore, the echo canceller must not cause detriment to signaling tones (DTMF etc.) or fax and modem transmissions.

Diva supports echo cancellation (in accordance to G.168 with NLP) with tail length up to 256 mSec.

256 mSec tail length is required to ensure the operation in the environments where the signal is carried over the packet network. This is not always the case at customer site and can be done by transit network which does not provides own echo cancellation capabilities.

You can activate (deactivate) echo cancellation per call using “echocancel” command or generally using “echocancel” configuration parameter in capi.conf. “echocancelnlp” configuration parameter (capi.conf) is used to activate (deactivate) NLP (Non Linear Processor which removes the residual echo at the output of the echo cancellation unit). You can use Diva chan_capi configuration to change this capi.conf configuration parameter.

Upon detection of fax or modem transmission Diva echo cancellation is automatically deactivated. Diva echo cancellation is not activated for digital (voice, data, ...) calls.

Suppression of in band DTMF tones

DTMF (dual-tone multi-frequency, http://en.wikipedia.org/wiki/DTMF) tones are used for transmission of dialed digits. In PBX environment DTMF is often used to control the PBX functionality (connect to voice mailbox, redirect calls, initiate and control conference, ...) after the connection was established. Passing DTMF tones can be desirable in certain scenarios (for example pass tones through primary PBX to secondary PBX where users can access certain services).

But passing the DTMF trough can be unpleasant for users or introduce security leaks in PBX environment in other scenarios. For example if one of the conference members will by occasion pressed the key on his phone then the DTMF signal is sent to all other members. DTMF signals are loud (user experience compared to human voice) and will disturb other members. Given one large conference with high amount of members pressing of keys by users can change from occasional to regular event and conference will receive unuseable for members. The same is true for the call agent in the support or in the call center. While receiving the calls over long period of time the person should be protected from loud and unexpected signals, in this case from sent by occasional pressing of the phone keys by users.

The security is affected if the DTMF sequences are passed to location where it should not arrive. For example passing of DTMF through PBX connection gives the user the potential ability to control the equipment behind of PBX. Members of conference can record the DTMF sequences and receive passwords to control the conference, recorded on the voice mail message DTMF tones can be used to trigger certain events in PBX at time message is played back. The list is endless, but in the most of cases the users who are not allowed to access certain services (calls, mailboxes, ...) will receive access to appropriate services.

Diva provides the possibility to suppress the DTMF tones. This feature is available on per call basis and can be activated (deactivated) using “clamping” command. To activate this feature globally please use “Extended Voice Processing/DTMF Clamping” Diva configuration option. Diva will automatically deactivate clamping for digital (data, video, ...) commections.

The feature is always activated for Rx direction only. To activate this feature for both (all in case of conference) directions this is necessary to send this command to both (to every) peer.

The implemented by Diva DTMF suppression (clamping) does not affects the quality of the voice signal and it is even possible to receive overlapped by DTMF tones voice sequence.

Voice signal limiter

Voice signal limiter (FCC Part 68 Limiter, http://www.fcc.gov/wcb/iatd/part_68.html) is used to limit the signal power and to protect the listening on the phone equipment people from unexpected and too loud signals.

You can activate this feature for PBX interconnections and for conferencing. Part 68 limiter is automatically activated by Diva in countries where required by approvals. You can activate it by “Extended Voice Processing/Part 68 Voice Signal Limiter“ Diva configuration option. Diva will automatically deactivate Part 68 limiter for digital (data, video, ...) connections.

Automatic gain control combined with digital gain control

In case of conferences or if dealing with huge amount of callers in support or call center it is beter to equalize the loudness of the speakers. Rx AGC can be used for this purpose. If active it will preserve the level of the received signal at -14 dB. You can adjust the level to the personally best one using the digital gain control commands.

Other use of this feature is to ensure all voice mail messages are recorded with same signal level. This simplify the processing of huge amount of voice messages.

In addition AGC and digital gain control can be activated in transmit direction too. This feature can be used to play back voice messages which are recorded using different levels and to control the level of the signal in case this feature is not supported by peer.

You can control the levels of the Rx and Tx path independent one from the other. Following commands allow to activate (deactivate) AGC and digital gain control on call basis: “rxagc”, “txagc”, “rxdgain”, “txdgain”, “incrxdgain”, “inctxdgain”.

The AGC can be used if signal source is not normalized. Digital gain can be used to change the level of the signal. Both features are independent one from the other but in multiple scenarios used together.

Control of playback and recording speed (pitch control)

Some time user needs to play same voice mail message multiple time. It is often the case if phone numbers or other information of interest is contained in the call. In this case it is desirable to play the voice message slower.

In other case user needs to jump over the part of the long message to the information of interest. In this case it is better to play message faster.

Provided by Diva pitch control feature can be used to provide this functionality. The pitch control is accessed using “pitchcontrol” and “incpitchcontrol” commands. Using pitch control is possible to change the sampling rate of signal and as result play messages faster or slower.

This feature can be used only for playing back and for recording of voice messages. This feature is not available for connections between two or more parties.

Suppression of ambient noises

In the time of phone call or of one conference multiple ambient noises can lead to decrease of the level of understanding. It can be the noises from computer fans, projector fans, air cooling system, ventilation system, street noises trough open window, car noises, ...

Diva provides the possibility to suppress the ambient noises. The suppression of ambient noises can be activated using “noisesuppressor” command on per call basis or generally by “Extended Voice Processing/Noise suppression“ Diva configuration parameter.

Conferencing AGC

Several problems occurs if multiple parties are joined to conference.

First one is the summation (and as result increase of level) of noises if nobody in the conference is speaking. The noise signal will be added even if the phone is muted. In this case this is the own phone and line noise.

The other problem occurs if multiple people are are speaking at same time. In this case it is necessary to identify the real active talkers and protect they signal from received from listeners occasional signals. If not done then occasional signals from multiple conference members will affect the signal from active talkers. As result the listeners will stop to understand the talkers. This problem still can be resolved by deactivation of voice patch from listeners. But it results in need for one conference manager and conference management tools. And in this case listeners are not able to issue question and notes spontaneously. They need to receive the permission from conference manager first.

To resolve all mentioned above problems Diva provides conferencing AGC. Conferencing AGC receives automatically active as soon as more then two members have joined the conference.

Interactive media control, VC command

Multiple media control commands (volume control, playback speed control, ...) are usable only if media change can be applied to media directly without delay and without changes in the position of the media. Unfortunately currently available in Dial Plan set of commands does not provides necessary features.

To overcome this problem “vc” command is add to chan_capi. You can use this command to attach any provided by chan_capi command to sequence of DTMF (MF/Pulse, detection of tones, ...) digits. If active chan_capi will process received events and perform required action upon detection of event of interest. In this way events are processed without entering the Dial Plan. As result required action is processed without affecting the position of the media stream.

With other words “vc” command allows to create menu which binds certain events to certain chan_capi commands and to process this menu in front of Dial Plan while media is active.

The suggestion is to create small menus which do not involve more then one DTMF digit. Most of media commands require very short response time which can not be provided if user need to press multiple keys. The use of preprogrammed keys (single key sending multiple DTMF digits) still can use multiple digit, but the duration of single DTMF digit ~ 100 mSec plus inter digit pause. This again enforces the same limits. The big menus are not used by users too.

Good choices for conferences and for regular calls are: Increase and decrease level of signal, mute/un-mute tx direction, activate/deactivate suppression of ambient noises:

Useful set of commands if processing voice mailbox can be:

You can see used in previous menu keys “3” and “4” are left empty. The new functionality is assigned to still unused keys “8” and “9”. This is done to prevent the user confusion if switching between different menus.

In one conference can be useful to send one tone to track the attention of the conference members to certain event. This can be done using “sendtone” command:

chan_capi forum at DEN at www.dialogic.com/den

2009-04-20T02:00:00.000-07:00

This is new forum for support of Diva chan_capi users (but everyone wellcome) at DEN (Dialogic Exchange Network) www.dialogic.com/den.

Please follow link and register and finally ask gplcoder for access.

Use of DSP resources for conferences with IP members

2009-04-20T01:59:00.001-07:00

The "chat" command allows to create conference with multeple rooms. This allows to create conference between E.1/T.1/S0/Analog and IP members in fully transparent to user way. "chat" command always detects the type of connection and uses appropriate resources.

The implementation of "chat" for IP endpoints uses Diva NULL PLCI. While this resource is available for every Diva hardware and allows to create high amount of IP endpoints running parallel to E.1/T.1/S0/Analog endpoints on the same Diva hardware it does not allows access to DSP resources for IP conference members.

This is the reason why new "resource" command is added to chan_capi. This command allows to assign DSP resource to IP conference member. This is no need fo user to check the type of connection and the type of Diva hardware is using this command. The "resource" command detects automatically the type of connection and type of hardware and perform requested actions only if necessary and possible.

The other more general way to use DSP resources for IP connections is to use Diva softIP. In this case IP traffic is processed by Diva protocol stack and presented as E.1/T.1 interface to chan_capi. This is not IP connection from the point of view of chan_capi and no additional commands are required.

Example (from README.media):

[isdn-in]
exten => _X.,1,Answer     ; Answer the line
exten => _X.,n,Goto(s,1)
exten => s,1,capicommand(resource|1-4)           ; Create DSP resource on CAPI controllers 1-4 for IP members, ignore command for E.1/T.1/S0/POTS members
exten => s,n,capicommand(clamping|100)         ; Activate suppression of DTMF tones
exten => s,n,capicommand(rxagc|yes)            ; Activate Rx AGC
exten => s,n,capicommand(noisesuppressor|yes)  ; Activate suppression of ambient noises
exten => s,n,capicommand(vc|incrxdgain|0|1.5)  ; Install voice command menu for volume control, '0' to increase volume
exten => s,n,capicommand(vc|incrxdgain|1|-1.5) ; Install voice command menu for volume control, '1' to decrease volume
exten => s,n,capicommand(vc|txdgain|2|-128) ; Install voice command menu for volume control, '2' to mute tx path
exten => s,n,capicommand(vc|txdgain|3|0) ; Install voice command menu for volume control, '3' to activate tx path
exten => s,n,capicommand(chat|test1|m|1-4)     ; Craete/enter conference toom 'test1', controller field is ignored if media processing resource is assigned by 'resource' command or for E.1/T.1/S0/POTS members

Supported hardware (from README.media):

Supported hardware:
 Assign DSP resources to connected by IP network conference member. This feature is available
 for equipped with DSP Diva hardware only.

 For Diva 2PRI PCI, Diva 4PRI PCI, Diva 1PRI PCIe HS, Diva 2PRI PCIe HS and Diva 4PRI PCIe HS no
 restrictions apply for this feature and this is possible to access N x 30 DSP resources
 (N - amount of interfaces, 1 - 1PRI, 2 - 2PRI, 4 - 4PRI) in addition to used for E.1/T.1
 DSP resources.

 For Diva PRI Rev.3 PCI and Diva PRI Rev.3 PCIe this is possible to reserve two DSPs for processing
 of E.1/T.1 without media processing features and share remainding DSPs between E.1/T.1 and IP
 for connections with media processing features.
 Using hardware with 30 DSPs and E.1 this is possible to create:
   From:  2 x E.1 without media processing + 28 x E.1 with media processing
   To:   30 x E.1 without media processing + 28 x IP with media processing
 Using hardware with 30 DSPs and T.1 this is possible to create:
   From: 23 x T.1 with media processing    +  7 x IP with media processing
   To:   23 x T.1 without media processing + 28 x IP with media processing

 For Diva BRI-2M Rev.2 PCI, Diva BRI-2M PCIe, Diva 4BRI Rev.2 PCI and for Diva 4BRI PCIe
 this is not possible to reserve DSPs for processing of ISDN connections and to share
 DSPs between ISDN and IP connection. In case DSP resources are assigned to connected
 by IP conference member then appropriate DSP resources receive not available
 for processing of ISDN connections. As result ISDN connections can not be processed.
 To resolve this problem please use Diva configuration to change the configuration
 of Diva board to resourceboardmode. In resourceboard mode ISDN interface is deactivated
 and all available DSP resources (two DSPs for Diva BRI-2M and eight DSPs for Diva 4BRI)
 can be used for connected by IP conference members (two members for Diva BRI-2M and
 eight members for Diva 4BRI).

T.38 and Clear Channel fax support by chan_capi

2009-04-20T01:58:00.000-07:00

chan_capi supports both FoIP (Fax over IP) standards: T.38 and Clear Channel fax with V.34, ECM, intelligen fax processing, on demand change between voice and fax. All provided by Diva hardware in TDM (E.1/T.1/S0) environment fax features are available for T.38 and Clear Channel Fax.

In case chan_capi is used to terminate or initiate the fax transmission all necessary features are provided by Diva softIP. softIP exposes one CAPI interface towards
chan_capi and SIP interface towards IP network.
This is no need to change chan_capi configuration. This is only necessary to specify softIP as CAPI controller. All other configuration details are handled by Diva softIP configuration.

Diva softIP allows to preserve all voice features. This is possible to process voice calls over IP and switch between voise and fax media. Diva softIP can be used
in one system with Diva hardware and supports line interconnect (conferencing) between processed by Diva hardware and by softIP voice streams.

In case softIP is used with one or more Diva boards in resource board mode then V.34 Clear Channel Fax and G.729, iLBC, G.726, G.723, GSM and other vocoders receive available for chan_capi.

softIp can be used in virtualized environment (VMWare, XEN, ...)

Dial Plan: Conference with multiple rooms and media control

2009-04-20T01:57:00.000-07:00

[isdn-in]
exten => _X.,1,Answer ; Answer the line
exten => _X.,n,Goto(s,1)
exten => s,1,Set(TIMEOUT(digit)=5) ; Set Digit Timeout to 5 seconds
exten => s,n,Set(TIMEOUT(response)=10) ; Set Response Timeout to 10 seconds
exten => s,n(restart),BackGround(demo-instruct) ; Play some instructions
exten => s,n,WaitExten ; Wait for an extension to be dialed, use to select conference room

New Diva DEMO system online

2009-04-20T01:52:00.000-07:00

New Diva DEMO system is online and allows to take a look on the changes in the future version

chan_capi configuration
New sipControl features
SS7 integration

Please use link: Dialogic® Diva® Configuration live demo system