Pull to refresh

Comments 7

Были настроены сценарии обработки входящих вызовов, по следующей схеме:
  1. При поступлении входящего звонка, он отправлялся на основной сервер, время дозвона 20 сек.
  2. При недоступности основного сервера, звонок отправлялся на резервный, время дозвона 20 сек.
  3. При недоступности и резервного сервера, звонок отправлялся в голосовую почту.

В этот план стоит еще добавить перевод на мобильные телефоны сотрудников колл-центра, чтобы хоть как-то сервис обеспечивать в ситуации когда (именно когда, а не если) возникнут проблемы с работой через SIP-клиенты.
Этот момент сделан уже в самом диалплане, но до него как правило не доходит.
Да про резервирование каналов доступа и офисов я написал в статье, это весьма банально и тривиально решается.
Какое количество одновременных звонков способна выдержать вышеописанная система?
Например, висящих в очередях входящих звонков, раз уж про астериск разговор завели.
Здесь приводился пример организации резервирования телефонии, на примере основного и резервных серверов. Резервных может быть больше. Я максимально абстрагировался от технических аспектов, дабы показать самый простой принцип.

Вопрос нагрузочного тестирования на Хабре неоднократно поднимался и можете поискать, как это проводили и к чему пришли.

А применительно к этой статье я не могу вам ответить, так как в том проекте ни разу не достигался предел по звонкам.
Ну можно пиковую нагрузку указать.
80 одновременных каналов — максимум, что было замечено в прошлом году.
Sign up to leave a comment.

Articles