Комментарии 62
Всё хорошо в самописных модулях, только один минус — при ошибке в нём (а мы, люди, склонны делать ошибки), падает весь астериск.
Все ПО в мире написано людьми, склонными к совершению ошибок.
Для тех кто трусит, есть альтернативный вариант — использовать агент, который будет связан с Asterisk через AMI. В этом случае, падение агента никак не повлияет на работу телефонии. Через AMI можно перехватывать сообщение peerstatus, оно несет в себе туже информацию, что добывает модуль. Мы тестировали оба варианта, с целью кластеризации. Оба варианта жизнеспособны.
Для тех кто трусит, есть альтернативный вариант — использовать агент, который будет связан с Asterisk через AMI. В этом случае, падение агента никак не повлияет на работу телефонии. Через AMI можно перехватывать сообщение peerstatus, оно несет в себе туже информацию, что добывает модуль. Мы тестировали оба варианта, с целью кластеризации. Оба варианта жизнеспособны.
Вы не рассматривали вариант, перенести регистрации, например на kamailio, и использовать kamailio как балансировщик?
Рассматривали. Решение не устроило с архитектурной точки зрения — у нас используется бесшовный диалплан, размазанный в геоплане на множество серверов, включая аппаратные комплексы, что требует максимальной гибкости, в довесок — архитектура уже изначально построена на базе Asterisk. Кроме того, возник еще один момент — с одной стороны, нам нужна единая база куда будет собраны все-все-все, с другой нам очень важно чтобы при падении этой базы или любого узла, вполне корректно работали узлы кластера, потому что простой кластера очень критичен. В связи с этим добавлены еще дополнительные механизмы синхронизации узлов кластера, разномастные кэши. Вишенкой на торте является то, что кластер ориентирован на конечного потребителя — очереди, нестандартные переадресации по условиям и тд.
А зря. Все эти механизмы не добавляют надежности. Вам всегото надо было потратить немножко времени на изучение kamailio, и все запросы о нахождении абонента отправлять ему. Как экесперт с опытом работы с астериском более 15 лет, могу сказать, что решение в виде модуля для * гарааааздо больший костыль, чем kamailio.
Kamalio найдет абонента на аппаратной платформе, или находящегося в данный момент на другой АТС?
Вы как человек с опытом в 15 лет, должны понимать, что такие решения не рождаются на пустом месте.
Вот вам задачка:
Абонент 14444 на кластере Asterisk
Абонент 14445 на Avaya
Абонент 14446 на H323 шлюзе в другом городе
Абонент 14447 мобилен (с сотового телефона через софтфон по Wifi в любом подразделении компании)
Абонент 14448 софтфон в Москве
Решите вопрос маршутизации через kamalio.
Абонентов 10 к+, так что вариант со статичной маршутизацией не вариант.
Вы как человек с опытом в 15 лет, должны понимать, что такие решения не рождаются на пустом месте.
Вот вам задачка:
Абонент 14444 на кластере Asterisk
Абонент 14445 на Avaya
Абонент 14446 на H323 шлюзе в другом городе
Абонент 14447 мобилен (с сотового телефона через софтфон по Wifi в любом подразделении компании)
Абонент 14448 софтфон в Москве
Решите вопрос маршутизации через kamalio.
Абонентов 10 к+, так что вариант со статичной маршутизацией не вариант.
НЛО прилетело и опубликовало эту надпись здесь
Вы не допускали мысль, что это часть большей задачи, чем «решаете задачу определения факта, что софтфон сотрудника зарегистрирован на Астериске»? И тем кому нужно определить факт регистрации воспользуются встроенной функцией DEVICE_STATE и не будут интересоваться этой статьей вообще?
Но есть компании, которые решают задачи масштабнее определения регистрации телефона.
И да, Вы кстати технично ушли от ответа о маршрутизации. Заканчивайте оффтоп, речь в статье о модулях астериск, не нужно — пожалуйста, не используете.
Но есть компании, которые решают задачи масштабнее определения регистрации телефона.
И да, Вы кстати технично ушли от ответа о маршрутизации. Заканчивайте оффтоп, речь в статье о модулях астериск, не нужно — пожалуйста, не используете.
А вот тут я не соглашусь, это не костыль. Это возможно усложнит сборку и обновление, может потом модуль под новые версии придется переписывать. Т.е. нужно будет сопровождать модуль и следить за ним.
Но получить информацию из астера через модуль астера всегда можно будет быстрее, чем через любой другой метод. Мы такой вариант практиковали, прирост производительности был большой. Но в итоге, в связи с тем что его нужно поддерживать, и цена процессорного времени и времени получения данных стала не такой важной, то перешли на другие варианты. Да и железо сильно подешевело :)
Но получить информацию из астера через модуль астера всегда можно будет быстрее, чем через любой другой метод. Мы такой вариант практиковали, прирост производительности был большой. Но в итоге, в связи с тем что его нужно поддерживать, и цена процессорного времени и времени получения данных стала не такой важной, то перешли на другие варианты. Да и железо сильно подешевело :)
Костыль это. Во первых можно было вообще убрать само существование пробелемы, сделав регистрации на kamailio/opensips. Во вторых астериск умеет сам менять состояние в odbc/mysql. Без спец модулей.
Вы тестировали модули связки астериска с базами данных? При высоких нагрузках, при отвале базы вы получите абсолютно не рабочую систему. Можно повторить в домашних условиях лайт версию этого апокалипса:
— Настройте выгрузку модулем астериска CDR
— Подайте через астериск 500+ звонков
— Ложим базу (а что? Думаете так не бывает в продакшене?)
— Минута и астериск ложиться, достигнув лимит потоков (500 шт)
Кстати, 500 это программное ограничение «по-умолчанию». Это ограничение выбирается примерно 20к каналах, это полка для собранного «по-умолчанию» астериска.
Если сделать как вы предлагаете, то в наших конкретных условиях нашего предприятия астерик ляжет через 70 сек после сбоя базы данных. Проверенно на стенде на версии 13.2
Что касается регистрации на камалио, вам уже было сказано — что это не решает вопрос с маршутизацией. Мы уже прошли этот путь от фанатичного «Вау, камалио!» до «Блиин, камалио..»
— Настройте выгрузку модулем астериска CDR
— Подайте через астериск 500+ звонков
— Ложим базу (а что? Думаете так не бывает в продакшене?)
— Минута и астериск ложиться, достигнув лимит потоков (500 шт)
Кстати, 500 это программное ограничение «по-умолчанию». Это ограничение выбирается примерно 20к каналах, это полка для собранного «по-умолчанию» астериска.
Если сделать как вы предлагаете, то в наших конкретных условиях нашего предприятия астерик ляжет через 70 сек после сбоя базы данных. Проверенно на стенде на версии 13.2
Что касается регистрации на камалио, вам уже было сказано — что это не решает вопрос с маршутизацией. Мы уже прошли этот путь от фанатичного «Вау, камалио!» до «Блиин, камалио..»
Если у вас продакшен в 25000 в день, допускается больше минуты сбоя продакшен базы, то, действительно, какие могут быть вопросы. Минута сбоя соединения к базе в нагруженном проекте обычно приводит к большим разборкам и часто к увольнению админа базы.
Я тестировал, a2billing.org так работает в кластерах, нет проблем.
Я тестировал, a2billing.org так работает в кластерах, нет проблем.
Лимит потоков в * если и есть, то он явно выше 1000. Есть лимит на открытые файловые хендлы, но об этом знает любой вменяемый админ. А чтоб не ложилося, сдр надо сделать в batch mode
Короче понятно, просто нет эксперта. Бывает.
Короче понятно, просто нет эксперта. Бывает.
Про CDR был пример. Батч моде там тоже не с проста появился. Проблема в том, что у реалтайм нет батч, как у CDR и вести себя они будут так как и CDR с отключенным батч моде. Вы опять схватили край сообщения, не вникнув в суть. Такая поспешность может сыграть злую шутку когда нибудь.
Лимит потоков не есть лимит файлов и не есть лимит каналов. Это 3 разные вещи.
Лимит потоков не есть лимит файлов и не есть лимит каналов. Это 3 разные вещи.
Ну я выполню скоро уже тысячный проект на *, делал много чего, включая анализы сигналов, TTF, и системы с нагрузкой выше описанной вами в сотни раз. Писать свой модуль приходилося всего два раза, и было это для анализа сигналов. В данном случае это костыль. Решение «проблемы удаленного офиса» из вашего описания надо решать на уровне данных, не свича.
На лимит потоков(причем еще и на 500) не натыкался никогда, хотя все системы, требующие больше 400 по спецификации делаю исключительно через балансеры, поскольку аптайм астериска сильно зависит от cps.
На лимит потоков(причем еще и на 500) не натыкался никогда, хотя все системы, требующие больше 400 по спецификации делаю исключительно через балансеры, поскольку аптайм астериска сильно зависит от cps.
Вас же не просят проектировать наш продакшен, а вы так радеете за него. Простой базы — это дизайнерское решение сервиса. И оно никаким образом не касается этой статьи. Это первое.
Второе, троль вы мой не наглядный, попробуйте обеспечить 100% аптайм не головной организации, а в филиале, за 1000 км от него. А телефония там тоже должна работать. Даже тогда, когда база и основной канал недоступен. А-В-Т-О-Н-О-М-Н-О. Но при этом отвечать единому диалплану и мобильности пользователей.
Отсюда и требование о недоступности базы в нашем продакшене.
Но повторюсь, наш продакшен вас не касается, просьба обсуждать не его, а статью.
Второе, троль вы мой не наглядный, попробуйте обеспечить 100% аптайм не головной организации, а в филиале, за 1000 км от него. А телефония там тоже должна работать. Даже тогда, когда база и основной канал недоступен. А-В-Т-О-Н-О-М-Н-О. Но при этом отвечать единому диалплану и мобильности пользователей.
Отсюда и требование о недоступности базы в нашем продакшене.
Но повторюсь, наш продакшен вас не касается, просьба обсуждать не его, а статью.
Я не вижу проблему составить диалплан для автономного офиса и отложеное общение с базой, и даже отложенные cdr.
Как пример посмотрите на реализацию этого в a2billing.org. Код доступен.
У вас какието очень надуманные проблемы. Как и решения.
Как пример посмотрите на реализацию этого в a2billing.org. Код доступен.
У вас какието очень надуманные проблемы. Как и решения.
Я вас просил ранее привести пример маршрутизации и даже указал вводные данные. Вы это сообщение проигнорировали, но каждое сообщение повторяете что труда это не составит. Докажите уже всем наконец, что проблемы с организацией бесшовного диалпалана не существует и мы боремся с ветряными мельницами. Пусть мне будет стыдно, что трачу время людей на хабре.
Автономных офисов не 1 и не 10 и даже не 100, их больше у нас. Значительно больше. Составление руками или статика — сразу нет.
Автономных офисов не 1 и не 10 и даже не 100, их больше у нас. Значительно больше. Составление руками или статика — сразу нет.
На камалио это выполняется простым опросом всех доступных супер-нод из таблицы dispatcher. Каждая супер-нода запрашивает свои ноды. Тоесть запрос просто проходит по всем машинам. Учитывая типичный показатель запросов в 10000-50000 в СЕКУНДУ проблемы это не вызывает.
На астериске существует специальный протокол dundi для решения этой проблемы.
На астериске существует специальный протокол dundi для решения этой проблемы.
Я указывал в комментарии, что есть не только сип. Кроме того, ноды могут быть территориально разнесены и не доступны по ряду причин — упал канал в подразделении, например.
Каков таймаут поиска? А если 20 нод недоступно? Поиск может быть оочень длительным. Вы в упор не хотите признавать, что есть варианты организации сервиса, отличные от вашего понимания. Вообщем вопрос про маршутизацию открыт.
Каков таймаут поиска? А если 20 нод недоступно? Поиск может быть оочень длительным. Вы в упор не хотите признавать, что есть варианты организации сервиса, отличные от вашего понимания. Вообщем вопрос про маршутизацию открыт.
Avaya может быть сип. может быть нет. На h323 надо поставить гейт, да. Все остальное через сип — соответсвенно без проблем ищется с kamailio в режиме 300+cps и 10000+ звонков на каждый сервер(чего не FS, не asterisk не могут).
Вопрос маршрутизации вообще не вопрос. Там с бубном решаются всякие сообщения и с большим бубном команда wait. А маршрутизация не составляет проблемы.
Вопрос маршрутизации вообще не вопрос. Там с бубном решаются всякие сообщения и с большим бубном команда wait. А маршрутизация не составляет проблемы.
Камалило не пркосирует ртп. Если два телефона в разных сетях беp маршрутизации между ними, звука не будет. Все точка.
При наличии не одного кластера телефонии, а нескольких, а также наличии панасов и протокола H323 маршрутизация ваша в таких условиях работать не будет. А конвентировать все в сип — замучаетесь, количество ендпоинтов огромное.
При наличии не одного кластера телефонии, а нескольких, а также наличии панасов и протокола H323 маршрутизация ваша в таких условиях работать не будет. А конвентировать все в сип — замучаетесь, количество ендпоинтов огромное.
Не проксирует. Проксирует mediaproxy/rtpproxy или iptables.
Не расказываейте ерунду. Почти все инсталяции kamailio имеют клиентов за натом. Это давно отработано.
Не расказываейте ерунду. Почти все инсталяции kamailio имеют клиентов за натом. Это давно отработано.
Нужны сервисы, поэтому за камалио можно поставить только свитч сервер 5 лвл.
Встает тогда вопрос, зачем тут камалио, если мы имеем региональную структуру в которых сервера в Active режимах? Чтобы получить единую точку отказа?
Вообщем я еще раз повторюсь — дизайн продакшена это не тот вопрос, который стоит тут обсуждать. Вы не знаете наших требований, спорить можно бесконечно.
Так что разрешите откланяться.
Встает тогда вопрос, зачем тут камалио, если мы имеем региональную структуру в которых сервера в Active режимах? Чтобы получить единую точку отказа?
Вообщем я еще раз повторюсь — дизайн продакшена это не тот вопрос, который стоит тут обсуждать. Вы не знаете наших требований, спорить можно бесконечно.
Так что разрешите откланяться.
Чем был обусловлен выбор именно Asterisk для крупномасштабной телефонии?
С какими архитектурными проблемами самого астера вы сталкивались?
С какими архитектурными проблемами самого астера вы сталкивались?
>> Чем был обусловлен выбор именно Asterisk для крупномасштабной телефонии?
Бесплатно, гибко, есть специалисты, гибкий API для управления из вне, особенности диалаплана. Ну и конечно же сравнительное тестирование на стендах.
>> С какими архитектурными проблемами самого астера вы сталкивались?
Честно говоря, на вскидку не вспомнил не одной серьезной проблемы. С точки зрения архитектурного дизайна самого продукта претензий нет, есть некоторые претензии к конкретным модулям. Но на то он и framework, чтобы пилить из него то что нужно.
Бесплатно, гибко, есть специалисты, гибкий API для управления из вне, особенности диалаплана. Ну и конечно же сравнительное тестирование на стендах.
>> С какими архитектурными проблемами самого астера вы сталкивались?
Честно говоря, на вскидку не вспомнил не одной серьезной проблемы. С точки зрения архитектурного дизайна самого продукта претензий нет, есть некоторые претензии к конкретным модулям. Но на то он и framework, чтобы пилить из него то что нужно.
А почему не Freeswitch? Только потому что меньше специалистов и не такое большое комьюнити? Просто по остальным параметрам Freeswitch проворнее и стабильнее. Я после семи лет работы на Asterisk, два года назад перешел на FS, и честно говоря нисколько не пожалел. Как по мне, так FS работает намного стабильнее и менее требователен к ресурсам.
Я просто интересуюсь, и никого не агитирую за FS.
Я просто интересуюсь, и никого не агитирую за FS.
При выборе в корпоративную среду фри продукта, не последнюю роль играет компания, которая поддерживает продукт. По крайней мере наличие такой компании. Кроме того, у фри свитча есть моменты, которые играют против него:
— Сложный конфиг
— Малое комьюнити
— Возможность аутсорса ограничена. Лично я не знаю ни одной компании, которая занимается фри свитчем в коммерческом аутсорсе.
— Порог вхождения нового администратора выше, чем у Asterisk.
— Сложный конфиг
— Малое комьюнити
— Возможность аутсорса ограничена. Лично я не знаю ни одной компании, которая занимается фри свитчем в коммерческом аутсорсе.
— Порог вхождения нового администратора выше, чем у Asterisk.
Сложный конфиг — тут не согласен. Он другой, но никак не сложный. Если человек понимает что должно быть, то сделать ничего сложного. Все таки в вики у них команды описаны и все просто и логично.
Малое комьюнити — это да, соску в рот в среде FS никто не вставляет и слюни не подтирает. Тут согласен. Работают с ним не кто попало, а только те кто реально разбираются
Порог вхождения конечно выше. И логи сложнее. Тут я с Вами не спорю. Но если человек знает как работает телефония в принципе(тот же астер), то в FS он войдет за месяц. Хотя я соглашусь, что этот месяц ему нужно будет платить зарплату.
Но если в итоге говорить про компанию, то коммерческая поддержка от основателей тоже хорошо :) И работают они оперативно.
В общем я с Вами согласен и не спорю :)
Малое комьюнити — это да, соску в рот в среде FS никто не вставляет и слюни не подтирает. Тут согласен. Работают с ним не кто попало, а только те кто реально разбираются
Порог вхождения конечно выше. И логи сложнее. Тут я с Вами не спорю. Но если человек знает как работает телефония в принципе(тот же астер), то в FS он войдет за месяц. Хотя я соглашусь, что этот месяц ему нужно будет платить зарплату.
Но если в итоге говорить про компанию, то коммерческая поддержка от основателей тоже хорошо :) И работают они оперативно.
В общем я с Вами согласен и не спорю :)
Маленькое комьюнити — это прежде все мало тестеров(пользователей). Что такого дает FS, чего не дает астериск и что оправдывает меньшую тестируемость и xml конфиги?..
Порог входа в FS равный порогу входа в kamailio. И, поверьте, как знающий обе системы — крайне рекомендую сразу kamailio для «тех, кто не кто попало».
Порог входа в FS равный порогу входа в kamailio. И, поверьте, как знающий обе системы — крайне рекомендую сразу kamailio для «тех, кто не кто попало».
>> соску в рот в среде FS никто не вставляет и слюни не подтирает
>> Работают с ним не кто попало, а только те кто реально разбираются
При выборе решения в корпоративной среде в героев не играют. А те кто играют, быстро становятся фрилансерами ;) Решение должно работать, быстро и просто, либо с минимальным напильником, если речь о фри. Уже этого указанного Вами пункта достаточно, чтобы перечеркнуть FS как вариант.
>> Работают с ним не кто попало, а только те кто реально разбираются
При выборе решения в корпоративной среде в героев не играют. А те кто играют, быстро становятся фрилансерами ;) Решение должно работать, быстро и просто, либо с минимальным напильником, если речь о фри. Уже этого указанного Вами пункта достаточно, чтобы перечеркнуть FS как вариант.
А никто в героев и не играет. ФС это обычный продукт, что от него шарахаются :) И опять же, смотря какая корпоративная среда :) Просто люди иногда такие напильники покупают в корпоративную среду, что камаилио как прокси + ФС как медиа сервер кажется просто детской игрушкой. И представляете, такая корпоративная среда цветет и радуется выбору. Так что люди, которые свободно работают как с астером так и с ФС и понимают что можно добиться большего если использовать например так же камаилио или опенсер, врилансерами наврятли будут :)
Опять же, смотря какие задачи и сколько эта «корпоративная среда» готова тратить на телефонизацию себя…
Опять же, смотря какие задачи и сколько эта «корпоративная среда» готова тратить на телефонизацию себя…
А можно уточнить, по каким таким параметрам(реальным) FS «проворнее» астериска со стеком pj_sip? Просто вот народ это все повторяет, повторяет. Ну это как реклама продукта(так на сайте написано). А если проверить — параметры +- одинаковы, только в FS баги дольше исправляются(комьюнити не такое «проворное»)
У FS конфиги значительно сложнее в редактировании и значительно менее устойчивы к сбоям конфиго-генерящих скриптов.
Найти свободного эксперта по FS практически нереально(даже по астериску свободного именно эксперта найти — та еще задача).
У FS конфиги значительно сложнее в редактировании и значительно менее устойчивы к сбоям конфиго-генерящих скриптов.
Найти свободного эксперта по FS практически нереально(даже по астериску свободного именно эксперта найти — та еще задача).
Стабильнее работает? Я за свою практику видел всего две компании, у которых астериск реально нестабильно работал.
Причем в обоих случаев это было из-за выбраного предпочтения ОС(debian) и изза одного и того же косяка майнтейнера пакетов.
Запускайте астериск на рекомендованой ос(Centors/redhat), кроссплатформенность это хорошо, но работает все не так радужно(тестируют меньше на всем, что не elastix/trixbox).
Причем в обоих случаев это было из-за выбраного предпочтения ОС(debian) и изза одного и того же косяка майнтейнера пакетов.
Запускайте астериск на рекомендованой ос(Centors/redhat), кроссплатформенность это хорошо, но работает все не так радужно(тестируют меньше на всем, что не elastix/trixbox).
Большое количество астерисков у меня было не из пакетов. А из исходников. Так что у меня было по разному… И могу сказать, что нет никакой особой разницы откуда поставлен астер, из пакета или из сорсов. Конечно если Вы не используете специфические платы расширения, под которые нужны специфицеские драйверы или еще лучше изменение параметров в сырцах перед сборкой(китайские платы аналогичные диджиумовским). Но все таки у всех по разному, и под разные задачи. Так что может у Вас было так, а у меня вот так.
Со стеком pj_sip лично я не проверял. Мне в этом теперь нет нужды никакой. Я ушел с астера в тот момент, когда этот стек был сырой, и его использование в проде было тоже самое что стрелять себе в ногу. А без него и ари даже пробовать не хотелось. А наелся я тогда с астериском порядочно(у меня 320 серверов было на астериске на разном железе и разных ОС). Поэтому если Вы говорите что все замечательно, то пусть так и будет. Я же останусь на том, что сейчас работает намного лучше чем то что было тогда :)
Да не сложнее у него конфиги(Они просто другие. Это как говорить что на vi я работать не буду, так как по сравнению с nano из него долго выходить и там странные горячие клавиши) :) Кто Вам сказал такую глупость? :) Куча вариантов и все просто и легко :) А про ошибки конфиго генерящих скриптов я как бы не сильно думал говорить, потому что в нем все ошибки из за того что они написаны людьми, которые плохо понимают что и как должно работать. Если Вы знаете как написать конфиг ФС, то и со скриптом никаких проблем не будет. А если подходить к таким вещам с «поделкой на коленке», то тут что угодно может работать как угодно.
Про свободного эксперта по ФС, тут согласен.
Да не сложнее у него конфиги(Они просто другие. Это как говорить что на vi я работать не буду, так как по сравнению с nano из него долго выходить и там странные горячие клавиши) :) Кто Вам сказал такую глупость? :) Куча вариантов и все просто и легко :) А про ошибки конфиго генерящих скриптов я как бы не сильно думал говорить, потому что в нем все ошибки из за того что они написаны людьми, которые плохо понимают что и как должно работать. Если Вы знаете как написать конфиг ФС, то и со скриптом никаких проблем не будет. А если подходить к таким вещам с «поделкой на коленке», то тут что угодно может работать как угодно.
Про свободного эксперта по ФС, тут согласен.
>> Мне в этом теперь нет нужды никакой. Я ушел с астера в тот момент, когда этот стек был сырой, и его использование в проде было тоже самое что стрелять себе в ногу
Я так понимаю это было до версии 1,8 еще? У нас в продакшене версия 1.8 есть (будет заменяться вскоре на 13,8 LTS) — проблем не замечено со стеком. Аптайм год без сбоя, на нем около 5800+ телефонов, так что полагаю Вам досталась сырая 1.4?
Я так понимаю это было до версии 1,8 еще? У нас в продакшене версия 1.8 есть (будет заменяться вскоре на 13,8 LTS) — проблем не замечено со стеком. Аптайм год без сбоя, на нем около 5800+ телефонов, так что полагаю Вам досталась сырая 1.4?
нет. 1.4 уже давно в архиве был, и на новом проде я бы ее никогда не стал бы использовать. Я тогда смотрел и 1.8, и 11 версию и 13(или 12-я, я точно не помню какая тогда была в стабильных).
В общем на конец 2014 года, pj_sip вроде был уже стабильный, но доступный функционал и количество репортов на него было устращающе большое, и я не рискнул начинать под него разработку. И к тому времени у меня был небольшой опыт в работе с ФС(в свободное время читал и «выполнял домашние задания»). И на тот период он мне нравился все больше и больше, и на новый проект было принято решение разрабатывать в качестве основного медиа сервера и сервера регистрации ФС, с возможностью в будущем перенести регистрацию на камаилио и оставить фс только как медиа.
И да, я сразу не сказал что у меня текущий проект с webrtc, и ФС уже тогда работал с ним прекрасно из коробки, а вот с астериском было не все так гладко. Как мне сказали компании аутсорсеры по астериску, на одном из городских IT сабонтуйничках, что вроде в последней версии у астера еще были проблемы с webrtc. Но тут, как говорится «мопед не мой». За что купил, за то и продаю :) Сам тему не изучал.
В общем на конец 2014 года, pj_sip вроде был уже стабильный, но доступный функционал и количество репортов на него было устращающе большое, и я не рискнул начинать под него разработку. И к тому времени у меня был небольшой опыт в работе с ФС(в свободное время читал и «выполнял домашние задания»). И на тот период он мне нравился все больше и больше, и на новый проект было принято решение разрабатывать в качестве основного медиа сервера и сервера регистрации ФС, с возможностью в будущем перенести регистрацию на камаилио и оставить фс только как медиа.
И да, я сразу не сказал что у меня текущий проект с webrtc, и ФС уже тогда работал с ним прекрасно из коробки, а вот с астериском было не все так гладко. Как мне сказали компании аутсорсеры по астериску, на одном из городских IT сабонтуйничках, что вроде в последней версии у астера еще были проблемы с webrtc. Но тут, как говорится «мопед не мой». За что купил, за то и продаю :) Сам тему не изучал.
>> В общем на конец 2014 года, pj_sip вроде был уже стабильный,
Он до сих пор не пригоден к использованию. Мы сразу от него отказались.
>> возможностью в будущем перенести регистрацию на камаилио и оставить фс только как медиа.
Этот проект рассматривали?
Он до сих пор не пригоден к использованию. Мы сразу от него отказались.
>> возможностью в будущем перенести регистрацию на камаилио и оставить фс только как медиа.
Этот проект рассматривали?
если бы «комьюнити» что астериска, что freeswitch не жило за счет тайных незадокументированных знаний, которые надо гуглить или вычислять опытным путем, оба проекта были бы куда стабильнее, как программные продукты. Но нет, экспертам же невыгодно (:
А что значит «проворнее»? На каком количестве звонков Asterisk начнёт тормозить на сервере с 24 ядрами и 128 ГБ памяти?
Понятия не имею. Я оперирую тем железом которое есть, а не которое хочется что бы было. И клиенты, которые используют наше ПО тоже такие сервера не покупают. Поэтому свои 20000 — 25000 звонков в сутки ФС и * обрабатывают с совершенно разной нагрузкой на сервер. Я понимаю что и астер можно затюнить, но только вокруг ФС я тоже не сильно прыгал.
25000 звонков в сутки(17 в минуту, при стандартном ACD 100 каналов) обрабатывает без существенной нагрузки один сервер. Вобщемто все, что меньше 10 в секунду не должно вызывать нагрузки. Есть системы, в которых до миллиона звонков в день на *, и они достаточно просты.
Тут вопрос в подходе авторов. FS по умолчанию затюнен на перфоманс(reinvite, rtp в обход и так далее), в то время как asterisk затюнен на максимальное compatibility.
Тут вопрос в подходе авторов. FS по умолчанию затюнен на перфоманс(reinvite, rtp в обход и так далее), в то время как asterisk затюнен на максимальное compatibility.
На 600-1500 примерно(цифра зависит от того, какую латентность вы считаете приемлимой). Если один астериск. Зависит от диалплана и длительности звонков, конечно, но это у него такое фундаментальное ограничение вызваное блокировками. На железе с 24 ядрами запускается 4-8 разных астерисков и балансер(kamailio). Но интересно то, что у FS с блокировками та же фигня. При сравнимом диалплане(реальном, не том который в доках по FS) и равной оптимизации разница в пределах 20-30% и не всегда(не во всех диалпланах) в сторону FS.
1500? Ну-ну :)
У нас на продакшене 1 сервак отрабатывает почти 600 звонков в каждый момент времени при нагрузке 7-8% на процессор. А он такой же почти как в условии выше, только памяти меньше.
Общее количество звонков через него 80к в сутки.
Я вам гарантирую, что число там порядка 10к, не меньше
У нас на продакшене 1 сервак отрабатывает почти 600 звонков в каждый момент времени при нагрузке 7-8% на процессор. А он такой же почти как в условии выше, только памяти меньше.
Общее количество звонков через него 80к в сутки.
Я вам гарантирую, что число там порядка 10к, не меньше
Ну попробуйте 10к, потом сообщите результат. У меня есть система обрабатывающая уже лет 5 от 400к до 1500к звонков каждый день(система обработки терминации). С большим аптаймом не работает астериск при большом количестве звонков. Вечно что-то блокируется. Проще запустить 4 на сервак.
По той же причине нет особого смысла ставить астериск на cpu с количеством ядер больше 4.
И не пугайте меня фразами типа ххК звонков в сутки. Они ничего не значат без параметров ACD,ASR и описания диалплана, да и даже мой упрощенный вариант обзвонщика(не говоря про полноценные) расчитан на cps>5(тоесть такие же обьемы в час)
По той же причине нет особого смысла ставить астериск на cpu с количеством ядер больше 4.
И не пугайте меня фразами типа ххК звонков в сутки. Они ничего не значат без параметров ACD,ASR и описания диалплана, да и даже мой упрощенный вариант обзвонщика(не говоря про полноценные) расчитан на cps>5(тоесть такие же обьемы в час)
>> С большим аптаймом не работает астериск при большом количестве звонков. Вечно что-то блокируется. Проще запустить 4 на сервак.
Тут явно противоречие, 1.5 млн звонков в день и один сервак с 4 астерисками. У вас явно тут ошибка в архитектуре. Почему не кластер Актив-Актив? Блокируется потому что есть программное ограничение, уже талдычим не первый коммент.
>> По той же причине нет особого смысла ставить астериск на cpu с количеством ядер больше 4.
Обоснуй.
Тут явно противоречие, 1.5 млн звонков в день и один сервак с 4 астерисками. У вас явно тут ошибка в архитектуре. Почему не кластер Актив-Актив? Блокируется потому что есть программное ограничение, уже талдычим не первый коммент.
>> По той же причине нет особого смысла ставить астериск на cpu с количеством ядер больше 4.
Обоснуй.
Кстати, просто интересно, в какой компании 1.5 ляма звонков в сутки?
Я вот вроде в крупной компании работаю, но 1.5 ляма это явно очень много для нас.
Ростелеком? Бибилайн? Мтс?
Я вот вроде в крупной компании работаю, но 1.5 ляма это явно очень много для нас.
Ростелеком? Бибилайн? Мтс?
Все просто, астериск ляжет при 20к+ каналах. От железа это мало зависит, если вы не используете транскодинг.
Максимум что мне удалось добиться — это 24к канала в режиме тишины. При этом загрузка процессора была средней. Астериск 13.2
После этого вы получите в лучшем случае дрожащий голос, в худшем отлуп при попытке регистрации или инвайта. Как я писал выше в коментах, там програмные ограничения есть.
Мы гоняли на 16 ядрах астериск. В полку он так и не уперся, ни по памяти ни по ядрам…
Максимум что мне удалось добиться — это 24к канала в режиме тишины. При этом загрузка процессора была средней. Астериск 13.2
После этого вы получите в лучшем случае дрожащий голос, в худшем отлуп при попытке регистрации или инвайта. Как я писал выше в коментах, там програмные ограничения есть.
Мы гоняли на 16 ядрах астериск. В полку он так и не уперся, ни по памяти ни по ядрам…
Сколько гоняли? День, месяц, год? Что, говорите, у астериска нет проблем при стандартном ACD(оно 5 минут если что), при 20к каналов(тоесть cps 66-100) устойчиво на промежутке хотя бы в неделю?
Понимаете, пробелема в том, что для софсвичей показатель «может держать ххххх каналов с тишиной» совершенно бесполезен.
По сути у астериска 1.8+ ограничение в районе 20-30cps. После чего начинаются всякие приколы.
Понимаете, пробелема в том, что для софсвичей показатель «может держать ххххх каналов с тишиной» совершенно бесполезен.
По сути у астериска 1.8+ ограничение в районе 20-30cps. После чего начинаются всякие приколы.
Знаете, мне начинает казаться что у вас цель просто спорить :)
>> у астериска нет проблем при стандартном 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 к каналов есть ограничение програмное и не зависит от железа. На этом точка.
>> у астериска нет проблем при стандартном 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 к каналов есть ограничение програмное и не зависит от железа. На этом точка.
чего за железо / операционка если не секрет?
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 нод…
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 нод…
Упс, ошибся веткой. Это ответ для g613
> чего за железо / операционка если не секрет?
CentOS 7 / 16 * E7@2400 / 32G Ram
>> 800 cps это сильно… PDD какой при этом?
Это предел. PDD при этом до 5-6 сек. При 600 вполне нормальный PDD — 1-2c. Есть определенная связь между количества ядер и CPS, которые нормально переносятся астериском.
Опять же, при такого рода тестах очень часто утыкаемся не в скорость создания каналов, а в обработку уже существующих каналов — достигается лимит по каналам, в результате чего деградирует CPS. Поэтому производительность астериска уместно рассматривать в совокупности 2 параметров — количества звонков «онлайн» и CPS.
Обычно после этого:
начинаются проблемы с прохождением звонков. Разгрузить астериск можно отключив то что использует таскпроцессор — CDR, WEB, и тд. Более подробный список находиться в исходниках. На данный момент, это горлышко бутылки для астериска.
Интересно послушать, были ли у кого-то аналогичные исследования на эту тему и к каким выводам пришли. Логично предположить, что раз астериск не утыкается в полку, но звонки начинает отбивать, то это внутренняя проблема, которую, возможно, можно исправить.
> чего за железо / операционка если не секрет?
CentOS 7 / 16 * E7@2400 / 32G Ram
>> 800 cps это сильно… PDD какой при этом?
Это предел. PDD при этом до 5-6 сек. При 600 вполне нормальный PDD — 1-2c. Есть определенная связь между количества ядер и CPS, которые нормально переносятся астериском.
Опять же, при такого рода тестах очень часто утыкаемся не в скорость создания каналов, а в обработку уже существующих каналов — достигается лимит по каналам, в результате чего деградирует CPS. Поэтому производительность астериска уместно рассматривать в совокупности 2 параметров — количества звонков «онлайн» и CPS.
Обычно после этого:
начинаются проблемы с прохождением звонков. Разгрузить астериск можно отключив то что использует таскпроцессор — CDR, WEB, и тд. Более подробный список находиться в исходниках. На данный момент, это горлышко бутылки для астериска.
Интересно послушать, были ли у кого-то аналогичные исследования на эту тему и к каким выводам пришли. Логично предположить, что раз астериск не утыкается в полку, но звонки начинает отбивать, то это внутренняя проблема, которую, возможно, можно исправить.
5-6 секунд это не серьезно. у нас камалио машину мертвой метит если не получил 100 на инвайт за секунду.
и повторюсь, что уперлись мы в то, что астериск не успевает выгребать ртп пакеты из сетевого стека.
pjsip или chan_sip кстати?
и повторюсь, что уперлись мы в то, что астериск не успевает выгребать ртп пакеты из сетевого стека.
pjsip или chan_sip кстати?
>> 5-6 секунд это не серьезно
Горизонтальное масштабирование, canreinvite=yes. Все же зависит от задачи.
>> астериск не успевает выгребать ртп пакеты из сетевого стека.
Вот поэтому нужно больше процессоров :) Больше прерываний. Ну а серьезно — мониторили, в чем затык? strace что нибудь сказал? В каком моменте «горлышко бутылки»? Кстати, еще раз — canreinvite=yes — может существенно улучшить положение.
chan_sip
Горизонтальное масштабирование, canreinvite=yes. Все же зависит от задачи.
>> астериск не успевает выгребать ртп пакеты из сетевого стека.
Вот поэтому нужно больше процессоров :) Больше прерываний. Ну а серьезно — мониторили, в чем затык? strace что нибудь сказал? В каком моменте «горлышко бутылки»? Кстати, еще раз — canreinvite=yes — может существенно улучшить положение.
chan_sip
canreinvite=yes не будет медию проксировать.
без медии нам не интересно.
затык в том что астериск гоняет пакеты через user спейс.
без медии нам не интересно.
затык в том что астериск гоняет пакеты через user спейс.
>> затык в том что астериск гоняет пакеты через user спейс.
кхм… а есть другой способ проксировать?
кхм… а есть другой способ проксировать?
если не надо транскодировать и делать репакатизацию то можно просто в кернел спейсе переложить. но в софте который сильно заточен для офисной атс этого наверное не стоит ожидать.
Нужен модуль, который будет используя xTables Api или ip Route Table выставлять маршрутизацию в ядре, чтобы пакеты не доходили до астериска, а сразу ремаршутизировались на удаленного клиента.
Данные для маршрутизации модуль может брать прям из текущей сессии, там же указан и адрес источника и адрес назначения и необходимость транскодинга.
Данные для маршрутизации модуль может брать прям из текущей сессии, там же указан и адрес источника и адрес назначения и необходимость транскодинга.
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кластер Asterisk. Централизация информации о регистрации