Howto16r1:Conferences, Resources and Licenses

FIXME: This product is in the beta phase and is not yet finished

Applies To

This information applies to

all innovaphone devices supporting a CONF or SCNF interface and hence Conference Channels (as shown in the devices home-page).

More Information

Performing conferencing on a CONF or SCNF interface consumes both resources and licenses. Here is an overview of which and how much.

Overview

First let us have a look at the overall scheme:

Coder channels

Both the CONF and SCNF interface provides the mixing of 8KHz G711 PCM audio channels.

If a call is done towards a CONF interface, it will allocate a Coder channel from the DSP coder channel bank for processing of the audio from the VoIP codec (e.g. G.711, G.722, OPUS) to PCM audio.

The SCNF supports G.711a/u and G.722 coder. No Coder channel needs to be allocated for a call.

(Soft) Conference Channels

Each call to a CONF interface consumes one of the Conference Channels.

Each call to an SCNF interface consumes one of the Soft Conference Channels.

Channels license

In addition to that, a call to either the CONF or SCNF requires a Channel license. This license can be obtained from the PBX if the PBX Channels licenses switch in the PBX Conference object is activated (if the call comes through such an object) or the Obtain Channels lic on outgoing call check-mark is ticked in a PBX Gateway object (if the call comes through such an object). For this, PBX Channels licenses must be installed on the PBX.

This is the recommended configuration. However, the Channel license can also be obtained locally from the gateway where the CONF/SCNF is located on. All innovaphone gateways have a number of Channel licenses built-in. The number of licenses available is equal to the number of Coder channels the box supports. If no license is sent along with the call to the CONF or SCNF interface, the interface will try to obtain one from the pool of built-in licenses. This can save you some cost. However, be aware that these licenses (as well as the corresponding Channel coders) are also required for calls through the ISDN BRI/PRI interfaces or for audio fax calls. Calls to CONF/SCNF interfaces which consume local Channel licenses may inhibit such calls therefor.

The PBX-Channels License has order no. 02-00020-007 according to chapter "3.5 PBX Channels license" in the innovaphone license guide.

The status of the PBX Licenses shows assigned PBX-Channel licenses:

Port license

The registration of the CONF and/or SCNF to the PBX Conference object does not require a Port license.

Although this is not directly related to the CONF or SCNF interface, please note that a single Port license is required if any of the rooms defined in a PBX Conference object is accessed using the conference web access (from 13r3).

CPU usage

For a calculation of CPU usage see Howto:V13_Firmware_Upgrade_V13r2_V13r3#Conferences.

Example Scenarios

Conference on hardware gateway with local ISDN

Let us assume we have a conference running on a CONF interface with one PSTN and 3 VoIP participants. In this case, we have

	Caller	DSP Coder Channel	Conference Channel	PBX Channel License
	1 PSTN	1 (CONF) + 1 (ISDN) **	1	1
	3 VoIP	3	3	3
Total	4	5	4	4

**:

FIXME: do we need only one or would this require enable PCM?

Looking at an IP411, it supports the following resources:

We can see that our sample scenario will not work on an IP411 as there are no Conference Channels available. However, if we change the scenario so that an SCNF is used instead of a CONF, it would look as follows:

	Caller	DSP Coder Channel	Soft Conference Channel	PBX Channel License
	1 PSTN	1 (ISDN) **	1	1
	3 VoIP	3	3	3
Total	4	4	4	4

This will work on an IP411.

3PTY Conferencing

3-way conferencing is special as it is usually implemented internally in the innovaphone IP phones. That is, each user of an innovaphone IP phone (except the IP61) has internal conferencing resources built-in to allow for a 3-way conference. No external CONF/SCNF interface is needed.

However, on innovaphone DECT phones, no internal conferencing resource is present and hence no internal 3PTY is possible. The DECT system can thus be configured to use an external conferencing resource for 3PTY. In this case, the rules above apply.

Conference Scaler

With 16r1 we introduce a new App "Conference Scaler", with the Conference Scaler it is possible to cluster multiple SCNF Interfaces into one registering Endpoint at a conference Object, for more please refer to the concept article

Ressource consideration

Conference Channels

If using the conference scaler and multiple interfaces you need to take into account to be sure how much conference channels are actually used, even if they are not be seen. Let's have a look what happens for each room inside a Conference object that uses the conference scaler:

• As soon as a room has been opened on more than one interface (this will be the case when having at least 2 participants), the audio is only transmitted between the Interface and the locally connected participants
  • To share audio between interfaces, the conference scaler will allocate a RTP Port on both interfaces
  • This Socket will be exchanged between both interfaces, so that both interfaces know where to connect to
  • Now, as both interfaces have the needed information, both interfaces will join to the other Interface as an "invisible" participant, taking up one more extra conference channel on both interfaces
• As we have learned in the concept article, the conference scaler will allocate one random interface as primary interface, this Primary interface will then be used to connect all used interfaces and mixing the audio. Let's go through this with our already existing scenario:
  • Now we have two participants on two interfaces which are connected together ( and the conference scaler has already selected Interface 1 as the primary interface in the beginning of the conference call)
  • Another participant joins the conference call, therefore this room will also be opened at interface 3
  • As Interface 1 is the primary Interface, interface 3 will join the conference room ONLY at interface 1, taking up another conference channel as "invisible" participant (Interface 3 does not need to join interface 2 because the audio from interface 2 is already transmitted to interface 1, our primary interface)
  • Interface 1 will also join interface 3 as "invisible" participant, taking up one conference channel on interface 3
• Now we have 2 Interfaces connected to interface 1 and interface 1 is connected to 2 interfaces as participant
• This is the flow for every conference room you are using at that conference object, for the next room the conference scaler might select Interface 3 as primary interface, in this case he will join both interfaces as participant and vice versa (also taking up conference channels here as well) - but only if this conference call has at least these 3 participants (as the interfaces will be used in a round robin manner)
• The primary inertface will now receive audio from both interfaces, which will be the mixed audio from both interfaces, and distributes it to the other interfaces + it's own audio mixed together
  

For Room 1 it will look like this:

Interface 1 (Primary Interface)	Interface 2	Interface 3
Participant 1	Participant 2	Participant 3
Interface 2 ("invisbile participant")	Interface 1 ("invisbile participant")	Interface 1 ("invisbile participant")
Interface 3 ("invisbile participant")

Related Articles

• Reference9:Concept myPBX
• Reference10:Concept Innovaphone Virtual Appliance
• Reference9:3pty conference on DECT phones
• Reference10:Gateway/Interfaces#Conferencing_interface_.28CONF.29
• Howto:How_to_implement_large_PBXs#Technical_data_and_recommended_number_of_users_supported, lists DSP and CONF resources for the different gateway platforms