Сбой при сборе огромной конференции.

[Reader]

Здравствуйте, уважаемые господа специалисты.
Использую Elastix 2.4.0, 32bit. Подключен 4мя потоками Е1 к электронной TDM-PBX. Всё работает. Но. Появилась задача автоматически к определённому времени собрать довольно большую конференцию из 75 участников TDM-PBX. А она не собирается !! Т.е. абоненты сами могут собраться самостоятельно. А в автоматическом режиме Elastix собирает только ну в лучшем случае 18...20 участников. Остальных - даже дозвон не проходит !! Что делать ?!
Немного подробностей. У меня получается собирать более маленькую конференцию из примерно 30 участников. Путём запуска из crontab 2х групп обзвона с разницей в 1 минуту (по 15 участников в одной группе обзвона). Уже несколько недель. И всё работает - абоненты безмерно счастливы. А вот с сбором большой вылезли проблемы. В каждой группе обзвона я включил 25 участников. Колл-файлы для каждого участника - идентичны колл-файлам для более маленькой конференции. Но когда Elastix обзванивает 1 группу из 25 участников - ещё всё более менее (кто-то отвечает сразу, кто-то черед 15...18 сек., чья-то линия занята, Elastix ему перезванивает. Кто-то не отвечает. 18...19 чел. набирается за 1 мин. легко и непринуждённо. Начинается 2й обзвон ещё 25 участников - и далее обзвон затыкается !!!!!!! Почему-то ! Хотя свообдных ресурсов ещё на тот момент в Elastix полно - более 80% по мощности проца и более 75% по памяти ! Значит не в ресурсах дело. А в чём ? Смотрю трассировку - всё как на первом круге обзвона, но почему-то Elastix вдруг перестаёт звонить и всё !!!!! Перепроверил весь путь к колл-файлам, права поьлзователя каждого колл-файла - всё идентично !! А третий цикл обзвона последних 25 участников - вообще не робит !!!!!!!!!!!!!!!! Ну что же это может быть за затык ? Куда курить ?

[Vlad1983]

Скорей всего натыкается на заблокированные со стороны TDM-PBX канальные интервалы.

[virus_net]

Куда курить ?

мне кажется в сторону кол-ва одновременно обрабатываемых call-файлов и соответственно кол-ва одновременных вызовов.

Подключен 4мя потоками Е1

а точно все потоки исправны ?

и далее обзвон затыкается

а можно более детально раскрыть понятие "затыкается" ?

[Sfinx]

Когда я делал похожее custom'ное решение, то вставлял задержку (100-200ms) перед каждым набором номера в сторону E1, так как TDM подразумевает старую станцию и соответствующие тормоза/timeout'ы. И потом, в call-файлах есть чудесные параметры - количество наборов и пауза между ними - они тоже играют роль в стабильном наборе участников. В моем случае было всего два потока и 40-50 чел, среднее время сбора в конфу - секунд 40

[Reader]

На форуме не был 2 дня. Делал испытания с разными параметрами. Кое-что всё-таки сдвинулось с мёртвой точки.
Да, все 4 потока E1 ISDN PRI у меня исправны и исправно настроены. С целью их проверки TDM автоматом даже запускает каждое утро и в обед по одному тесту по каждому потоку Е1 чтобы не дай бог какая-нибудь из маленьких конференций не сорвалась и администратор телефонии не получил по шапке. 2 дня потоки пашут отлично (впрочем и до этого пахали целую пятилетку - включал я их в экспл. в 2008 г. - TDM-PBX тоже мой объект, сравнительно новая АТС с отличными рекомендациями). Итак, мелкие конференции пашут целыми днями с качеством достойным восхищения. Крохоборы-участники пока довольны.
Теперь о большой конференции. Пытался испытывать её на живых участниках (как уже писал в начале своей темы) - получил по конкретной шапке ! Хотя все варианты исхода 1001 раз согласовывались на самом верху конторы. И сразу желание проводить испытания на живых людях пропало навсегда. Стал проводит испытания среди себя. Т.е. собрал на столике 5 телефонов от TDM-PBX. И по crontab собрал их автоматом. Собирается всё чётко как по часам. Слышимость - супер. Априоре также понятно, что конференция ёмкостью до 35 участников через crontab путём 2х кругов обзвона по 15...18 участников в каждом собирается также легко и непринуждённо и работает как по нотам. Каждый день. Ну и наконец возвращаемся наконец к нашему барану - гигаконференции. Сделал схему сбора гигаконференции: есть 75 свободных абонентских портов на TDM-PBX. Но нет 75 автоответчиков, чтоб снимали трубки и участвовали. Пришлось ставить на каждый из аналоговых незанятых портов на TDM переадресацию на автоответчик, находящийся внутри Elastix (это я умею чётко). Запустил по crontab 3 круга обзвона по 25 участников каждый. Через 4 минуты обнаружил, что на Elastix в meetme имеются только 19 участников, а ещё 19 участников с А-номером инициатора обзвона слушают Music-on-Hold с Elastix. Ну, примерно 10 минут поглазел на этих 19 участников и прервал эксперимент - результат-то не очень. Почему не очень, ну во-первых у меня в контексте не было повторного звонка вообще !!! Думал, что поскольку все неиспользуемые абонентские порты TDM по определению всегда свободны, то отбоев не будет ... Немного посмотрел на трассировку процедуры сбора (CLI) - всё равно видны затыки при попадании исхоящего звонка от Elastix в TDM при занятости конкретного канала конкретного потока Е1. Обнаружил, что Elastix в момент начала запуска круга обзвона просто пытается занимать первую попавшуюся свободную линию, и если та congestion - то иногда ищет свободную линию в этом же потоке, а иногда и вообще не ищет ! Это было для меня неожиданностью. Впрочем даже на самом первом круге обзвона в какой-то момент все 120 канальчиков до TDM были заняты ! Как тут не начнутся затыки попыток дозвониться Elastix до вызываемого абонента TDM ... Печално ! Впрочем вот образец call-file:
Channel:DAHDI/g0/2252
CallerID: 79
MaxRetries:0
RetryTime:01
WaitTime:15
Context:vgp-call
Extension:79
Priority:1
Все остальные 74 колл-файла - точная копия данного (за исключением 4х-значного персонального номера свободного абонентского порта TDM в первой строке).
Ну что делать - надо рыть. Взял и увеличил время дозвона от Elastix до TDM с 15 до 18 секунд ! Запустил мегаиспытание по crontab. И через 4 минуты получил картину: 34 channels active + spy ch.; 17 meetme. Согласитесь - уже лучше !
Усугубил эксперимент. Оставил 18 сек дозвона до TDM, внедрил 1 повтор на случай неудачи + RetryTime=9 sec. Получил такой колл-файл:
Channel:DAHDI/g0/2252
CallerID: 79
MaxRetries:1
RetryTime:09
WaitTime:18
Context:vgp-call
Extension:79
Priority:1
Исправил аналогично все до единого оставшиеся 74 колл-файла. Запустил. Итог (через 4 минуты и далее стабильно): 67 channels active + spy ch.; 33 meetme. Уже гораздо лучше !! Но всё равно несколько раз самолично наблюдал картину, когда все 120 channels задействованы ... Таких моментов стало больше. Да бог с ними - опять я в раздумье - а надо ли увеличивать дальше количество повторов обзвона - ведь если абонент уже заранее самостоятельно подключился в гигаконференцию (такая возможность все прописана без исключения), то зачем тревожить несколько раз его порт ?
Вобщем куда лучше курить ? Читал я в O'Reilly, что одновременно нежелательно делать обзвон пачками более 30 абонентов. У меня 25 в одной пачке обзвона - оптимизировать тоже некуда - итак всё оптимально. Можно конечно сделать пачку толщиной и 15 абонентов, но тогда понадобится не 3 круга обзвона, а цельных 5 ! Абоненты за 5 мин. разнервничаются ! И опять мне по шапке. Может мне стоит в каждый последующий колл-файл внутри одного круга обзвона действительно добавить задержку на 2...3 сек. по сравнению с предыдущим ?! Кстати, а как это делается ? Я просто никогда не делал ...

[Vlad1983]

посмотреть порядок выбора КИ со стороны TDM
со стороны астериска сделать с протипоположным алгоритмом

[SVoy]

я надеюсь, что гигаконференции - это какой-то лекторий, а не селектор у начальника.. ))) если второе, то у вас очень крутая контора с кучей свободного времени у сотрудников..

[Sfinx]

Кстати, а как это делается ? Я просто никогда не делал ...

как это делается в elastix - х.з. в астере call file запускается по времени его модификации, т.е. никто не мешает поставить время для каждого следующего файла на пару сек. вперед - в unix для этого служит команда touch с опцией -d. если хочется ставить время на миллисекунды, то следует убедится что FS держит nanoseconds timestamp'ы. проверить можно с помощью 'ls --full-time' - в выводе времени должны быть цифры после точки в секундах.

[virus_net]

Может мне стоит в каждый последующий колл-файл внутри одного круга обзвона действительно добавить задержку на 2...3 сек. по сравнению с предыдущим ?! Кстати, а как это делается ? Я просто никогда не делал ...

совсем недавно этот вопрос поднимался в топике Callback средствами bash

[Reader]

Здравствуйте, уваж. спец-ты.
Вобщем не разобрался я с командами Bash. C вставлением задержки перед каждым следующим колл-файла - тоже не разобрался. А лупанул влоб - увеличил по сравнению с предыдущими экспериментами кол-во попыток дозвона до 3х (MaxRerties:2) и увеличил таймаут между попытками дозвона внутри каждой группы колл-файлов до 9 сек. (RetryTime:09). Образец колл-файла стал выглядеть так:
Channel:DAHDI/g0/2252
CallerID: 79
MaxRetries:2
RetryTime:09
WaitTime:18
Context:vgp-call
Extension:79
Priority:1
Все остальные 74 колл-файла - точная копия данного (за исключением 4х-значного персонального номера свободного абонентского порта TDM в первой строке).
Запустил мегаиспытание по crontab. И уже через 2,5 минуты получил картину: 120 channels active + 4 spy ch.; 60 meetme. Короче - это максимальная конфигурация, которая только возможна с моей платой на 4 E1. Понятно, что 2 круга обзвона прошли с максимальной эффективностью, а последний круг - даже и не начался - уже все каналы Е1 к тому времени были заняты. Решил тут же вручную освободить все каналы командой "meetme kick 79 all". Канальчики все до одного освободились. И далее снова начались заниматься, но восновном остатками участников 2й группы обзвона и 3й группой обзвона. И вскоре опять почти опять ужас как быстро образовалась могучая конференция с кучей участников.
Короче говоря, похоже и без bash можно стандартными средствами быстренько собрать конференцию из 75 участников.
Все остальные вопросы пока вторичны. TDM-PBX конечно визжит, шо нагрузка на ней великовата по потокам (по трассировке ошибок TDM-PBX это видно невооружённым глазом) - но таки собирает конференцию. Понятно, почему визжит - при каждом звонке с Эластикса занимается почти сразу 2 СЛ. А одна группа обзвона сразу за минуту занимает 50 СЛ. С учётом разбора конфликтов по занятию одной и той же СЛ одновременно с 2х концов и повторного поиска/занятия первой_попавшейся_свободной_СЛ со стороны TDM-PBX как раз весь ресурс TDM-PBX и исчерпывается ! Но пока справляется, но на пределе. Как спасти TDM-PBX, если начальству через год размер конфы покажется маловат - ума не приложу. Придётся курить команды bash. Блин, взялся поразбирать тему "Как изменить порядок занятия СЛ в Elastix с традиционного (с 1го по 120 по-порядку) на нетрадиционный (с 120го по 1й по-порядку)" - не могу в стандартных установках Elastix найти где это изменить. Это был бы на первое время выход. Иначе придётся лезть в содержимое файлов *.conf - это займёт с непривычки кучму времени.
Да, забыл сказать: Elastix в разы мощнее по совокупной процессорной и RAM мощности, чем TDM. И потому его не жалко. А жалко TDM. Elastix запросто может даже на этапе теста заплевать TDM своими звонками и свалить TDM в релоуд.
Понятно, что на реальных TDM-абонентах Elastix отнимет ресурсов у TDM-PBX раза в 2 поменьше. Вся надежда только на это. Конечно по-хорошему нужно и время дозвона уменьшить и кол-во обзвонов второстепенным участникам уменьшить до одного (но это придётся делать незаметно уже на этапе опытной эксплуатации гигаконференции) и кол-во посылок вызова к участникам уменьшить. Может кто-то что-то ещё сможет предложить по оптимизации отъёма ресурсов у TDM-PBX ? Было бы очень кстати ...