Course11:Advanced - Audio Conferencing

From innovaphone-wiki

Jump to: navigation, search

This book is about the building blocks available in the innovaphone PBX to support audio conferencing functions.

Contents

Overview

Traditionally, 2 types of audio conferencing are distinguished in PBX systems
  1. Three-Party Conferencing (3PTY)
    This type of conferencing involves 3 parties only and is initiated and controlled on an ad-hoc basis by a user using the phone user interface (usually some sort of a function key). The technical resources required to implement the conference (namely the audio-mixing capability) may be present in the initiating users terminal device (ie. phone) or as a shared resource within the PBX
  2. Multi-Party Conferencing
    This type of conferencing involves conferences with 3 or more participants. The conference control usually is only partly available on the users terminal (ie. phone), if at all. Instead, dedicated interfaces like IVR applications, voice menus or web applications are used. The technical resources required to implement the conference (namely the audio-mixing capability) usually are provided as a shared resource within the PBX
This book discusses mechanisms available in the innovaphone PBX to implement multi-party conferences.

Mixing

To implement an audio conference, an audio mixing capability must be available which receives the audio from the participants, merges all of them and echoes the result back to the participants. This function is present in the gateway fish-help.png CONF interfaces available in many of the gateway products.

A CONF interface has the notion of a conferencing room. A room is a set of calls destined to the interface which share the same audio. It is identified by a room number. In other words, all calls in the same room are members of the same audio conference.

The CONF interface has commands such as screenshot.png create new room or join room. Such commands are invoked by sending appropriate digit strings as part of the called number when a call to the interface is made. They are referred to as fish-help.png Call-Setup Commands therefore. For example, the command for creation of a room with a given room number is *2<number># in its simplest form. The command for joining an existing room is simply the room number itself followed by a hash mark (#).

Commands may have further options which follow the command in the called number. For example, the *1 command (Create a new room with a unique room number) can have a *3<prefix> option: *1*32 (create a new room with room number prefix 2).

Difference between commands and options


As you finished reading this page, you probably noticed that the CONF interface interprets called numbers containing the '*' digit followed by a number. The text and also the wiki refers to this '*' - number sequences as commands or options. Commands and options look the same but have a very different role for the CONF - interface.
  • commands can create new room or join room
  • options can be appended to commands to specify more exactly how a conference room is created or joined but cannot be used without a command in the first place
Because commands and options look very similar, students are often confused and have problems understanding this topic. The fish-help.png current list of commands and options is of course in the wiki. It is recommended to print out the mentioned wiki page and have it at hand while reading the book and configuring the lesson.

As far as this lesson is concerned, you can disregard the *82 option along with all those ''innovaphone remote control'' facilities. These are for programmatic access to the CONF interfaces only.

Conference Control

There are a number of control functions which may make sense in a conference. The most important being
  • conference creation
  • conference destruction
  • joining a conference
  • leaving a conference
  • inviting to a conference
  • muting participants
There are various objects in the PBX which can be used to implement conference control. Regardless which scheme is used, all calls of all participants will ultimately end up in a single CONF interface as described in the previous chapter.

In a very simple setup, all users simply call into the same conference room (the number of which is pre-known by all participants). The initiator creates the conference, all others will join after that. This can be screenshot.png implemented easily using a PBX fish-help.png Gateway object. In this setup, all participants will dial-in to the conference at their own discretion.

However, more sophisticated scenarios may be required. As an example, the fish-help.png Call Broadcast Conference object (a.k.a. BC-Conference) screenshot.png can be employed to implement features such as
  • automatic invitation of participants when the conference is created
  • destruction of the conference as soon as there is only one remaining participant
  • closed user group conference
and more. In addition to that, the Call Broadcast Conference object will hide the details of the CONF interface commands from the user.

The audio-conference creation scheme which had been implemented in myPBX V9 has been removed from myPBX V10 though.

Another approach suitable for system integrators is to have a custom-developed XML script running in a fish-help.png Voicemail object control a conference.

The remainder of this book will concentrate on the use and configuration of the CONF interface itself.

Participant Control

In addition to the call-setup commands, the CONF interface provides some fish-help.png in-call commands which are invoked using DTMF tones during the call. They allow a participant of the conference to mute all other participants. This is especially useful in a presentation-like conferencing setup, where all but one participants listen to a presenter.

A single participant will be muted when the CONF interface receives a remote hold indication within the call from the participant. This may happen when the user holds the call to the conference, e.g. when pressing the R-key to initiate a consultation call. Muting this participant will make sure the music on hold sent by the participant is not echoed into the conference. Likewise, when the call is retrieved again, the user is un-muted.

For this to happen, the respective call signalling events must make it all the way from the participant to the CONF interface. While this happens automatically if the participant uses a VoIP terminal within the same PBX system, it may fail if she is somehow remote, e.g. an external user calling in via a SIP trunk or an ISDN trunk line. Also, some terminals do not signal a hold event at all. At least, you need to enable interworking (that is, set the fish-help.png Interworking check-mark) on all the fish-help.png gateway routes used in the call path, including the routes to the CONF interface itself!

Aggregation

A conference room does not span over more than one CONF interface. An audio conference always resides on a single CONF interface thus and as a result, a single conference cannot support more participants than the most capable single conferencing device can. However, multiple conferencing devices can be aggregated such that a huge number of conferences are supported - as long as any single conference can be handled by one of the devices available in the aggregation.

The aggregation scheme is quite simple: all devices which shall be aggregated need to screenshot.png register with a single PBX object. Based on the fish-help.png standard re-routing mechanism found in the fish-help.png PBX Gateway Object, a call to a gateway object will be sent to each of the peers registered to the gateway object sequentially until one of them accepts the call. A CONF interface which cannot satisfy the conference command (either because a room needs to be created and the appropriate resources are not available or because a room should be joined which does not exist in this CONF interface) will reject the call with a No circuit/channel available cause code, which triggers the re-routing logic mentioned above. The exact same call will then be sent to the next available CONF interface until one of them can satisfy the command or there is no interface left.

[ please note that the very same re-routing logic is implemented in the trunk interface too. For this reason, fish-help.png Trunk Line objects can be used too. However, as the extra properties and features such an object provides are not needed for conferencing, the use of a fish-help.png PBX Gateway Object is recommended ]

Configuration

This chapter will go through the configuration of the CONF interfaces in an aggregated setup in more detail.

For the remainder of this book, let us assume we have a setup with a single PBX (an IP302) and 2 conferencing devices (an IP305 and an IP800). Both shall be aggregated and the conferencing features shall be made available through a PBX Gateway object. The gateway object has its Number property set to 40 and is called Conference.

The IP800 is used to drive a BRI trunk line, so only 8 of the 10 possible DSP channels must be used by the CONF interface. The IP305 however is used as a PBX only, so all 4 DSP channels may be used there.



The PBX Object

The PBX object used to access the CONF interfaces serves 2 purposes
  1. it defines the number and/or name to access the conferencing facility
  2. it implements the aggregation logic
Both the fish-help.png PBX/Objects/Trunk Line and the fish-help.png PBX/Objects/Gateway object have the re-routing logic required for the aggregation built-in. However, the Trunk Line object has many additional features which are not used in this context, so the Gateway object is the natural choice here. The available CONF interfaces screenshot.png will register with the PBX Gateway object thus.

As the CONF interfaces doesn't care about the number used to access the Gateway object itself, the Prefix property should be set in the screenshot.png object configuration.

Routes to the CONF Interface

As discussed before, all the available CONF interfaces register with the Gateway object representing the aggregated conference facility. If this is done, default routes will be created from and to the CONF interface (this is done by default like for all other interface types, although there will never be calls from the CONF interface to the Gateway object and these routes are thus never needed).

As we will see later in this book, calls to the CONF interface need to be manipulated and this is best done using interface maps directly at the respective CONF interface. This works fine, however, you need to recall that interface maps do not work well with overlapped sending. This will create a problem when calls to the conference facility are done manually (as opposed to being created automatically through a fish-help.png BC Conf object). It is thus important to turn on the Force enblock checkmark on all routes from the registration to the Gateway object to the CONF interface!

Also, as we have discussed in Participant Control above, the Interworking(QSIG,SIP) check-mark screenshot.png must be ticked.


Setting a default Value for the *2 option

When no channel reservation is done, no channels are reserved for a conference room. Sounds pretty straight forward, however it isn't. When creating a room without reservation, the request will be satisfied even if there is only a single channel left on the device, resulting in a room where nobody else can join. Not very useful!

If you have a single conferencing device, then it is not a big deal. Without reservation, you get a room no-one can join. With reservation, you don't get the room in the first place. Still, this might be seen as a better behaviour.

In an aggregated setup though, this is a real problem. If a single channel is left on a device, a room creation would be satisfied (resulting in an unusable room) by this device although there may be other devices which have enough resources for a real conference at the same time.

It may thus be a good habit to enforce a *23 option (which reserves 3 channels for the conference room) in the CONF interface mappings. As options are parsed left-to-right, if a user specifies an explicit *2<channel-reserve> option, it will overwrite the default set.

Device specific Settings

Resource Limitation


To implement the audio mixing capability, 2 types of resources are necessary in the CONF device :
  1. audio mixing engine
    This is usually a dedicated hardware circuitry on the device
  2. DSP channels to terminate the voice channels
DSP channels however are a shared resource on the device. Namely ISDN interfaces will need DSP channels too to terminate calls from/to the ISDN and if all those channels are consumed by the CONF interface already, call setups through the ISDN interfaces will fail. This is why it makes sense to limit the use of audio channels on a CONF interface to make sure there are enough channels left for other purposes.

As this obviously does not depend on the whole set of aggregated CONF interfaces but is specific to each individual device which is part of the aggregated set, it should be clear that this configuration is done on the CONF interface itself, not in the aggregating PBX object. The limit is set as part of the fish-help.png call setup commands to the CONF interface, namely the *1<channel-max> option of the create room commands (*1, *2 and *3). Btw: do not confuse commands and options, as they both start with the * introducer.

Also, it does not make sense to have the calling user specify this option as part of the called number. Instead, it must be inserted into the called number using appropriate fish-help.png interface maps. They need to insert a *14 option into all call setup commands which create a room (*1, *2 and *3) on the IP305 (as we allow 4 channels to be used) and likewise a *18 option on the IP800 (as we allow 8 channels).

Unique Room Numbers


Room numbers need to be unique. Within a single CONF interface, the device itself will ensure unique room numbers. However, if more than one interface is aggregated, unique prefixes must be enforced using appropriate interface maps. This is done using the *3<prefix> option to the create room command (*1). In our example, we use prefix 1 for the IP800 and prefix 2 for the IP305. Again, this is not to be specified by the calling user and thus we need to insert it like the resource limitation using an appropriate interface map (*32 for the IP305 and *31 for the IP800).

But what about the other two commands which may create a room (*2 and *3)? They are a little different as the room number (including the unique prefix) are given by the caller already. The CONF interface needs to verify if the room number presented actually has the right prefix already. If not so, it must reject the call so it can be re-routed to the next available CONF interface. This is enforced using the *4<match> option. So we need to insert a *41 option (IP800) or a *42 option (IP305) into calls which use either the *2 or *3 command.

Room Number Length


As said before, room numbers must be unique. However, in an application where the only access control to conference rooms is through the room number you will probably want it to be unlikely that users hit a valid room number just by accident (or even worse, malicious try and error). In other words, you want room numbers to be long. This is why the CONF interface creates unique room numbers with a length of 6 digits. If there is an extra prefix for aggregation (see above), there will be even more digits in the effective room numbers.

This can be quite annoying, so it can be controlled using the *5<id-length> option. To set it to 3, you would insert a *53 using an appropriate interface map. In our example, this would make for 4 digit room numbers (3 digit random number length + 1 digit unique prefix).

Resulting Interface Map Example


In our example setup, all this will result in an interface map like this (for the IP305):

*1 ? *1*32*14*53

Let's look at the call processing when a user requests a new conference with random room number. The number dialled would be 40 (the Number of the PBX gateway object which implements the aggregation) followed by the *1 command to create a new room, optionally followed by a *2 option to reserve a number of channels (say, 4) and a terminating #

40*1*24#

The gateway object would remove its own number (due to the Prefix property)

*1*24#

This would be sent to the first CONF device (let us assume it is the one in the IP305) and the interface map for *1 does match, so we end up with

*1*32*14*53*24#

which is what we want. Now let's look at a similar Create a new room with a given room number command (*2). Assuming the user would request creation of room 2123 with a reservation of 4 channels it would be called like 40*22123*24#. If we'd have a map for *2 on the interface identical to the one above for *1 (*2 ? *2*32*14*53), we'd end up with

*2*32*14*532123*24#

which unfortunately creates a syntax error in the *5 option argument. So we need to use the explicit *3<prefix> introducer. Also, the *3<prefix> option must be replaced with the *4<match> option, as follows:

*2 ? *2*42*14*53*3

This way, what the user dials (40*22123*24#) is translated to *2*42*14*53*32123*24#. Difficult? Well, after all, being an iCE is not a walk in the park wink.

In order to not further upset you, the interface map for the Create a new or join an existing room with a given room number *3 command is similar to the one for the *2 command:

*3 ? *3*42*14*53*3

One thing still is left: how to map the Join an existing room command? This command is invoked by just calling the room number. In our example setup, joining the room 2123 is done by calling 402123. The good news here is, there is nothing needed to do. The 40 is stripped away by the gateway object and the remaining room number is presented to the CONF interface right away.

So here is the boilerplate for the screenshot.png CONF interface maps:

*1 ? *1*3<prefix>*1<channel-max>*5<id-length>
*2 ? *2*4
<prefix>*1<channel-max>*5<id-length>*3
*3 ? *3*4
<prefix>*1<channel-max>*5<id-length>*3

Some thoughts on optimizing the Route to CONF Interfaces

Now that we have discussed all routes and interface mappings, let us come back to the routes to the CONF interfaces. They have been discussed before and the solution shown there works. However, when you start playing around with the solution, you will find that there is a minor drawback: When joining a conference for example, you will experience a slight delay until you get connected to the conference.

This delay can be avoided, when you add a trailing # to the number dialled. It is caused by the Force enblock option which we need in the routes (as explained earlier in this book). This instructs the routing logic to wait for additional digits to come.

While this makes sense for the complicated "commands" encoded to the dialled number (such as the creation commands and all the options), it can be avoided for the simple "join" command. This trick here is that we exactly know how the number looks like: it is the pure room number (as the preceding number of the used gateway object in the PBX has already been stripped). This room number consists of the unique device prefix (which is known à priori and of fix length) followed by the random part (which is not known à priori of course but of fixed length). So let us assume the prefix is 2 and the random part is 2 digits, then we can catch join commands with a route matching 2.. -> 2 ! Fair enough, but then, all join commands for all rooms will be tried on all devices, not only ours (see Aggregation above). For this reason, we also need to catch all other join commands (in our sample case, the only other prefix is 2). For those joins, we know a priori, that they will fail on our local CONF interface. To avoid the overlap timeout, we can just diconnect them with a fish-help.png rerouting cause.

Prepending screenshot.png such a route to the already existing route will catch this situation and handle it more conveniently. We still need the Interworking(QSIG,SIP) check-mark on it, but of course not the Force enblock.

If all that sounds strange to you, re-read the fish-help.png chapter on maps in the wiki, especially Number In/Out.

As you can see, this little optimization does make the whole configuration more complicated, so that you may as well decide to train your users to append a trailing # or wait a while for the join to happen wink!

Aggregation Call Flow

With the configuration discussed in the previous chapter in mind, let us have a look at the call flow in an aggregated scenario.

Conference Creation

As discussed before, the overall screenshot.png aggregation scheme is to pass any request to all available devices in a sequential order until one of them can satisfy the fish-help.png  request.

Here are screenshot.png the steps to create a new room in more detail:

  1. User calls conference facility
  2. Gateway object selects registration (CONF device), strips own number and calls to the selected device
  3. Interface maps are applied and CONF interface is called with added local settings
  4. Device rejects the call with a re-route cause
  5. Gateway object selects next available registration
  6. Interface maps are applied and CONF interface is called with added local settings
  7. Device satisfies the request and responds with the new room number conveyed in the connected number
  8. Gateway object prefixes own number and acknowledges the call to the user


Conference Join

The screenshot.png the steps to join an existing conference with one of the fish-help.png join requests are quite similar:

  1. User calls conference facility providing the room number to join
  2. Gateway object selects registration (CONF device), strips own number and calls to the selected device
  3. There are no interface maps for the join commands, so the call is sent to the device as it is
  4. The CONF device rejects the request (room is unknown here) with a re-routing cause
  5. Gateway object selects next available registration and sends call
  6. There are no interface maps for the join commands, so the call is sent to the device as it is
  7. Device satisfies the request and responds with the joined room number conveyed in the connected number
  8. Gateway object prefixes own number and acknowledges the call to the user


Long Room Numbers and Dialin

When random room numbers are used for ad-hoc conferences, room numbers tend to be long (by default, the CONF interface will generate 6-digit room numbers as a response to a *1 dial-in command and if aggregation takes place, there is the need for at least one unique prefix digit). While this might be not an issue if users dial into the conference from within the PBX, it will be a problem most likely if users dial in from the PSTN. The resulting number to dial-in to may simply be longer than the PSTN allows.

The simplest way of doing this is to dial in to the conference object and when connected dial the remaining digits for the commands and/or room number using overlapped sending. While the CONF interface supports this mode of operation, it might be confusing to users as they probably would expect a welcome message which asks them to key in the room number.

The solution is quite simple, use a PBX fish-help.png Waiting Queue object with appropriate DTMF maps.

The queue would have no operators and the Alert Timeout can be set to zero. If you like, you may want to provide a customized announcement ("Welcome to the xyz conferencing service! Please enter your room number now"). The DTMF maps should just map anything (.) to the Number of the gateway object used for CONF device aggregation.

screenshot.png Room Access IVR Waiting Queue Object



This model does not work for the creation of conference rooms as the created room number is not signalled back to the caller. However, in a real-life scenario, you wouldn't want to let external users call in to create conference rooms anyway.

Of course, even more sophisticated solutions can be created using customized XML scripts for the fish-help.png voice mail object.

Licensing

Audio Conferencing does not require any specific licensing. However, keep in mind that the CONF interfaces register with the Gateway PBX object used for aggregation and thus require a port license there.

Also, each call to a CONF interface via VoIP requires a DSP channel and will thus fail if no more channels are available. Surprisingly enough however, such use of DSP channels will not subtract a DSP license from the balance of available licenses in certain scenarios, currently. You may consider this a bug - but currently there is no plan to fix it. From a legal point of view though, a license is required whenever a DSP channel is used.

Conferencing and the BC-Conference Object

The fish-help.png BC-Conference Object does not support aggregation. This has 2 aspects:
  1. The object referred to in the External Conference Resource Name field must not have more than one registration and its PBX attribute must be the same as the BC-Conference object
  2. The returned connected number is not evaluated, so no dynamic creation of room numbers is supported

For these reasons, the CB-Conference object does not fit well in the scheme recommended in this book.

So how should you deal with this?

There is in fact no issue, if you only use the CONF interface local to the PBX where the BC-Conference object is anyway. You can then simply leave the External Conference Resource Name field empty and the local CONF interface is used.

If you intend to use a non-local CONF interface, then you must create an extra fish-help.png Gateway object that registers only the desired interface.

You should still make sure to use a proper Conference Id Prefix/Suffix so as to facilitate channel reservation and co-existance with the dynamic scheme explained in this book. For example, using *3*23*3 as Conference Id Prefix/Suffix and 28388 as Conference Id (along with not-checking the Create Dynamic Conference Id check-mark) would be appropriate to Create a new or join an existing room with a given room number (*3), reserve 3 channels (*23) and use room 8388 on device with prefix 2 (28388).

In any case, you should not use the BC-Conference object if you don't need the specific features provided by this type of PBX object.

Personal tools