Архитектурная модель распределенного Call центра

[andrsharov]

Здравствуйте, коллеги.

Сейчас админю call-центр с единственным Asterisk в главном филиале Страна 1. Появилась задача сделать систему более отказоустойчивой.

Большинство проектов - входящие.

Сейчас фактически у нас присутствует единая точка отказа Asterisk в Стране 1. Все проекты Страны 1, Страны 2, Страны 3 идут через него. Это архитектурно очень плохо.

Требуется разделить инфраструктуру:

1. По стране: Страна 1, Страна 2, Страна 3
2. По Asterisk , требуется не один Asterisk, который обрабатывает все вызовы. А например 1-2 Asterisk в Стране 1 : 10 клиентов висят на 1-ом Asterisk , 20 на втором. Тоже самое в Стране 2 и Стране 3
3. Требуется внедрить на территории каждой страны SIP Proxy сервер Kamalio для операторов, чтобы каждый оператор подключался к прокси своей страны.
4. Требуется обязательно сохранить возможность принимать вызовы все операторы на всех транках. Т.е. вызов пришел в очередь на один из Asterisk в Стране 1, встал в очередь , в Стране 1 никто не взял трубку, вызов пошел оператора Страны 2, либо Страны 3 на того, кто свободен.
5. Транки каждой страны от заказчиков/провайдров должны быть заведены на Asterisk-ки соответствутющей страны.
6. Требуется обязательно сохранить возможность перевода вызовов между Asterisk всех стран / между всеми операторами. / между всеми очередями.

Самая видимая проблема - это определение в разговоре ли оператор или нет между Asterisk/kamalio между Asterisk , либо странами.

И вообще хоть на схеме изображены Asterisk/Kamalio , это не обязательно что они будут в финальной версии архитектуры, можеть быть и FreeSWITCH/OpenSIPS.

На схеме я нарисовал очень много стрелочек между странами, хотя я сам точно не знаю где именно соединять будет правильнее с точки зрения возможности передачи статусов.

Пожалуйста покритикуйте, предложите свой вариант решения поставленной задачи.

[Glukinho]

А зачем в этой схеме SIP proxy, он же Kamailio? Сильное усложнение и архитектурно и с точки зрения поддержки, а зачем?

[andrsharov]

Тут просто столкнулись с проблемой обновления Asterisk ,

Страна 1 - 50 транков до заказчиков.
Операторы работают 5/2 ; 2/2 ; сутки трое;

Даже близко нет окна что бы его обновить. А ему уже 10 лет.

И например с заказчиком №1 - транк настроен по IP адресам, как и с заказчиком №3 , и таких штук 5-10 заказчиков, поменять одномоментно IP адреса на всех стыках - нерально организационно, т.к. обычно прописание стыка IP занимает 1-3 дня. Не остановить такое никак.

Главная задача SIP Proxy определять находится ли в разговоре тот или иной оператор , сообщать статус на ВСЕ Asterisk (всех стран) , и принимать вызов только от одного Asterisk в один момент времени. Если так умеет Asterisk, то не проблема. Но я что-то не нашел.

[Zavr2008]

обычно прописание стыка IP занимает 1-3 дня

3 дня транк создать? Ну это жесть.

20, 50 - это всё реально мелочи а не нагрузка.
Камаилио хотите - поставьте посередине их пару в кластер и нет проблем и раздавайте.
Тот же проект dSipRouter.

[andrsharov]

дня транк создать? Ну это жесть.

Обожаю таких комментаторов =) , которые "ты-г...о" . А по делу ничего.

Так вот , SIP операторы бывают РАЗНЫЕ.. Заказчики бывают РАЗНЫЕ.

Если идет речь о каком-нибудь супер-адекватном zadarma/novofon . и заказчик отдал логин/пароль . то прописание транка 10 минут. Ну плюс до часа совершить тестовые наборы, посмотреть что все биллится как нужно и т.п.

Если у заказчика БОЛЬШОЙ неповоротливый оператор, который может дать SIP только через стык IP-IP то обычно создается группа WA/Telegram в которой все договариваются. Зоны ответственности вносятся в разные доп соглашения и т.д. и .т.п. Потом ПРОЕКТ ЗАПУСКАЕТСЯ со стороны оператора связи. Документация сканируется ТП ОПЕРАТОРА СВЯЗИ и вносится в Wiki для техподдержки. Жуткая бюрократия , но реальность.

20, 50 - это всё реально мелочи а не нагрузка.

Тут как посмотреть , у нас нагрузка в пике 100 вызовов одновременных бывает, весь РТК порядка 10000 вызовов одновременных. Все относительно .

Камаилио хотите - поставьте посередине их пару в кластер и нет проблем и раздавайте.

Хочу убрать едиственную точку отказа в виде текущего Asterisk. Но Asterisk не умеет передавать состояние очереди(агентов) на другие Asterisk https://community.asterisk.org/t/asteri ... y/95657/14.
Поэтому ищу варианты , как разнести точки отказа, при этом что-бы все агенты стояли во всех очередях, и могли переводить друг другу вызовы.

Тот же проект dSipRouter.

Вот за наводку спасибо, по делу.