The purpose of this application is to allow you to add new members in your queue, whenever you want, without having the need to make changes in the queues.conf file.

For example, you can use this application when need to add a new agent in the queue just for a while. In other word, when you need a new agent, but just temporary and you do not want to make any changes in the queues.conf file and in the agents.conf file, you can use the AddQueueMember application.

Below, we will give you an example.

To use this application you need
a working Asterisk PBX with registered users in iax.conf,sip.conf or mgcp.conf(It depends on which protocol you would like to use) and made extensions. Also, you need to create an context in the queues.conf and another one in the agents.conf file.

To see how the application works we recommend to use our IAX softphone Idefisk. You can download it from here. Please also read our tutorial to learn how to configure it to work with Asterisk PBX.

NOTE: This is only an example of what for you can use this application. Of course you can use it and for other things.

We need two registered users in the iax.conf file and also another one in the sip.conf file. This is because we are going to use the IAX2 and the SIP channels. If you want to use other protocol such as MGCP, you have to do the configurations below respectively in mgcp.conf.

So, we have registered the users user1 and operator2 in the iax.conf file and the user operator in the sip.conf file.

Type=friend means that this user can make and receive calls. Host=dynamic means that the IP is not static but dynamic through a DHCP server. Allow=all means that the line which this user will use, could support all audio codecs. Context=test - this shows that this user is working with the extensions in this context of the configuration file extensions.conf.

In the sip.conf file you can see the following option: disallow=all. This means that the line will not support any codecs. However, below this option we have allow=ulaw, allow=alaw and allow=gsm. This means that the line will support these three codecs - ulaw, alaw and gsm. It is important to write the options exactly in this order. First you write the disallow=all option and then the allow options. Otherwise, if you write the disallow option after the allow options, no codecs will be supported by the line.

In this file you have to say which users or agents will participate in your queue. In other words, which users or agents will be responsible for the answer of an incoming call. More about the features of this configuration file, you can learn in our tutorial about the queues.conf file.

There are two possible ways to configure the settings in this file.

The first one, is the so called "static" way. For this configuration you do not need the agents.conf file.

You will say directly, which users to answer the incoming call. In our example, we have created a context with the name [test]. In this context we have written the following: member => SIP/operator. This means that this user(operator) will be responsible for the answering of the incoming calls in the queue test. In the same way you can add even more than one user, which you would like to answer in this queue. However in our case we will have only one user. The advantage of this method, is that you do not have to use the AgentLogin or the AgentCallbackLogin applications in order to log the user in the queue. It will be logged in automatically, when it turns on its phone. The disadvantage is that this user can use, only the phone, on which it is registered. That is why the method is called "static". You can see a screenshot below

The other way is the so called "dynamic" way. For this configuration you will need the agents.conf file.

In the section agents.conf Configurations we will show you the configurations in it and here we will explain you the configurations in queues.conf file. Unlike the static method, here we have to write not the name of the user, but the number of the agent, as written in the
agents.conf file. In our example we have written the following:
member => Agent/8888. This means that we want the agent with number
8888, to answer the incoming calls in the queue test. If you decide to use this method you have to add in your dial plan either the AgentLogin or the AgentCallbackLogin application. This is necessary, because unlike the "static" method, here is not enough just to turn on your phone. The user has to log in itself in the queue, manually. The advantage of this method is that the user could log in from any place and phone, which is connected with the Asterisk PBX.You can see a screenshot below.

As we have mentioned above, we have to use this configuration file, if we decide to use the "dynamic" method. In this file, we have to create one or more agents. We will use them to answer the incoming calls in our queue.

The way of creating an agent is the following: agent => agentnumber,agentpassword,agentname. In our case we have written the following: agent => 8888,8888,operator. This means that we have registered an agent with number 8888, password 8888 and username operator. The agent is set in the [agents] context. The agent number will be used in the queues.conf file. Please, take a look at section queues.conf Configurations above, to learn how to do this.

Now lets take a look at the extensions.conf file.

On the picture above you can see our extensions.conf file.

Firstly, we need a logged in agent. For the purpose, we will use the AgentCallbackLogin application. The agent has to call the number 2345, which will execute the AgentCallbackLogin application. It will allow us to log in the agent 8888 at the context [test](in extensions.conf). When the agent log in, the system will ask it for its password and to enter an extension. In our case the extension will be the one with the number 111, which one contains the Dial application. This will cause the connection to the user operator through the SIP channel. Now the agent is ready to accept the incoming calls in our queue.

Secondly, lets take a look at the AddQueueMember application. The extension which contains this application has number 110. As arguments in the brackets of the application we have the following: test|IAX2/operator2. test is the name of the context, in the queues.conf file, where we would like the new member to be added. IAX2/operator2 means that the user operator2 will be the new agent. It will be reachable through the IAX2 channel. As the AgentLogin, the AddQueueMember application will also log in the member as soon as it turns on its IP phone. So you do not need a separate application to log in the member.

Now, lets take a look at the Queue application. We have one extension, with number 112, which will execute the Queue application. When somebody dials the number, the call will be attached in the queue. The caller will hear music on hold. Meanwhile the phones af the users operator and operator2 will be ringing. When someone of the agents answers the call, the music on hold will stop and the conversation will start. The phone of the other agent will stop ringing. If in the same time somebody else dials 112, it won't hear a busy signal, but again the music on hold. The new caller could stay on the line until it decides to hang up, the set timeout expires or the again someone of the agents answer its call.