asterisk.ru

userall200 писал(а):хочется сделать один раз и не переделывать.
В связи с этим спрашиваю, как правильно построить архитектуру этой системы.

AJAX для таких проектов, в частности с телефонией - это тупик, пришедший к нам из средневековых глубин Web разработки. При эксплуатации возникнет куча проблем, начиная от нагрузки на сервер (представим 100-300 агентов делающих одновременный/1 раз в сек. GET/POST на сервак к perl/php скрипту на том конце) и заканчивая сомнительным обеспечением безопасности всей этой байды (особенно если она смотрит в инет). Я построил свою CRM на WebSocket'ах (wss://) - все получилось просто до-нельзя. Для броузеров, которые еще не держат этот стандарт (привет надкушенным и мелкомягким !) используется opensource flash-аналог. Как дополнителный бонус - софтфон органично встраивается в Web UI агента, а не смотрится эдаким "не пришей ..."

Интересует, как оператору дать удобную возможность определить, какой именно звонок поступил к нему из общего списка очереди для открытия карты звонка (операторов несколько и в очереди может быть несколько звонков). Думаю, реализовать AJAX скрипт, который будет по AMI раз в 1 сек связываться с Ast и получать id установленного канала для данного оператора и как только оператор поднял трубку через секунду у него откроется нужный клиент при совпадении Caller ID с клиентом или просто карта нужного звонка.

Еще как вариант - все сделать вокруг софтфона - путь он и посылает запросы к БД и прочее. Тут уже пробегали ребята на джаве - главная ошибка звучит так "у нас есть CRM/Java/крутые программисты/silver bullet in the head/etc - и мы ходим просто добавить VoIP/воды". Во-первых: все наоборот, во-вторых: чтобы узнать, что "во-первых" правда, нужно набросать обдуманную архитектуру своей системы, и в третьих: когда будете делать "во-вторых" помнить, что "тому, кто не попал в первую пуговичную петлю - уже не застегнуться", кажись (c) Гете

switch писал(а):

Sfinx писал(а):представим 100-300 агентов делающих одновременный/1 раз в сек. GET/POST на сервак к perl/php скрипту на том конце

При правильном подходе этот способ легко раскачивается на 300 агентов так как линейно масштабируется. И скорость этого способа не зависит от астериска.

Можете поподробнее описать вашу архитектуру.

switch писал(а):

Sfinx писал(а):представим 100-300 агентов делающих одновременный/1 раз в сек. GET/POST на сервак к perl/php скрипту на том конце

При правильном подходе этот способ легко раскачивается на 300 агентов так как линейно масштабируется. И скорость этого способа не зависит от астериска.

Эта сомнительная теория, не имеющая практического применения, потому как линейное масштабирование - это как минимум не реализуемо, а как максимум - тупая трата средств на содержание серверов. Но я тоже с удовольствием послушаю как switch отмасштабирует такое AJAX/GET/POST решение, к примеру, хотя бы тыщ на 7-10 юзеров

2 Sfinx: ты никакущий специалист, раз таких вещей не понимаешь. Добро пожаловать в мой платный суппорт!

А тут никому и не надо понимать что ты просто форумное трепло. Иди научись программировать лампочки для начала, потом может и сможешь осилить масштабирование

Если отделить switch-мух от масштабирования, собрать стендик и создать нагрузку для связки Apache/PHP/AMI-Asterisk/MySQL, то можно увидеть что при нагрузке уже в где-то в 300 запросов/секунду 4-ядерный сервак начинает отвечать через 3-5 секунд, при 400 - через 10, ну дальше уже промоделируете сами. Цифры могут незначительно отличаться в зависимости от уровня железа, настроек OS и соответствующего ПО.

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

switch, а чисто с точки зрения грамотного и неграмотного подхода, вы сами неужели считаете этот ежесекундный цикл нормальным? Представьте как бы выглядело программирование если бы не было событий: Ежесекундный опрос клавиатуры, ежесекундный опрос винчестера на проверку записал/не записал, ежесекундный опрос событий о клике мышки, жуть.
Просто у нас нет нормального выбора. И приходится выбирать что то одно из отстойных способов(мне известны следующие):
1) Всякие флеш java которые могут держать постоянное соединение и ждать событий от сервера
2) Вариант когда сервер на Ajax запрос будет держать соединение и не будет отвечать на запрос пока не поступит событие
3) И в цикле Ajax запросы на которые сервер сразу отвечает.
Веб сокеты ещё в черновом варианте и походу ещё не скоро можно будет смотреть в эту сторону.

гыы, судя по тому, что написано на сайте тормозит перл а пхп летает. не верю....

но то, что оно есть это гуд.

полностью согласен, однако надпись 'FOP тормозит из за того что используется медленный язык программирования перл а мы взяли и переписали все на php и оно полетело' имеет место быть.

"The main desire was to get rid of the FOP at all, because it is very heavy as a system (due to the fact that the backend is written in Perl)"

http://code.google.com/p/lynks-ajax-panel/


"При разработке интерфейса за основу был взят дизайн, внешне похожий на привычный Flash Operator Panel (FOP), однако схожесть только внешняя. Имеющие дело с FOP быстро поняли, что это красивая игрушка, фактически бесполезная для реальной работы. Более того, и сам FOP и его серверная часть, написанная на Perl работают очень медленно, сильно нагружая и клиента и сервер даже при малом количестве звонков.

Кардинально новый подход к работе с Asterisk позволил снизить на порядок потребляемые ресурсы со стороны сервера, в серверной части отсутствуют постоянно запущенные скрипты, все AJAX обращения обрабатываются быстрыми и оптимизированными php скриптами без взаимодействий с базами данных и обширным использованием встроенных функций, написанных на С.
"

http://lynks.ru/blog/vkhodyashchii-call-tsentr-ot-lynks