Diva System Release - Version 9.0LIN SU1 (final)

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

'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

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

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

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

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

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

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