Course11:Advanced - Audio Conferencing: Difference between revisions
m (Protected "Course11r1:Advanced - Audio Conferencing" [edit=sysop:move=sysop]) |
m (Protected "Course11:Advanced - Audio Conferencing" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))) |
(No difference)
|
Latest revision as of 11:57, 12 October 2023
This book is about the building blocks available in the innovaphone PBX to support audio conferencing functions.
Overview
- 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 - 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
Mixing
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 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 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
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
- conference creation
- conference destruction
- joining a conference
- leaving a conference
- inviting to a conference
- muting participants
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 implemented easily using a PBX 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 Call Broadcast Conference object (a.k.a. BC-Conference) 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
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 Voicemail object control a conference.
The remainder of this book will concentrate on the use and configuration of the CONF interface itself.
Participant Control
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 Interworking check-mark) on all the gateway routes used in the call path, including the routes to the CONF interface itself!
Aggregation
The aggregation scheme is quite simple: all devices which shall be aggregated need to register with a single PBX object. Based on the standard re-routing mechanism found in the 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, 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 PBX Gateway Object is recommended ]
Configuration
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
- it defines the number and/or name to access the conferencing facility
- it implements the aggregation logic
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 object configuration.
Routes to the CONF Interface
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 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 must be ticked.
Setting a default Value for the *2 option
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 :
- audio mixing engine
This is usually a dedicated hardware circuitry on the device - DSP channels to terminate the voice channels
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 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 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):
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 #
The gateway object would remove its own number (due to the Prefix property)
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:
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:
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 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
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 rerouting cause.
Prepending 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 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 !
Aggregation Call Flow
Conference Creation
Here are the steps to create a new room in more detail:
- User calls conference facility
- Gateway object selects registration (CONF device), strips own number and calls to the selected device
- Interface maps are applied and CONF interface is called with added local settings
- Device rejects the call with a re-route cause
- Gateway object selects next available registration
- Interface maps are applied and CONF interface is called with added local settings
- Device satisfies the request and responds with the new room number conveyed in the connected number
- Gateway object prefixes own number and acknowledges the call to the user
Conference Join
- User calls conference facility providing the room number to join
- Gateway object selects registration (CONF device), strips own number and calls to the selected device
- There are no interface maps for the join commands, so the call is sent to the device as it is
- The CONF device rejects the request (room is unknown here) with a re-routing cause
- Gateway object selects next available registration and sends call
- There are no interface maps for the join commands, so the call is sent to the device as it is
- Device satisfies the request and responds with the joined room number conveyed in the connected number
- Gateway object prefixes own number and acknowledges the call to the user
Long Room Numbers and Dialin
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 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.
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 voice mail object.
Licensing
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 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
- 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 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.