Переадресация- штука интересная и количество сценариев переадресации звонка очень много.
В случае описываемом мной переадресация выполняется безусловно и включатеся по желанию абонента (вообще данный пример очень просто перделывется в условную переадресацию и если дойдут руки я постараюсь раскрыть эту тему), но все осложняется тем, что сервер на котором регистрируется Asterisk с выходом в город не умеет обрабатывать SIP сообщение 302-Moved Temporarily (Используется SIP канал, но диалплан может быть применен и к другим технологиям). Недостаток метода который я опишу здесь в том, что потребуется 2 Trunk'а или 1, но многоканальный (<2 канала). Метод использует собственную базу данных Asterisk astDB, поэтому советую прочитать об этом, поскольку подробно останавливаться на этом моменте я не буду.

Надеюсь, что этой статьей получится превратить статьи по конфигурации Asterisk в целый цикл статей, начало которому я, для себя положил около 2-х лет назад в этой статье.

Я стараюсь описывать свою разработку (а возможно кому-то и приподниму завесу тайны) нетривиальных, или просто интересных, по моему мнению, диалпланов.

Я сразу оговорюсь, что не буду описывать настройку модулей, конфигурационных файлов подключения к базе данных и тому подобного, так как это не цель статьи, тем более все это есть в wiki и в книгах по Asterisk. Так же я сразу скажу что делаю все это на голом Asterisk без freePBX так как считаю реализацию этого веб-интерфейса неправильной, нелогичной и ущербной.

Начну я с одного из сценариев в организациях — разгрузки секретаря. Эту же логику будет возможно применить и к Call центрам, и диспетчерам такси (немного изменив Dialplan).

Сценарий:
-Звонок на секретаря.
-Сектретарь поднимает трубку -просят соединить с отделом продаж.
-Секретарь переводит звонок на группу менеджеров.
-Менеджер разговаривает с клиентом.
-При повторном звонке в течении 24 часов клиент попадает сразу к принявшему его впервые менеджеру.

Кому интересно прошу под кат.