Diva configuration allows to manage capi.conf

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

(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

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

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

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.