NaturalConference development environment

This topic presents the following information:

NaturalConference system architecture

On NMS Communications AG and CG boards, NaturalConference functions communicate with enhanced voice processing modules running on digital signal processors (DSPs):

DSPs or DSP pools located on AG and CG boards can be programmed to support IVR, fax, IP telephony, or NaturalConference. NaturalConference requires dedicated DSPs. DSPs programmed for NaturalConference cannot be used for any other feature.

For information about specific board configurations, refer to the board-specific installation and developer's manual.

Although the voice channel associated with a particular member joining a conference does not have to be on the same board as the conference, the application must perform the appropriate switching to connect the new member's line to the conference. If the member comes from the same board, make a local-stream-to-local-stream connection; otherwise, make a bus-stream-to-local-stream connection.

For more information about switching, refer to the Dialogic® NaturalAccess™ Switching Interface API Developer's Manual and the Dialogic® NaturalAccess™ Point-to-Point Switching API Developer's Manual.

NaturalConference data flow

NaturalConference performs processing for each member's voice input individually, mixes according to the conference attributes, and generates the output signal for each member. The following illustration summarizes the processing chain performed by the conferencing code:

You specify conference capabilities such as DTMF clamping and echo cancellation when you declare the conference resource or create the conference. Other settings, such as the number of loudest speakers, can be changed dynamically. You specify settings (or attributes) such as talking and listening activity and gain control on a member by member basis.

Resource handles and conference and member identifiers

Any call to NaturalConference requires a conference resource handle (cnfresourcehd). A conference resource handle links a context and a conference resource. An application can create as many of these paths as necessary among contexts. To obtain a conference resource handle, open a conference resource with cnfOpenResource. Once you have a cnfresourcehd, you can create conferences and add members to them.

When you create a new conference, a unique conference identifier is generated and returned to the application. Similarly, when you add a new member to a conference, a unique member identifier is generated and returned to the application. NaturalConference also provides enumeration functions to retrieve existing conference identifiers on a given resource and existing members on a given conference.

By opening a resource and creating a resource handle on a given context, the application implicitly designates which queue returns the events for the conferences created by that resource handle. The following illustration shows the relationships between Natural Access objects, resource handles, and conference identifiers:

The actual link between Natural Access and a NaturalConference object is performed at the resource handle level. Create resource handles using ctahd in the same way that instances of ctahd can be created on a queue.

Refer to the Function reference section for a complete description of NaturalConference functions.

Regulatory constraints

Telecom regulatory authorities regulate the use of NaturalConference in some countries. These regulations address two aspects of conferencing:

Since these aspects vary with the applications developed using NaturalConference and the countries where NaturalConference is installed, NMS Communications does not obtain type approval for NaturalConference. Contact the regulatory authorities in the country where you plan to install NaturalConference to learn the regulations for applications developed with this product.