we have created a Group in Vicidial and added few remote agents to the group. Remote agents have mobile phone numbers. Here are some of the options from the group configurations:
Next Agent Call: longest_wait_time
Queue Priority: 0 - Even
On-Hook Ring Time: 15
Now the queue is working as expected. Agent numbers are dialed based on the wait time. But the problem is that for an incoming call, the system dialed only one number from the queue and hangs up if the call is not answered.
It does not dialed the next number from the queue if the previous number does not receive the call. It only dialed the next number if a new call comes in.
I was wondering how to have the next number from the queue dialed (or redirect the user to an IVR) if the previous number does not picks up?
Vicidial:
Version: 2.14b0.5
SVN Version: 3254
DB Schema Version: 1596
Found a way, in my case all the agents are remote agent on PSTN connections. So I have set the On-Hook = Y for all the remote agent accounts. And now if the previous agent is busy or does not receive the call then the next agent is dialed from the queue.
Need to check if setting the On-Hook property to Y has any other ramification.
Update: You have to set the onhook time considering 5/6 seconds will be spent on the PSTN end to search for the mobile device + couple of seconds to initiate the call + ring time on the mobile device. In my case setting 23 seconds working ok for a 15 seconds ring time on the mobile end.
Related
There is one dynamic send port (Req/response) in my orchestration.
Request is sending to external system and accepting response in orch. There is a chance the external system have monthly maintenance of 2 days. To handle that scenario
Retry interval if I set to 2 days is it impacting the performance? Is it a good idea?
I wouldn't think it is a good idea, as even a transitory error of another type would then mean that message would be delayed by two days.
As maintenance is usually scheduled, either stop the send port (but don't unenlist) or stop the receive port that picks up the messages to send (preferable, especially if it is high volume), and start them again after the maintenance period.
The other option would be to build that logic into the Orchestration, that if it catches an exception that it increased the retry interval on each retry. However as above, if it is high volume, you might be better off switching of the receive location, as otherwise you will have a high number of running instances.
Set a service interval at the send port if you know when the receiving system will be down. If the schedule is unknown I would rather set:
retry count = 290
retry interval = 10 minutes
to achieve that the messages will be transmitted over two days.
I am new to and working on asterisk.
How to Capture the Reverse Signal in Asterisk,
Currently I am receiving the disposition as NA-No Answer Auto Dial for all unreached calls where I should receive as follows
No Answer,
Busy,
Not Reachable,
Switched Off.
Currently using vicidial: 2.2.1
Vicidial use app_AMD
Synopsis
Attempts to detect answering machines.
Description
AMD([|initialSilence][|greeting][|afterGreetingSilence][|totalAnalysisTime][|minimumWordLength][|betweenWordsSilence][|maximumNumberOfWords][|silenceThreshold])
This application attempts to detect answering machines at the beginning of outbound calls.
Simply call this application after the call has been answered (outbound only, of course).
When loaded, AMD reads amd.conf and uses the parameters specified as default values.
Those default values get overwritten when calling AMD with parameters.
'initialSilence' is the maximum silence duration before the greeting. If exceeded then MACHINE.
'greeting' is the maximum length of a greeting. If exceeded then MACHINE.
'afterGreetingSilence' is the silence after detecting a greeting. If exceeded then HUMAN.
'totalAnalysisTime' is the maximum time allowed for the algorithm to decide on a HUMAN or MACHINE.
'minimumWordLength'is the minimum duration of Voice to considered as a word.
'betweenWordsSilence' is the minimum duration of silence after a word to considere the audio what follows as a new word.
'maximumNumberOfWords'is the maximum number of words in the greeting. If exceeded then MACHINE.
'silenceThreshold' is the silence threshold.
This application sets the following channel variable upon completion:
AMDSTATUS - This is the status of the answering machine detection.
Possible values are:
MACHINE | HUMAN | NOTSURE | HANGUP
AMDCAUSE - Indicates the cause that led to the conclusion.
Possible values are:
TOOLONG-<%d total_time>
INITIALSILENCE-<%d silenceDuration>-<%d initialSilence>
HUMAN-<%d silenceDuration>-<%d afterGreetingSilence>
MAXWORDS-<%d wordsCount>-<%d maximumNumberOfWords>
LONGGREETING-<%d voiceDuration>-<%d greeting>
http://www.voip-info.org/wiki/view/Asterisk+cmd+AMD
We have a shell script setup on one Unix box (A) that remotely calls a web service deployed on another box (B). On A we just have the scripts, configurations and the Jar file needed for the classpath.
After the batch job is kicked off, the control is passed over from A to B for the transactions to happen on B. Usually the processing is finished on B in less than an hour, but in some cases (when we receive larger data for processing) the process continues for more than an hour. In those cases the firewall tears down the connection between the 2 hosts after an inactivity of 1 hour. Thus, the control is never returned back from B to A and we are not notified that the batch job has ended.
To tackle this, our network team has suggested to implement keep-alives at the application level.
My question is - where should I implement those and how? Will that be in the web service code or some parameters passed from the shell script or something else? Tried to google around but could not find much.
You basically send an application level message and wait for a response to it. That is, your applications must support sending, receiving and replying to those heart-beat messages. See FIX Heartbeat message for example:
The Heartbeat monitors the status of the communication link and identifies when the last of a string of messages was not received.
When either end of a FIX connection has not sent any data for [HeartBtInt] seconds, it will transmit a Heartbeat message. When either end of the connection has not received any data for (HeartBtInt + "some reasonable transmission time") seconds, it will transmit a Test Request message. If there is still no Heartbeat message received after (HeartBtInt + "some reasonable transmission time") seconds then the connection should be considered lost and corrective action be initiated....
Additionally, the message you send should include a local timestamp and the reply to this message should contain that same timestamp. This allows you to measure the application-to-application round-trip time.
Also, some NAT's close your TCP connection after N minutes of inactivity (e.g. after 30 minutes). Sending heart-beat messages allows you to keep a connection up for as long as required.
Default Asterisk configuration (only sip.conf changes).
I use call files for calling and I need to hangup after first ring while every dial.
WaitTime: 4 seconds doesn't work sometimes, since it's counting from the beginning (connect to SIP provider etc) and the client doesn't even receive the call.
00359894000001.call
Channel: SIP/flowroute/00359894000001
Extension: 00359894000001
WaitTime: 4
There are no way predict connection time and count how much ring was at called side. Ring create by endpoing equipment, you have no control/info about it.
If the connection time for the SIP provider etc is constant you should just check what it is and add it to your 4 seconds.
I am using asterisk(1.6.2.13) to mass originate to specified numbers that are come from mysql database using perl and AMI.
if I send all calls (simultaneous) to asterisk, it will drop half of them after about 20 seconds. but if I sleep for 1 second between each originate it will process the call clearly. so this will reduce the capacity of origination.
Is there any way to get rid of this limitation?
Asterisk uses a single thread to process all SIP messages, and everything relating to SIP messaging happens in this thread (eg. realtime database access). This imposes an upper limit on the number of calls that can be processed per second. You can monitor the unprocessed SIP packets on the socket queue using something like "netstat -na |grep 5060". I've found it can up to 200 call setups per second, beyond that it will start losing and retransmitting packets and eventually dropping calls.