Поэтому, чтобы не тянуть кота за хвост, шаблон загружаемого модуля для Asterisk:
#include "asterisk.h"
ASTERISK_FILE_VERSION(__FILE__, "$Revision: $")
#include "asterisk/module.h"
#include "asterisk/logger.h"
static int load_module(void){
// Init code here
return AST_MODULE_LOAD_SUCCESS;
}
static int unload_module(void){
// Destroy code here
return 0;
}
AST_MODULE_INFO_STANDARD(ASTERISK_GPL_KEY, "Hello World");
Это минимально необходимый код, который нужно поместить в папку с сорцами Asterisk в подкаталог res. При компиляции, будет собран новый модуль с названием «как имя файла» и дискрипцией «Hello World».
Отлично, внутрь Asterisk мы попали, что дальше? Нам нужно получить информацию о регистрации телефона, бонусом мы хотим знать IP адрес телефона, возможно его джитер и статус (USE/NOT_USE/HOLD).
В Asterisk для этого существует Stasis . К сожалению, единственный способ разобраться в работе этого механизма — это изучить исходные коды. Итак, сделаем 3 простых шага:
1. Подписываемся на получения событий от шины стазиса
stasis_subscribe(ast_endpoint_topic_all(),acl_change_stasis_dev_status,NULL);
ast_endpoint_topic_all() — возвращает название «Топика» сообщения.
acl_change_stasis_dev_status — Это функция, которая будет вызвана, когда в стазисе появиться нужное для нас сообщение из указанного топика.
2. Создаем функцию, в которой будем ловить нужные сообщения.
static void acl_change_stasis_dev_status(void *data, struct stasis_subscription *sub, struct stasis_message *msg){
}3. Собственно самое вкусное — код обработки события.
Перед тем как начеркать свое, нужно понять, а в каком виде оно к нам придет? Для этого лезем в сорцы и находим вот такой кусок:
ast_endpoint_blob_publish(peer->endpoint, ast_endpoint_state_type(), blob);
и далее:
void ast_endpoint_blob_publish(struct ast_endpoint *endpoint, struct stasis_message_type *type, struct ast_json *blob)
{
RAII_VAR(struct stasis_message *, message, NULL, ao2_cleanup);
if (blob) {
message = ast_endpoint_blob_create(endpoint, type, blob);
}
if (message) {
stasis_publish(ast_endpoint_topic(endpoint), message);
}
}
struct stasis_message *ast_endpoint_blob_create(struct ast_endpoint *endpoint,
struct stasis_message_type *type, struct ast_json *blob)
{
RAII_VAR(struct ast_endpoint_blob *, obj, NULL, ao2_cleanup);
RAII_VAR(struct stasis_message *, msg, NULL, ao2_cleanup);
if (!type) {
return NULL;
}
if (!blob) {
blob = ast_json_null();
}
if (!(obj = ao2_alloc(sizeof(*obj), endpoint_blob_dtor))) {
return NULL;
}
if (endpoint) {
if (!(obj->snapshot = ast_endpoint_snapshot_create(endpoint))) {
return NULL;
}
}
obj->blob = ast_json_ref(blob);
if (!(msg = stasis_message_create(type, obj))) {
return NULL;
}
ao2_ref(msg, +1);
return msg;
}
Что дает нам это кусок кода? Понимание того, что в качестве полезной нагрузки в нашу функцию мы получим ast_endpoint_blob, внутри которого будет ast_endpoint_snapshot и JSON.
Теперь наш код:
if(ast_endpoint_state_type() != stasis_message_type(msg))return; // Проверим, мы получили нужное нам сообщение?
// Все остальное выдергиваеться из исходных кодов Asterisk при длительном и внимательном изучении
struct ast_endpoint_blob * n=stasis_message_data(msg); // Полезная нагрузка в данном топике ходит в виде структуры ast_endpoint_blob
// Сведения о регистрации конвентированы в JSON
struct ast_json * m;
struct ast_endpoint_snapshot *snap; // А вот информация о пире лежит рядом c JSON в структуре ast_endpoint_snapshot
snap=n->snapshot; // Получаем информацию о пире
m=n->blob; // Получаем JSON
char buffer[1050];
sprintf(buffer,"Device %s (%s): %s\n",snap->id,ast_endpoint_state_to_string(snap->state),ast_json_dump_string_format(m,AST_JSON_COMPACT));
ast_log(LOG_NOTICE,buffer); // И выводим в лог
Описанные выше структуры потянут за собой следующие инклуды:
#include "asterisk/stasis_endpoints.h"
#include "asterisk/stasis.h"
#include "asterisk/stasis_message_router.h"
#include "asterisk/stasis_channels.h"
#include "asterisk/stasis_bridges.h"
#include "asterisk/stasis_system.h"
#include "asterisk/devicestate.h"
#include "asterisk/json.h"
Про них тоже нужно не забыть, при создании модуля.
Итого:
#include "asterisk.h"
ASTERISK_FILE_VERSION(__FILE__, "$Revision: $")
#include "asterisk/module.h"
#include "asterisk/logger.h"
#include "asterisk/stasis_endpoints.h"
#include "asterisk/stasis.h"
#include "asterisk/stasis_message_router.h"
#include "asterisk/stasis_channels.h"
#include "asterisk/stasis_bridges.h"
#include "asterisk/stasis_system.h"
#include "asterisk/devicestate.h"
#include "asterisk/json.h"
static void acl_change_stasis_dev_status(void *data, struct stasis_subscription *sub, struct stasis_message *msg){
if(ast_endpoint_state_type() != stasis_message_type(msg))return;
struct ast_endpoint_blob * n=stasis_message_data(msg);
struct ast_json * m;
struct ast_endpoint_snapshot *snap;
snap=n->snapshot;
m=n->blob;
char buffer[1050];
sprintf(buffer,"Device %s (%s): %s\n",snap->id,ast_endpoint_state_to_string(snap->state),ast_json_dump_string_format(m,AST_JSON_COMPACT));
ast_log(LOG_NOTICE,buffer);
}
static int load_module(void){
stasis_subscribe(ast_endpoint_topic_all(),acl_change_stasis_dev_status,NULL);
return AST_MODULE_LOAD_SUCCESS;
}
static int unload_module(void){
// Тут нужно отписаться от события
return 0;
}Для чего это нужно? Полученную информацию можно класть в единую базу кластера, которая всегда будет знать на каком конкретно сервере зарегистрировано устройство. Смаршутизировать звонок, опираясь на эту информацию уже можно средствами диалплана.
И, собственно, как это выглядит:
Комментарии (62)
BoDRbI
14.10.2016 11:19Вы не рассматривали вариант, перенести регистрации, например на kamailio, и использовать kamailio как балансировщик?
xomiakba
14.10.2016 11:43Рассматривали. Решение не устроило с архитектурной точки зрения — у нас используется бесшовный диалплан, размазанный в геоплане на множество серверов, включая аппаратные комплексы, что требует максимальной гибкости, в довесок — архитектура уже изначально построена на базе Asterisk. Кроме того, возник еще один момент — с одной стороны, нам нужна единая база куда будет собраны все-все-все, с другой нам очень важно чтобы при падении этой базы или любого узла, вполне корректно работали узлы кластера, потому что простой кластера очень критичен. В связи с этим добавлены еще дополнительные механизмы синхронизации узлов кластера, разномастные кэши. Вишенкой на торте является то, что кластер ориентирован на конечного потребителя — очереди, нестандартные переадресации по условиям и тд.
arheops
14.10.2016 15:20А зря. Все эти механизмы не добавляют надежности. Вам всегото надо было потратить немножко времени на изучение kamailio, и все запросы о нахождении абонента отправлять ему. Как экесперт с опытом работы с астериском более 15 лет, могу сказать, что решение в виде модуля для * гарааааздо больший костыль, чем kamailio.
xomiakba
14.10.2016 15:27Kamalio найдет абонента на аппаратной платформе, или находящегося в данный момент на другой АТС?
Вы как человек с опытом в 15 лет, должны понимать, что такие решения не рождаются на пустом месте.
Вот вам задачка:
Абонент 14444 на кластере Asterisk
Абонент 14445 на Avaya
Абонент 14446 на H323 шлюзе в другом городе
Абонент 14447 мобилен (с сотового телефона через софтфон по Wifi в любом подразделении компании)
Абонент 14448 софтфон в Москве
Решите вопрос маршутизации через kamalio.
Абонентов 10 к+, так что вариант со статичной маршутизацией не вариант.ssh24
14.10.2016 15:35В статье вы решаете задачу определения факта, что софтфон сотрудника зарегистрирован на Астериске. Но тоже самое можно делать и на Камаилио. Да и на астериске тоже есть способы попроще.
Писать модуль и лезть в код — это технически может быть круто. Но в контексте общей задачи это выглядит как костыль. Минусов гораздо больше чем плюсов.
xomiakba
14.10.2016 15:50Вы не допускали мысль, что это часть большей задачи, чем «решаете задачу определения факта, что софтфон сотрудника зарегистрирован на Астериске»? И тем кому нужно определить факт регистрации воспользуются встроенной функцией DEVICE_STATE и не будут интересоваться этой статьей вообще?
Но есть компании, которые решают задачи масштабнее определения регистрации телефона.
И да, Вы кстати технично ушли от ответа о маршрутизации. Заканчивайте оффтоп, речь в статье о модулях астериск, не нужно — пожалуйста, не используете.
astashov
14.10.2016 16:05А вот тут я не соглашусь, это не костыль. Это возможно усложнит сборку и обновление, может потом модуль под новые версии придется переписывать. Т.е. нужно будет сопровождать модуль и следить за ним.
Но получить информацию из астера через модуль астера всегда можно будет быстрее, чем через любой другой метод. Мы такой вариант практиковали, прирост производительности был большой. Но в итоге, в связи с тем что его нужно поддерживать, и цена процессорного времени и времени получения данных стала не такой важной, то перешли на другие варианты. Да и железо сильно подешевело :)arheops
14.10.2016 22:14Костыль это. Во первых можно было вообще убрать само существование пробелемы, сделав регистрации на kamailio/opensips. Во вторых астериск умеет сам менять состояние в odbc/mysql. Без спец модулей.
xomiakba
14.10.2016 23:02Вы тестировали модули связки астериска с базами данных? При высоких нагрузках, при отвале базы вы получите абсолютно не рабочую систему. Можно повторить в домашних условиях лайт версию этого апокалипса:
— Настройте выгрузку модулем астериска CDR
— Подайте через астериск 500+ звонков
— Ложим базу (а что? Думаете так не бывает в продакшене?)
— Минута и астериск ложиться, достигнув лимит потоков (500 шт)
Кстати, 500 это программное ограничение «по-умолчанию». Это ограничение выбирается примерно 20к каналах, это полка для собранного «по-умолчанию» астериска.
Если сделать как вы предлагаете, то в наших конкретных условиях нашего предприятия астерик ляжет через 70 сек после сбоя базы данных. Проверенно на стенде на версии 13.2
Что касается регистрации на камалио, вам уже было сказано — что это не решает вопрос с маршутизацией. Мы уже прошли этот путь от фанатичного «Вау, камалио!» до «Блиин, камалио..»arheops
14.10.2016 23:10Если у вас продакшен в 25000 в день, допускается больше минуты сбоя продакшен базы, то, действительно, какие могут быть вопросы. Минута сбоя соединения к базе в нагруженном проекте обычно приводит к большим разборкам и часто к увольнению админа базы.
Я тестировал, a2billing.org так работает в кластерах, нет проблем.arheops
14.10.2016 23:16Лимит потоков в * если и есть, то он явно выше 1000. Есть лимит на открытые файловые хендлы, но об этом знает любой вменяемый админ. А чтоб не ложилося, сдр надо сделать в batch mode
Короче понятно, просто нет эксперта. Бывает.xomiakba
14.10.2016 23:45Про CDR был пример. Батч моде там тоже не с проста появился. Проблема в том, что у реалтайм нет батч, как у CDR и вести себя они будут так как и CDR с отключенным батч моде. Вы опять схватили край сообщения, не вникнув в суть. Такая поспешность может сыграть злую шутку когда нибудь.
Лимит потоков не есть лимит файлов и не есть лимит каналов. Это 3 разные вещи.
arheops
14.10.2016 23:54Ну я выполню скоро уже тысячный проект на *, делал много чего, включая анализы сигналов, TTF, и системы с нагрузкой выше описанной вами в сотни раз. Писать свой модуль приходилося всего два раза, и было это для анализа сигналов. В данном случае это костыль. Решение «проблемы удаленного офиса» из вашего описания надо решать на уровне данных, не свича.
На лимит потоков(причем еще и на 500) не натыкался никогда, хотя все системы, требующие больше 400 по спецификации делаю исключительно через балансеры, поскольку аптайм астериска сильно зависит от cps.
xomiakba
14.10.2016 23:18Вас же не просят проектировать наш продакшен, а вы так радеете за него. Простой базы — это дизайнерское решение сервиса. И оно никаким образом не касается этой статьи. Это первое.
Второе, троль вы мой не наглядный, попробуйте обеспечить 100% аптайм не головной организации, а в филиале, за 1000 км от него. А телефония там тоже должна работать. Даже тогда, когда база и основной канал недоступен. А-В-Т-О-Н-О-М-Н-О. Но при этом отвечать единому диалплану и мобильности пользователей.
Отсюда и требование о недоступности базы в нашем продакшене.
Но повторюсь, наш продакшен вас не касается, просьба обсуждать не его, а статью.arheops
14.10.2016 23:22Я не вижу проблему составить диалплан для автономного офиса и отложеное общение с базой, и даже отложенные cdr.
Как пример посмотрите на реализацию этого в a2billing.org. Код доступен.
У вас какието очень надуманные проблемы. Как и решения.xomiakba
14.10.2016 23:50Я вас просил ранее привести пример маршрутизации и даже указал вводные данные. Вы это сообщение проигнорировали, но каждое сообщение повторяете что труда это не составит. Докажите уже всем наконец, что проблемы с организацией бесшовного диалпалана не существует и мы боремся с ветряными мельницами. Пусть мне будет стыдно, что трачу время людей на хабре.
Автономных офисов не 1 и не 10 и даже не 100, их больше у нас. Значительно больше. Составление руками или статика — сразу нет.arheops
14.10.2016 23:57На камалио это выполняется простым опросом всех доступных супер-нод из таблицы dispatcher. Каждая супер-нода запрашивает свои ноды. Тоесть запрос просто проходит по всем машинам. Учитывая типичный показатель запросов в 10000-50000 в СЕКУНДУ проблемы это не вызывает.
На астериске существует специальный протокол dundi для решения этой проблемы.xomiakba
15.10.2016 14:25Я указывал в комментарии, что есть не только сип. Кроме того, ноды могут быть территориально разнесены и не доступны по ряду причин — упал канал в подразделении, например.
Каков таймаут поиска? А если 20 нод недоступно? Поиск может быть оочень длительным. Вы в упор не хотите признавать, что есть варианты организации сервиса, отличные от вашего понимания. Вообщем вопрос про маршутизацию открыт.
arheops
14.10.2016 22:01Avaya может быть сип. может быть нет. На h323 надо поставить гейт, да. Все остальное через сип — соответсвенно без проблем ищется с kamailio в режиме 300+cps и 10000+ звонков на каждый сервер(чего не FS, не asterisk не могут).
Вопрос маршрутизации вообще не вопрос. Там с бубном решаются всякие сообщения и с большим бубном команда wait. А маршрутизация не составляет проблемы.xomiakba
14.10.2016 23:11Камалило не пркосирует ртп. Если два телефона в разных сетях беp маршрутизации между ними, звука не будет. Все точка.
При наличии не одного кластера телефонии, а нескольких, а также наличии панасов и протокола H323 маршрутизация ваша в таких условиях работать не будет. А конвентировать все в сип — замучаетесь, количество ендпоинтов огромное.
arheops
14.10.2016 23:18Не проксирует. Проксирует mediaproxy/rtpproxy или iptables.
Не расказываейте ерунду. Почти все инсталяции kamailio имеют клиентов за натом. Это давно отработано.xomiakba
14.10.2016 23:54Нужны сервисы, поэтому за камалио можно поставить только свитч сервер 5 лвл.
Встает тогда вопрос, зачем тут камалио, если мы имеем региональную структуру в которых сервера в Active режимах? Чтобы получить единую точку отказа?
Вообщем я еще раз повторюсь — дизайн продакшена это не тот вопрос, который стоит тут обсуждать. Вы не знаете наших требований, спорить можно бесконечно.
Так что разрешите откланяться.
citius
14.10.2016 13:10Чем был обусловлен выбор именно Asterisk для крупномасштабной телефонии?
С какими архитектурными проблемами самого астера вы сталкивались?xomiakba
14.10.2016 13:35>> Чем был обусловлен выбор именно Asterisk для крупномасштабной телефонии?
Бесплатно, гибко, есть специалисты, гибкий API для управления из вне, особенности диалаплана. Ну и конечно же сравнительное тестирование на стендах.
>> С какими архитектурными проблемами самого астера вы сталкивались?
Честно говоря, на вскидку не вспомнил не одной серьезной проблемы. С точки зрения архитектурного дизайна самого продукта претензий нет, есть некоторые претензии к конкретным модулям. Но на то он и framework, чтобы пилить из него то что нужно.
astashov
14.10.2016 14:32А почему не Freeswitch? Только потому что меньше специалистов и не такое большое комьюнити? Просто по остальным параметрам Freeswitch проворнее и стабильнее. Я после семи лет работы на Asterisk, два года назад перешел на FS, и честно говоря нисколько не пожалел. Как по мне, так FS работает намного стабильнее и менее требователен к ресурсам.
Я просто интересуюсь, и никого не агитирую за FS.xomiakba
14.10.2016 15:19При выборе в корпоративную среду фри продукта, не последнюю роль играет компания, которая поддерживает продукт. По крайней мере наличие такой компании. Кроме того, у фри свитча есть моменты, которые играют против него:
— Сложный конфиг
— Малое комьюнити
— Возможность аутсорса ограничена. Лично я не знаю ни одной компании, которая занимается фри свитчем в коммерческом аутсорсе.
— Порог вхождения нового администратора выше, чем у Asterisk.astashov
14.10.2016 15:30Сложный конфиг — тут не согласен. Он другой, но никак не сложный. Если человек понимает что должно быть, то сделать ничего сложного. Все таки в вики у них команды описаны и все просто и логично.
Малое комьюнити — это да, соску в рот в среде FS никто не вставляет и слюни не подтирает. Тут согласен. Работают с ним не кто попало, а только те кто реально разбираются
Порог вхождения конечно выше. И логи сложнее. Тут я с Вами не спорю. Но если человек знает как работает телефония в принципе(тот же астер), то в FS он войдет за месяц. Хотя я соглашусь, что этот месяц ему нужно будет платить зарплату.
Но если в итоге говорить про компанию, то коммерческая поддержка от основателей тоже хорошо :) И работают они оперативно.
В общем я с Вами согласен и не спорю :)arheops
14.10.2016 15:36Маленькое комьюнити — это прежде все мало тестеров(пользователей). Что такого дает FS, чего не дает астериск и что оправдывает меньшую тестируемость и xml конфиги?..
Порог входа в FS равный порогу входа в kamailio. И, поверьте, как знающий обе системы — крайне рекомендую сразу kamailio для «тех, кто не кто попало».
xomiakba
14.10.2016 15:43+1>> соску в рот в среде FS никто не вставляет и слюни не подтирает
>> Работают с ним не кто попало, а только те кто реально разбираются
При выборе решения в корпоративной среде в героев не играют. А те кто играют, быстро становятся фрилансерами ;) Решение должно работать, быстро и просто, либо с минимальным напильником, если речь о фри. Уже этого указанного Вами пункта достаточно, чтобы перечеркнуть FS как вариант.astashov
14.10.2016 15:57А никто в героев и не играет. ФС это обычный продукт, что от него шарахаются :) И опять же, смотря какая корпоративная среда :) Просто люди иногда такие напильники покупают в корпоративную среду, что камаилио как прокси + ФС как медиа сервер кажется просто детской игрушкой. И представляете, такая корпоративная среда цветет и радуется выбору. Так что люди, которые свободно работают как с астером так и с ФС и понимают что можно добиться большего если использовать например так же камаилио или опенсер, врилансерами наврятли будут :)
Опять же, смотря какие задачи и сколько эта «корпоративная среда» готова тратить на телефонизацию себя…
arheops
14.10.2016 15:22А можно уточнить, по каким таким параметрам(реальным) FS «проворнее» астериска со стеком pj_sip? Просто вот народ это все повторяет, повторяет. Ну это как реклама продукта(так на сайте написано). А если проверить — параметры +- одинаковы, только в FS баги дольше исправляются(комьюнити не такое «проворное»)
У FS конфиги значительно сложнее в редактировании и значительно менее устойчивы к сбоям конфиго-генерящих скриптов.
Найти свободного эксперта по FS практически нереально(даже по астериску свободного именно эксперта найти — та еще задача).arheops
14.10.2016 15:27Стабильнее работает? Я за свою практику видел всего две компании, у которых астериск реально нестабильно работал.
Причем в обоих случаев это было из-за выбраного предпочтения ОС(debian) и изза одного и того же косяка майнтейнера пакетов.
Запускайте астериск на рекомендованой ос(Centors/redhat), кроссплатформенность это хорошо, но работает все не так радужно(тестируют меньше на всем, что не elastix/trixbox).astashov
14.10.2016 15:49Большое количество астерисков у меня было не из пакетов. А из исходников. Так что у меня было по разному… И могу сказать, что нет никакой особой разницы откуда поставлен астер, из пакета или из сорсов. Конечно если Вы не используете специфические платы расширения, под которые нужны специфицеские драйверы или еще лучше изменение параметров в сырцах перед сборкой(китайские платы аналогичные диджиумовским). Но все таки у всех по разному, и под разные задачи. Так что может у Вас было так, а у меня вот так.
astashov
14.10.2016 15:46Со стеком pj_sip лично я не проверял. Мне в этом теперь нет нужды никакой. Я ушел с астера в тот момент, когда этот стек был сырой, и его использование в проде было тоже самое что стрелять себе в ногу. А без него и ари даже пробовать не хотелось. А наелся я тогда с астериском порядочно(у меня 320 серверов было на астериске на разном железе и разных ОС). Поэтому если Вы говорите что все замечательно, то пусть так и будет. Я же останусь на том, что сейчас работает намного лучше чем то что было тогда :)
Да не сложнее у него конфиги(Они просто другие. Это как говорить что на vi я работать не буду, так как по сравнению с nano из него долго выходить и там странные горячие клавиши) :) Кто Вам сказал такую глупость? :) Куча вариантов и все просто и легко :) А про ошибки конфиго генерящих скриптов я как бы не сильно думал говорить, потому что в нем все ошибки из за того что они написаны людьми, которые плохо понимают что и как должно работать. Если Вы знаете как написать конфиг ФС, то и со скриптом никаких проблем не будет. А если подходить к таким вещам с «поделкой на коленке», то тут что угодно может работать как угодно.
Про свободного эксперта по ФС, тут согласен.xomiakba
14.10.2016 15:59>> Мне в этом теперь нет нужды никакой. Я ушел с астера в тот момент, когда этот стек был сырой, и его использование в проде было тоже самое что стрелять себе в ногу
Я так понимаю это было до версии 1,8 еще? У нас в продакшене версия 1.8 есть (будет заменяться вскоре на 13,8 LTS) — проблем не замечено со стеком. Аптайм год без сбоя, на нем около 5800+ телефонов, так что полагаю Вам досталась сырая 1.4?astashov
14.10.2016 16:15нет. 1.4 уже давно в архиве был, и на новом проде я бы ее никогда не стал бы использовать. Я тогда смотрел и 1.8, и 11 версию и 13(или 12-я, я точно не помню какая тогда была в стабильных).
В общем на конец 2014 года, pj_sip вроде был уже стабильный, но доступный функционал и количество репортов на него было устращающе большое, и я не рискнул начинать под него разработку. И к тому времени у меня был небольшой опыт в работе с ФС(в свободное время читал и «выполнял домашние задания»). И на тот период он мне нравился все больше и больше, и на новый проект было принято решение разрабатывать в качестве основного медиа сервера и сервера регистрации ФС, с возможностью в будущем перенести регистрацию на камаилио и оставить фс только как медиа.
И да, я сразу не сказал что у меня текущий проект с webrtc, и ФС уже тогда работал с ним прекрасно из коробки, а вот с астериском было не все так гладко. Как мне сказали компании аутсорсеры по астериску, на одном из городских IT сабонтуйничках, что вроде в последней версии у астера еще были проблемы с webrtc. Но тут, как говорится «мопед не мой». За что купил, за то и продаю :) Сам тему не изучал.xomiakba
14.10.2016 16:29>> В общем на конец 2014 года, pj_sip вроде был уже стабильный,
Он до сих пор не пригоден к использованию. Мы сразу от него отказались.
>> возможностью в будущем перенести регистрацию на камаилио и оставить фс только как медиа.
Этот проект рассматривали?
selenite
14.10.2016 23:56если бы «комьюнити» что астериска, что freeswitch не жило за счет тайных незадокументированных знаний, которые надо гуглить или вычислять опытным путем, оба проекта были бы куда стабильнее, как программные продукты. Но нет, экспертам же невыгодно (:
varnav
14.10.2016 18:51А что значит «проворнее»? На каком количестве звонков Asterisk начнёт тормозить на сервере с 24 ядрами и 128 ГБ памяти?
astashov
14.10.2016 20:57Понятия не имею. Я оперирую тем железом которое есть, а не которое хочется что бы было. И клиенты, которые используют наше ПО тоже такие сервера не покупают. Поэтому свои 20000 — 25000 звонков в сутки ФС и * обрабатывают с совершенно разной нагрузкой на сервер. Я понимаю что и астер можно затюнить, но только вокруг ФС я тоже не сильно прыгал.
arheops
14.10.2016 22:2525000 звонков в сутки(17 в минуту, при стандартном ACD 100 каналов) обрабатывает без существенной нагрузки один сервер. Вобщемто все, что меньше 10 в секунду не должно вызывать нагрузки. Есть системы, в которых до миллиона звонков в день на *, и они достаточно просты.
Тут вопрос в подходе авторов. FS по умолчанию затюнен на перфоманс(reinvite, rtp в обход и так далее), в то время как asterisk затюнен на максимальное compatibility.xomiakba
15.10.2016 00:24Поддерживаю. Почему то когда сравнивают ФС и * забывают что они проектировались как софтсвитчи разного уровня изначально.
arheops
14.10.2016 22:18На 600-1500 примерно(цифра зависит от того, какую латентность вы считаете приемлимой). Если один астериск. Зависит от диалплана и длительности звонков, конечно, но это у него такое фундаментальное ограничение вызваное блокировками. На железе с 24 ядрами запускается 4-8 разных астерисков и балансер(kamailio). Но интересно то, что у FS с блокировками та же фигня. При сравнимом диалплане(реальном, не том который в доках по FS) и равной оптимизации разница в пределах 20-30% и не всегда(не во всех диалпланах) в сторону FS.
xomiakba
15.10.2016 00:111500? Ну-ну :)
У нас на продакшене 1 сервак отрабатывает почти 600 звонков в каждый момент времени при нагрузке 7-8% на процессор. А он такой же почти как в условии выше, только памяти меньше.
Общее количество звонков через него 80к в сутки.
Я вам гарантирую, что число там порядка 10к, не меньшеarheops
15.10.2016 00:25Ну попробуйте 10к, потом сообщите результат. У меня есть система обрабатывающая уже лет 5 от 400к до 1500к звонков каждый день(система обработки терминации). С большим аптаймом не работает астериск при большом количестве звонков. Вечно что-то блокируется. Проще запустить 4 на сервак.
По той же причине нет особого смысла ставить астериск на cpu с количеством ядер больше 4.
И не пугайте меня фразами типа ххК звонков в сутки. Они ничего не значат без параметров ACD,ASR и описания диалплана, да и даже мой упрощенный вариант обзвонщика(не говоря про полноценные) расчитан на cps>5(тоесть такие же обьемы в час)xomiakba
15.10.2016 11:39>> С большим аптаймом не работает астериск при большом количестве звонков. Вечно что-то блокируется. Проще запустить 4 на сервак.
Тут явно противоречие, 1.5 млн звонков в день и один сервак с 4 астерисками. У вас явно тут ошибка в архитектуре. Почему не кластер Актив-Актив? Блокируется потому что есть программное ограничение, уже талдычим не первый коммент.
>> По той же причине нет особого смысла ставить астериск на cpu с количеством ядер больше 4.
Обоснуй.
xomiakba
15.10.2016 14:22Кстати, просто интересно, в какой компании 1.5 ляма звонков в сутки?
Я вот вроде в крупной компании работаю, но 1.5 ляма это явно очень много для нас.
Ростелеком? Бибилайн? Мтс?
xomiakba
15.10.2016 00:06Все просто, астериск ляжет при 20к+ каналах. От железа это мало зависит, если вы не используете транскодинг.
Максимум что мне удалось добиться — это 24к канала в режиме тишины. При этом загрузка процессора была средней. Астериск 13.2
После этого вы получите в лучшем случае дрожащий голос, в худшем отлуп при попытке регистрации или инвайта. Как я писал выше в коментах, там програмные ограничения есть.
Мы гоняли на 16 ядрах астериск. В полку он так и не уперся, ни по памяти ни по ядрам…arheops
15.10.2016 00:34Сколько гоняли? День, месяц, год? Что, говорите, у астериска нет проблем при стандартном ACD(оно 5 минут если что), при 20к каналов(тоесть cps 66-100) устойчиво на промежутке хотя бы в неделю?
Понимаете, пробелема в том, что для софсвичей показатель «может держать ххххх каналов с тишиной» совершенно бесполезен.
По сути у астериска 1.8+ ограничение в районе 20-30cps. После чего начинаются всякие приколы.xomiakba
15.10.2016 11:24Знаете, мне начинает казаться что у вас цель просто спорить :)
>> у астериска нет проблем при стандартном ACD(оно 5 минут если что), при 20к каналов(тоесть cps 66-100) устойчиво на промежутке хотя бы в неделю?
Нет такого понятия как стандартный ACD, давайте начнем с этого. Есть значения, которые принято брать при тестировании. Во вторых, cps в 100 звонков очень мало для астериска, этот показатель в районе 800. Тестировали, знаем…
Устойчивость в сутки вас устроит? Показатель такой: 800 cps примерно при 7-8к одновременных звонков, с хождением ртп, время жизни канала 10 сек. Тестирование проводилось с помощью sipp.
>> Понимаете, пробелема в том, что для софсвичей показатель «может держать ххххх каналов с тишиной» совершенно бесполезен.
Понимаете, тишину гоняли при 24к каналов, при 20к это было эхо.
>> По сути у астериска 1.8+ ограничение в районе 20-30cps. После чего начинаются всякие приколы.
Вы только что подтвердили мой результат. 30cps это 9к звонков при ваших стандартных 5 минутах. :)
То есть в каналах это 18 тысяч. Вы же помните, что при звонке два канала создаются?)
Так о чем спор, уважаемый? Лимит в 20 к каналов есть ограничение програмное и не зависит от железа. На этом точка.g613
15.10.2016 14:52чего за железо / операционка если не секрет?
800 cps это сильно… PDD какой при этом?
cat /proc/cpuinfo
…
processor: 39
vendor_id: GenuineIntel
cpu family: 6
model: 62
model name: Intel® Xeon® CPU E5-2470 v2 @ 2.40GHz
stepping: 4
microcode: 1064
cpu MHz: 2400.129
cache size: 25600 KB
physical id: 1
siblings: 20
core id: 12
cpu cores: 10
apicid: 57
initial apicid: 57
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms
bogomips: 4799.30
clflush size: 64
cache_alignment: 64
address sizes: 46 bits physical, 48 bits virtual
на таком живет 7к звонков ( по 2 лега ) с ртп в продакшине, больше начинаются проблеммы с перформансом сетевого стека. мы тупо не успеваем пакеты выбирать.
ось затюнина по гайдам. карточки 10 гигабитные. 711 кодек.
и да у нас тоже 1.5 млн в день бывает но на 10 нод…
xomiakba
17.10.2016 13:46Упс, ошибся веткой. Это ответ для g613
> чего за железо / операционка если не секрет?
CentOS 7 / 16 * E7@2400 / 32G Ram
>> 800 cps это сильно… PDD какой при этом?
Это предел. PDD при этом до 5-6 сек. При 600 вполне нормальный PDD — 1-2c. Есть определенная связь между количества ядер и CPS, которые нормально переносятся астериском.
Опять же, при такого рода тестах очень часто утыкаемся не в скорость создания каналов, а в обработку уже существующих каналов — достигается лимит по каналам, в результате чего деградирует CPS. Поэтому производительность астериска уместно рассматривать в совокупности 2 параметров — количества звонков «онлайн» и CPS.
Обычно после этого:
начинаются проблемы с прохождением звонков. Разгрузить астериск можно отключив то что использует таскпроцессор — CDR, WEB, и тд. Более подробный список находиться в исходниках. На данный момент, это горлышко бутылки для астериска.
Интересно послушать, были ли у кого-то аналогичные исследования на эту тему и к каким выводам пришли. Логично предположить, что раз астериск не утыкается в полку, но звонки начинает отбивать, то это внутренняя проблема, которую, возможно, можно исправить.g613
17.10.2016 14:355-6 секунд это не серьезно. у нас камалио машину мертвой метит если не получил 100 на инвайт за секунду.
и повторюсь, что уперлись мы в то, что астериск не успевает выгребать ртп пакеты из сетевого стека.
pjsip или chan_sip кстати?xomiakba
17.10.2016 16:32>> 5-6 секунд это не серьезно
Горизонтальное масштабирование, canreinvite=yes. Все же зависит от задачи.
>> астериск не успевает выгребать ртп пакеты из сетевого стека.
Вот поэтому нужно больше процессоров :) Больше прерываний. Ну а серьезно — мониторили, в чем затык? strace что нибудь сказал? В каком моменте «горлышко бутылки»? Кстати, еще раз — canreinvite=yes — может существенно улучшить положение.
chan_sipg613
17.10.2016 17:12canreinvite=yes не будет медию проксировать.
без медии нам не интересно.
затык в том что астериск гоняет пакеты через user спейс.xomiakba
17.10.2016 17:22>> затык в том что астериск гоняет пакеты через user спейс.
кхм… а есть другой способ проксировать?
g613
17.10.2016 17:29если не надо транскодировать и делать репакатизацию то можно просто в кернел спейсе переложить. но в софте который сильно заточен для офисной атс этого наверное не стоит ожидать.
xomiakba
18.10.2016 12:47Нужен модуль, который будет используя xTables Api или ip Route Table выставлять маршрутизацию в ядре, чтобы пакеты не доходили до астериска, а сразу ремаршутизировались на удаленного клиента.
Данные для маршрутизации модуль может брать прям из текущей сессии, там же указан и адрес источника и адрес назначения и необходимость транскодинга.
Ursadon
Всё хорошо в самописных модулях, только один минус — при ошибке в нём (а мы, люди, склонны делать ошибки), падает весь астериск.
xomiakba
Все ПО в мире написано людьми, склонными к совершению ошибок.
Для тех кто трусит, есть альтернативный вариант — использовать агент, который будет связан с Asterisk через AMI. В этом случае, падение агента никак не повлияет на работу телефонии. Через AMI можно перехватывать сообщение peerstatus, оно несет в себе туже информацию, что добывает модуль. Мы тестировали оба варианта, с целью кластеризации. Оба варианта жизнеспособны.