You’re incorrect in your statement. The “\n” at the end of the Local extension causes the agent to report to the queue as busy or ‘in use’ when it’s on a call. Yes, you will still get the error that the agent was ‘not in use’ – but it quickly will report them as busy. However, this causes other issues. For example, with the “\n” at the end, the caller can’t do an attended transfer. Blind transfers work just fine. Even so, with v1.6.x (and via a backport in 1.4.x) there is a state_interface that will allow you to bypass this. I’ve explained the state_interface here: http://hostseries.com/solvingtransferring-calls-from-queues-agents-stay-busy/ — However I have had some issues with getting it to function 100% of the time on v1.4.26.x

I’m glad that you have found a solution that works for you. However, you’re solution still has one major problem. You are still using AgentCallBackLogin, which has been removed in v1.6.x, so you are only causing yourself more headache down the road when you go to upgrade.

I hope that helps.

This approach to working around AgentCallbackLogin has one very serious issue: AgentCallbackLogin not only handles the agent login functionality but includes the needed code to detect the device state. Therefore when you remove it from the equation, you can add members to the queue and use alternatives [whether a VM workaround or a robust database solution] only to find that the extensions on the queue always show up \”not in use\” even when agents are talking on them. This has profound consequences since the queue sees all extensions as available and only when it rings the extension does it realize the queue is busy. From the agents point of view, this generally means that while they are talking to a customer, the \”second line\” on the phone is ringing all the time with new calls. From the system point of view, it is wasting huge amounts of time and resources ringing extensions that it should know are already in use.

I have found that the best workaround using a database lookup for agent authentication is to then perform the AddQueueMember and then follow that with a call to AgentCallBackLogin with a dummy agent but the correct extension. This then allows the extension to be accurately montored for its device state, stopping the \”second line ring\” and wasted motion by the queue itself.

This system is for allowing agents to login and logout of the queue and receive calls. To force the “Agent” Number as the source for the CDR on outbound calls – I’m not sure that’s easily possible. However, for outbound calls, you can always write your outbound dialplans to input that details for the outbound call to a database. I like the CDR, but there’s alot of data that I would like to have that isn’t there. Here’s a quick outbound dialplan:

[out-bound]
exten => main,1,VMAuthenticate(@agent|)
exten => main,2,Set(agent=${AUTH_MAILBOX})
exten => main,3,set(starttime=${EPOCH})

exten => main,4,Read(phonenumber|/home/Sounds/outbound/phonenumber|n|2|5)
exten => main,5,Dial(SIP/${phonenumber}@outbound-trunk,60)
exten => main,6,Congestion()
exten => main,103,Busy()

exten => h,1,set(endtime=${EPOCH})
exten => h,2,NoOp(Started – ${starttime} – Ended – ${endtime})
exten => h,3,MYSQL(Connect connid localhost asterisk_user yourpassword asterisk_db)
exten => h,4,MYSQL(Query resultid ${connid} INSERT\ INTO\ outbound\ VALUES\ (’\’\’, \’${phonenumber}\’, \’${starttime}\’, \’${endtime}\’, \’${agent}\’))
exten => h,5,MYSQL(Disconnect ${connid})

The above example is very rough. Consider the key elements:
1) Agent Authentication on all outbound calls. It’s requiring the same details that the agent enters when they login to the phones. This is added protection to prevent people from abusing the outbound service. At the sametime, you can capture the “Agent Number”.
2) Dialplan collects a start time of the call, and end time of the call. It also collects the phone number the Agent dialed.
3) All information is saved to a database. You can easily query that database for calls made by a certain agent, made during a certain time period, etc.

I hope that helps. Again, it’s very rough.

To get VMAuthenticate to play different audio prompts you can record the following file:
/var/lib/asterisk/sounds/vm-login.alaw (or .gsm)
And there are other vm-* sounds as well. You might want to record those to change behaviors. However, if you are overwriting these files, please keep in mind that if you upgrade Asterisk, it will overwrite these.

The above option will change the behavior or audio for the voicemail application. If you don’t want to do that, another option is simply not playing “Comedian Mail.” You can disable this within the VMAuthenticate application. The option is: ’s’ ….. so:

exten => main,1,VMAuthenticate(@agent|s)

You might want to play your custom prompt for agent ID before that:

exten => main,1,Playback(/home/Sounds/enter-agent-id)
exten => main,2,VMAuthenticate(@agent|s)

I hope all of this helps.

Sorry for the delay.
The important thing to remember when using MYSQL queries within your dialplan is that you have to make sure you have the same number of columns in the dialplan as the table has. You have to still mention all columns in your dialplan, even if it’s blank. Otherwise, it won’t insert the data.

By the way, you can using find the error from the Asterisk CLi.

I was looking at the login/out MySQL entry, for some strange reason it isn’t actually updating (or Inserting) the data into the table…

I’m reasonably sure I’ve created the table correctly, it just doesn’t seem to update the table…

Any ideas?

After an “Agent” has logged in, and they make an outbound call, is there a way (easy one preferably!) to have Asterisk use the “Agent” Number as the source for the CDR?

Also, is there a way of getting VMAuthenticate to play different audio prompts? (I’ve still got the “Comedian Mail” prompts!)

Think I’ll bookmark your blog for future reference!

Thanks & Regards

Great writeup otherwise!

-Erik