Notes Asterisker. Corporate - a holy thing ...
He slept well and was in a good mood. I decided to check the server, and at the same time also have a friend.
His uptime showed 86 days - fine, but Asterisk ... TOTAL 3 days and 20 hours !!!
- So what happened to you? Why did Asterisk restart?
- We just had a meeting. So I knocked him out so that the calls wouldn't go !!!
Blimey! Those. when they started a “meeting” - they just KILLED all the telephony!
Well, beasts, honestly! :)
We must make a normal decision.
')
Predict EXACTLY when the next corporate event takes place or this meeting is simply impossible. Well, we will make a normal decision - even for such a period all calls come, but not to office phones, but to the same voice mail.
To do this, I wrote a backup extensions.conf in which I pointed out incoming routes to VoiceMail and did not forget to insert a piece to unlock. Called it extensions.conf.mute .
Next in the original dialplan, did the following:
exten => 666,1, Answer
exten => 666, n, System (cp /etc/asterisk/extensions.conf /etc/asterisk/extensions.conf.back)
exten => 666, n, System (cp /etc/asterisk/extensions.conf.mute /etc/asterisk/extensions.conf)
exten => 666, n, System (asterisk -rx 'dialplan reload')
exten => 666, n, hangup
Those. on dialing 666 , the current dialplan is reserved, then it is replaced with a "holiday" and re-reading the state. A similar piece to unlock in the extensions.conf.mute file is just the opposite :)
That seems to be all. True, then they also asked to make a voice notification in which mode the station works, and then also the mode selection menu, etc. etc. And I thought that I got off easy :)
More from experience.
A couple of years ago, the same problem was posed for the operator's room. The fact is that the change of operators changed at 10 am and 6 pm For each change of operators, it was necessary to keep statistics on their work - how many calls were made or missed, the level of service, etc.
This indicator is in the statistics of the queue, but it is ACCUMULATIVE, but it was necessary to reset it to 0 before the start of the new shift. At the same time, the spent shift must first write down its indicators.
The idea is simple. However, a simple queue reload all does not give a reset if it has not seen changes in the parameters in the queue.conf file.
Then they did it by a simple method: a perl script was written, which parsley queue.conf and created a “double”. If I found a “tricky” string flag, I discarded it; if not, I added it. Those. received at the output of a constantly changing new configuration file of queues, which led to a reset of statistics.
True, we found a slight oddity: we have the parameters acceptdtmf = # set in agents.conf
which allows you to answer a call by pressing a key on the phone, and not automatically. So here. After such reboots, the situation turned out to be exactly the opposite - as if a TRIGGER was triggered - either respond to the key or automatically. We decided this simply - not once was given a queue reload all , but two at once.
Well, that's all.
His uptime showed 86 days - fine, but Asterisk ... TOTAL 3 days and 20 hours !!!
- So what happened to you? Why did Asterisk restart?
- We just had a meeting. So I knocked him out so that the calls wouldn't go !!!
Blimey! Those. when they started a “meeting” - they just KILLED all the telephony!
Well, beasts, honestly! :)
We must make a normal decision.
')
Predict EXACTLY when the next corporate event takes place or this meeting is simply impossible. Well, we will make a normal decision - even for such a period all calls come, but not to office phones, but to the same voice mail.
To do this, I wrote a backup extensions.conf in which I pointed out incoming routes to VoiceMail and did not forget to insert a piece to unlock. Called it extensions.conf.mute .
Next in the original dialplan, did the following:
exten => 666,1, Answer
exten => 666, n, System (cp /etc/asterisk/extensions.conf /etc/asterisk/extensions.conf.back)
exten => 666, n, System (cp /etc/asterisk/extensions.conf.mute /etc/asterisk/extensions.conf)
exten => 666, n, System (asterisk -rx 'dialplan reload')
exten => 666, n, hangup
Those. on dialing 666 , the current dialplan is reserved, then it is replaced with a "holiday" and re-reading the state. A similar piece to unlock in the extensions.conf.mute file is just the opposite :)
That seems to be all. True, then they also asked to make a voice notification in which mode the station works, and then also the mode selection menu, etc. etc. And I thought that I got off easy :)
More from experience.
A couple of years ago, the same problem was posed for the operator's room. The fact is that the change of operators changed at 10 am and 6 pm For each change of operators, it was necessary to keep statistics on their work - how many calls were made or missed, the level of service, etc.
This indicator is in the statistics of the queue, but it is ACCUMULATIVE, but it was necessary to reset it to 0 before the start of the new shift. At the same time, the spent shift must first write down its indicators.
The idea is simple. However, a simple queue reload all does not give a reset if it has not seen changes in the parameters in the queue.conf file.
Then they did it by a simple method: a perl script was written, which parsley queue.conf and created a “double”. If I found a “tricky” string flag, I discarded it; if not, I added it. Those. received at the output of a constantly changing new configuration file of queues, which led to a reset of statistics.
True, we found a slight oddity: we have the parameters acceptdtmf = # set in agents.conf
which allows you to answer a call by pressing a key on the phone, and not automatically. So here. After such reboots, the situation turned out to be exactly the opposite - as if a TRIGGER was triggered - either respond to the key or automatically. We decided this simply - not once was given a queue reload all , but two at once.
Well, that's all.
Source: https://habr.com/ru/post/139411/
All Articles