Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 94
Ответьте пожалуйста (но только с удовольствием).
В чем же глюкавость FreePBX? Не в генах ли одмина, который его некорректно настроил, а потом обвиняет FreePBX в глюкавости?
В чем же глюкавость FreePBX? Не в генах ли одмина, который его некорректно настроил, а потом обвиняет FreePBX в глюкавости?
Можно долго спорить на эту тему, но подозреваю, что из-за апгрейда PHP что-то может внезапно поломаться.
>> Вас не смущает, что FreeBPX хранит пароли открытым текстом?
Ну это типичная уязвимость, которой воспользоваться может только тот, кто и так имеет достаточно прав в системе.
>>А как Вам вот этот баг trixbox?
Это не баг, это жопоголовость разработчиков трикса. Она не имеет н-и-к-а-к-о-г-о отношения к FreePBX. Трикс — давно померший дистр. А о покойниках — хорошо или ничего.
Ну это типичная уязвимость, которой воспользоваться может только тот, кто и так имеет достаточно прав в системе.
>>А как Вам вот этот баг trixbox?
Это не баг, это жопоголовость разработчиков трикса. Она не имеет н-и-к-а-к-о-г-о отношения к FreePBX. Трикс — давно померший дистр. А о покойниках — хорошо или ничего.
Глюкавость FreePBX в отсутствии архитектуры, использовании PHP и MySQL и полное отсутствие знаний (изначально) у авторов про network security.
Asterisk + FreePBX = два сапога пара.
У обоих ошибка в ДНК.
Но это не мешает им выполнять свои функции :-)
Эта связка = TOP 1 IP PBX в мире :-)
У правильной IP АТС совсем другая должна быть архитектура, в мире пока таковых не наблюдается :-)
У обоих ошибка в ДНК.
Но это не мешает им выполнять свои функции :-)
Эта связка = TOP 1 IP PBX в мире :-)
У правильной IP АТС совсем другая должна быть архитектура, в мире пока таковых не наблюдается :-)
Если не затруднит, изложите, пожалуйста, свое видение архитектуры (хотя бы в пару фраз).
И можете указать хотя бы пару реальных ошибок в ДНК?
И можете указать хотя бы пару реальных ошибок в ДНК?
Что ж, пофлеймим чуток.
1. asterisk — multithread и использование mutex. При очень больших нагрузках и неаккуратном тестировании получаем вылет SIP-стека на версиях 1.6-1.8.х вплоть до современных. Уточнение: при использовании Queue(). Надо качественнее код писать.
2. freepbx — один раз настроить систему, а потом не трогать вообще, за исключением добавления модулей. Иначе в любой момент из-за приколов PHP, apt или yum можно получить неработающую АТС.
1. asterisk — multithread и использование mutex. При очень больших нагрузках и неаккуратном тестировании получаем вылет SIP-стека на версиях 1.6-1.8.х вплоть до современных. Уточнение: при использовании Queue(). Надо качественнее код писать.
2. freepbx — один раз настроить систему, а потом не трогать вообще, за исключением добавления модулей. Иначе в любой момент из-за приколов PHP, apt или yum можно получить неработающую АТС.
> При очень больших нагрузках
Именно так. В Asterisk все хорошо, пока нет нагрузки.
И ошибка в ДНК проявляется именно тогда, когда она появляется.
Отсюда следует одно следствие — нельзя использовать маломощные green устройства, потому что там CPU изначально мало, и Asterisk начинает лажать уже на детских нагрузках.
К FreePBX с точки зрения архитектуры у меня такие же претензии, как и к Switchvox — «тяжелая» база, «тяжелый» GUI, а самое главное, «тяжелый» AGI. Просто в Switchvox все эти «мелочи» решены за счет жесткого тюнинга системы, и тщательного тестирования (коммерческий продукт все же). И к тому же, в Switchvox нельзя залезть ручками, и все поломать, а то, что делается через WEB интерфейс (обновления) — тщательно тестируется. Короче, Switchvox доказывает, что даже если продукт не идеален с точки зрения архитектуры, он может быть неплох.
Именно так. В Asterisk все хорошо, пока нет нагрузки.
И ошибка в ДНК проявляется именно тогда, когда она появляется.
Отсюда следует одно следствие — нельзя использовать маломощные green устройства, потому что там CPU изначально мало, и Asterisk начинает лажать уже на детских нагрузках.
К FreePBX с точки зрения архитектуры у меня такие же претензии, как и к Switchvox — «тяжелая» база, «тяжелый» GUI, а самое главное, «тяжелый» AGI. Просто в Switchvox все эти «мелочи» решены за счет жесткого тюнинга системы, и тщательного тестирования (коммерческий продукт все же). И к тому же, в Switchvox нельзя залезть ручками, и все поломать, а то, что делается через WEB интерфейс (обновления) — тщательно тестируется. Короче, Switchvox доказывает, что даже если продукт не идеален с точки зрения архитектуры, он может быть неплох.
Ну давайте, рассказывайте, ЧЯДНТ:
[root@*** ~]# asterisk -rx 'core show version'
Asterisk 1.8.10.0 built by mockbuild @ build-server on a x86_64 running Linux on 2012-04-27 12:31:41 UTC
[root@*** ~]# asterisk -rx 'core show channels' | grep Queue | wc -l
54
Как видите, на текущий момент 54 звонка в очередях, в пике бывает до 100.
Дедлоков на этом сервере не было никогда.
[root@*** ~]# asterisk -rx 'core show version'
Asterisk 1.8.10.0 built by mockbuild @ build-server on a x86_64 running Linux on 2012-04-27 12:31:41 UTC
[root@*** ~]# asterisk -rx 'core show channels' | grep Queue | wc -l
54
Как видите, на текущий момент 54 звонка в очередях, в пике бывает до 100.
Дедлоков на этом сервере не было никогда.
Вас можно только поздравить :)
не хватает asterisk -rx 'core show uptime', и tail -30 /proc/cpuinfo
:)
а вообще `100 в пике` это совсем не нагрузка на современном железе.
:)
а вообще `100 в пике` это совсем не нагрузка на современном железе.
Ну, конкретно эту систему в понедельник перенесли на новый сервер богатенького заказчика, так что там сейчас аптайму несколько дней и с железом все хорошо — 24 ядра, 64 Гб памяти итд. А вообще до этого оно бегало на десктопе с Core i5, а аптаймы судя по мониторингу, по нескольку месяцев были.
100 в пике не нагрузка для железа, но всё-же минимум 100 операторов — такой колл-центр не каждой компании нужен :)
А вот еще забавные буковки:
XXX*CLI> core show version
Asterisk 1.4.21.1 built by root @ cocytus on a i686 running Linux on 2008-07-30 07:55:10 UTC
XXX*CLI> core show uptime
System uptime: 3 years, 47 weeks, 3 days, 21 hours, 53 minutes, 17 seconds
Last reload: 4 weeks, 3 days, 5 hours, 55 minutes, 56 seconds
Перезагружать страшно :)
100 в пике не нагрузка для железа, но всё-же минимум 100 операторов — такой колл-центр не каждой компании нужен :)
А вот еще забавные буковки:
XXX*CLI> core show version
Asterisk 1.4.21.1 built by root @ cocytus on a i686 running Linux on 2008-07-30 07:55:10 UTC
XXX*CLI> core show uptime
System uptime: 3 years, 47 weeks, 3 days, 21 hours, 53 minutes, 17 seconds
Last reload: 4 weeks, 3 days, 5 hours, 55 minutes, 56 seconds
Перезагружать страшно :)
А что насчет *CLI> core show calls?
в 1.4 нет статистики сколько было звонков
Тот, что 1.4 он на расслабоне, меньше сотни звонков в сутки, просто E1 в SIP гонит.
А тот, что 1.8, ну, можете вот посмотреть картинку с заббикса.
А тот, что 1.8, ну, можете вот посмотреть картинку с заббикса.
А что насчет core show uptime? Да и общий uptime linux?
Эта связка = TOP 1 IP PBX в мире :-)
А доказать сможете? Мне всегда казалось, что рынком владеют Cisco и Avaya. А опенсорсные и фриварные решения далеко не так популярны.
Беглый поиск — www.xorcom.com/ftp/partners/emg-battlefield-white-paper.pdf
Does the proprietary PBX market eventually recover, retain its 82 percent market share, and peacefully coexist with Open Source PBXs, which today hold the remaining 18 percent?
Упс. Господа, я имел в виде TOP 1 среди бесплатных поделок :-)
Рынком, может и владеют. Но ни один вменяемый человек это покупать не будет. Дорого и глупо.
Знаете сколько вменяемых за откаты такое покупало, покупает и будет покупать? Кроме того, в очень больших корпорациях покупка такого железа считается правильным и никто даже не возражает. И я знаком с несколькими инсталляциями, где затраты на внедрение asterisk* очень даже превышают затраты на внедрение cisco*. Подробности, к сожалению, скрыты под коммерческой тайной ибо корпорации со своими странностями (как же я их &^%@$5!)
Как можно называть человека, покупающего за откаты, вменяемым?
В очень больших корпорациях, если там у людей есть мозг, покупают решения гораздо более продвинутые попсовой цыски или вечно глючной авайи.
В очень больших корпорациях, если там у людей есть мозг, покупают решения гораздо более продвинутые попсовой цыски или вечно глючной авайи.
В таком случае как можно назвать человека, просто работающего в большой корпорации, вменяемым? Большой энтерпрайз он был, есть и будет. И решения энтерпрайз тоже были, есть и будут. Они друг друга замечательно дополняют. Я, к счастью, к таким не отношусь.
На тему глючной авайи можете не рассказывать. Сталкивался с ней. Не SMB-решения (IP-Office д
.авно еще то!) работают отлично. И циска опять таки не совсем попсовая. И работает стабильно. И поддержка есть. Просто у каждого свой рынок.
PS. Продвинутей чем Cisco. Можно ли узнать о чем конкретно идет речь и в каких областях?
На тему глючной авайи можете не рассказывать. Сталкивался с ней. Не SMB-решения (IP-Office д
.авно еще то!) работают отлично. И циска опять таки не совсем попсовая. И работает стабильно. И поддержка есть. Просто у каждого свой рынок.
PS. Продвинутей чем Cisco. Можно ли узнать о чем конкретно идет речь и в каких областях?
Знаете, в масштабах крупной компании инфраструктура на CUCM значительно дешевле астериска, freepbx и тому подобного :)
Вы наверное даже аргументы привести сможете?
Конечно. Вы можете себе представить, каких усилий стоит сопровождение территориально распределенной сети из астерисков, когда есть сотни гейтвеев и десятки тысяч телефонов?
Вроде никто из пытавшихся сэкономить на DLU лицензиях так и не смог более полугода продержаться на опенсорсе (об одном таком случае знаю лично). Ну не приспособлено оно для такого. Это вам не мелкая фирма на 50 человек.
Вроде никто из пытавшихся сэкономить на DLU лицензиях так и не смог более полугода продержаться на опенсорсе (об одном таком случае знаю лично). Ну не приспособлено оно для такого. Это вам не мелкая фирма на 50 человек.
И в чем же проблема? Может в том кто внедряет не умеет автоматизировать?
Затраты на эту самую автоматизацию (по сути — допиливание астериска до работоспособного уровня) слишком велики. А потом возникает проблема поддержки. Нестандартная конфигурация, множество скрытых грабель.
Вопрос не в умении, а в целесообразности использования опенсорса в тех сценариях, для которых он вообще не предназначен.
Вопрос не в умении, а в целесообразности использования опенсорса в тех сценариях, для которых он вообще не предназначен.
Допиливание это по вашему перевод asterisk на Realtime + написание пары(взять уже готовые) скриптов для привязки к AD или другому централизованному каталогу, можно и средствами Asterisk, но для полной кастоматизации не достаточно. Оконечные устройства берутся от того же Digium с настойкой из asterisk или бюджетные варианты с autoprovision(тот же yealink). Если системный администратор или специалисты от внедрения не могут подкорректировать пару скриптов, то тут вопрос квалификации. Конкретно каких параметров автоматизации вам не хватает в Asterisk не люблю пустые разговоры? Скрытые грабли всегда всплывают в первое время, для этого и нужны специалисты которые смогут избежать\отладить их.
С квалификацией проблем не было. Просто астериск принципиально не годится для описанных мной условий (десятки тысяч телефонов, сотни гейтвеев, десятки/сотни единиц DSP, навороченные роут-планы с фейловером и так далее). Я не могу перечислить все грабли, на которые наступили пытавшиеся перейти на опенсорс, но в итоге он был признан никуда не годным, и люди возвращались на циску, авайу, нортел и тому подобное, ибо они работают хорошо без необходимости работы напильником. Если хотите — могу попытаться связаться с человеком, узнать перечень претензий к астериску. Помимо «сопровождать его способен только тот, кто его поднимал, преемник будет бессилен что-либо сделать вне зависимости от своей квалификации».
Простой вопрос, который наверняка сделает дальнейшее обсуждение бессмысленным. Вам доводилось сопровождать астериски в указанном мной сценарии? Да/нет. «Десятки тысяч — нет, но на 50-и телефонах работает нормально» не считается.
Простой вопрос, который наверняка сделает дальнейшее обсуждение бессмысленным. Вам доводилось сопровождать астериски в указанном мной сценарии? Да/нет. «Десятки тысяч — нет, но на 50-и телефонах работает нормально» не считается.
10.000 устройств это на одном сервере? в таком виде нет. Про то что другой не разберется, для этого и пишется документация на любое внедрение. В вашем доводах видно только одно про количество устройств, навороченные диалпланы тут как раз cisco\авайа менее поворотливы, файловер достигается виртуализацией или 2-х кратным резервированием + sip proxy. Встречный вопрос у вас телефонная сеть интегрированная со службой каталогов? Опять же жду эти самые грабли!
10.000 устройств это на одном сервере?</blockquote
На разных серверах само собой. Но только удобно. С возможностью к примеру одним движением мизинца перекидывать устройства между серверами.
тут как раз cisco\авайа менее поворотливы
Например?
файловер достигается виртуализацией или 2-х кратным резервированием + sip proxy.
Это не фейловер, а недоразумение какое-то.
Дайте мне такой фейловер: телефоны при загрузке получают с M равнозначных TFTP (или других) серверов конфигурацию (в том числе упорядоченный список из N серверов для регистрации). Если все до единого сервера регистрации недоступны, то он должен зарегистрироваться на своем default gateway с сохранением номера и назначенными разрешениями по выходу в город, и периодически пытаться достучаться до центральных серверов. Это — задача-минимум, легко решаемая цискиными средствами (за авайку не поручусь).
Встречный вопрос у вас телефонная сеть интегрированная со службой каталогов?
Какой уровень интеграции подразумевается?
А вообще — да, интегрирована. А еще с Lync'ом подружена.
С возможностью к примеру одним движением мизинца перекидывать устройства между серверами.Такое можно и сделать на чистом * достаточно лишь на всех серверах иметь одинаковую базу или реплецировать ее между серверами, но это не правильный подход, как я писал выше нужно использовать SIP PROXY, например kamailio Соответственно уже на kamailio балансировать распределение звонков\регистраций
Это не фейловер, а недоразумение какое-то.
Как раз это и является Failover'ом, то что вы пишите про кучу TFTP серверов это обычное дублирование, причем сделанное на конечном устройстве соответственно полностью зависящая от поддержки в устройстве.И в вашем варианте получается куча серверов молотит в пустую ожидая падения другого, гораздо лучше использовать Heartbeat или High-availability. Ну ОК возьмем случай предложенный вами, на примере аппаратов Yealink которые поддерживает TFTP/HTTP/HTTPS/FTP Autoprovision, указываем HTTPS ссылку на настройки, далее на DNS сервере уже настраиваем несколько раздающих серверов и ВСЕ при этом использовались только стандартные методы балансировки!
По вашим ответам видно что вы пытаетесь пришить метод работы Cisco к Asterisk, это не совсем верно, так как Сisco завязан на своем оборудовании и протоколах и поэтому он использует схемы резервирования на конечных устройствах(я не утверждаю что это плохо, я, у cisco замечательное оборудование). На Asterisk же можно подключить любое оборудование использующее протокол SIP(ну и не только SIP конечно) и поэтому тут надо использовать универсальные методы балансировки\ отказоустойчивости, которые не завязываются на производителя оборудования!
Такое можно и сделать на чистом * достаточно лишь на всех серверах иметь одинаковую базу или реплецировать ее между серверами, но это не правильный подход
Для астериска неправильный, не спорю — он не поддерживает человеческую кластеризацию, нужны дополнительные звенья-костыли.
Лучшая балансировка сервиса достигается тогда, когда клиент (в данном случае телефон, или шлюз) знает про все составляющие кластер ноды и умеет правильно работать с ними напрямую, без посредников.
Как раз это и является Failover'ом, то что вы пишите про кучу TFTP серверов это обычное дублирование
Это и есть идеальная реализация отказоустойчивости вместе с балансировкой нагрузки.
причем сделанное на конечном устройстве соответственно полностью зависящая от поддержки в устройстве.
А это недостаток? Мне всегда казалось, что преимущество.
И в вашем варианте получается куча серверов молотит в пустую ожидая падения другого
Неужели? Но ведь роль TFTP сервера принято поднимать на самих серверах CUCM. Никто не простаивает, все работают эффективно. Если серверов 10, нет смысла делать TFTP на всех, можно три-четыре под это дело выделить.
гораздо лучше использовать Heartbeat или High-availability.
Опять же, почитайте про кластеризацию CUCM.
Вы сейчас используете страшные слова, которые в диковинку только для астериска :)
указываем HTTPS ссылку на настройки, далее на DNS сервере уже настраиваем несколько раздающих серверов и ВСЕ
А перерегистрация на DGW? Вы про это забыли? Это ведь сценарий миниофиса, у которого обвалились все каналы. DNS тоже, соответственно, мертв. Любые внешние системы отрезаны, но телефония (E1, SIP по отдельному шнурку или даже FXO) осталась. Что делать? Как юзерам звонить?
По вашим ответам видно что вы пытаетесь пришить метод работы Cisco к Asterisk, это не совсем верно, так как Сisco завязан на своем оборудовании и протоколах и поэтому он использует схемы резервирования на конечных устройствах
Итого: решения на базе Asterisk объективно хуже по причине вынужденного использования открытых стандартов. Я правильно понял?
На Asterisk же можно подключить любое оборудование использующее протокол SIP
И циска поддерживает любое оборудование SIP. Но максимальный кайф достигается при работе с родными телефонами, зарегистрированными по SCCP.
тут надо использовать универсальные методы балансировки\ отказоустойчивости, которые не завязываются на производителя оборудования!
И эти методы хуже, менее удобны, менее надежны. Дешевле по капексу? Но допиливание и сопровождение мигом наверстают разницу. Только открытые стандарты? А всем плевать.
Именно поэтому ентерпрайзы и бегут от * как от прокаженного. Телефон Cisco идеально дружит с IP-PBX Cisco и гейтвеями Cisco (по совместительству чаще всего роутерами). Телефон Avaya идеально дружит с медиасерверами Avaya. А астериск? Что он может предложить?
Для астериска неправильный, не спорю — он не поддерживает человеческую кластеризацию
Да своими средствами он не поддерживает с этим никто и не спорит, для этого есть другие инструменты.
Это и есть идеальная реализация отказоустойчивости вместе с балансировкой нагрузкиГде тут балансировка, вы можете в реальном времени исходя из загрузки всех нод выбираться оконечным устройством куда отправлять звонок?
Вы сейчас используете страшные словаЭто сарказм что ли?
А перерегистрация на DGW? Вы про это забыли? Это ведь сценарий миниофиса
Это вы забываете что Asterisk ставится на обычное железо на котором может быть тот же DNS резервирующий, соотвевено если упало все то и каналы все значит упали!
Опять же вы мыслите резервированием на конечных устройствах!
Итого: решения на базе Asterisk объективно хуже по причине вынужденного использования открытых стандартов. Я правильно понял?
Где у меня про это написано, я говорю про разные подходы которые применяются, а лучше или хуже это не слова инженера, помню за такие слова на экзаменах у нас любили выгонять с не зачетом.
И циска поддерживает любое оборудование SIP. Но максимальный кайфВ том то и дело что с не Cisco аппаратами вы уже не сделает такую схему резервирования как у вас сейчас.
И эти методы хуже, менее удобны, менее надежны. Дешевле по капексу?
Я разве об этом писал, опять же смотрим про хуже\лучше выше. Эти метода СТАНДАРТНЫ хорошо описаны вот и все.
Что он может предложить?
они и предлагают, очень интересное решение, особенно если посмотреть наработки которые сейчас уже есть и которые в будущем я думаю возьмут сторонние производители IP оборудования.
А вообще вы пытаетесь мне рассказать, что Cisco круто я и так знаю, а то что вы пытались когда-то там перейти и нашли какие-то нерешаемые грабили, про которые я так и не услышал, так у вас скорее всего подход был не правильный, ибо хотели все сделать так как в Cisco, я про это уже и пишу не сколько раз. У каждой платформы есть свои ПОДХОДЫ.
Где тут балансировка, вы можете в реальном времени исходя из загрузки всех нод выбираться оконечным устройством куда отправлять звонок?
Загрузка нод будет статистически одинаковой, когда мы говорим о тысячах конечных устройств.
Это сарказм что ли?
Да ни в жисть :)
Это вы забываете что Asterisk ставится на обычное железо на котором может быть тот же DNS резервирующий, соотвевено если упало все то и каналы все значит упали!
Даже в маленьком бранче на 20 человек? Будете в каждом по астериску вместе с репликой DNS поднимать, если требуется банальный fallback? Ну очень enterprise решение :)
Практика показывает, что каналы падают отдельно от местной телефонии. И с астериском выясняется, что его надежность уже значительно ниже надежности старого-доброго FXO…
я говорю про разные подходы которые применяются, а лучше или хуже это не слова инженера
Заменим «лучше» на «совершеннее». Так ближе к истине? Ну а ставить SIP proxy перед регистраром для внутренних ендпоинтов настолько далеко от совершенства, насколько это вообще возможно.
В том то и дело что с не Cisco аппаратами вы уже не сделает такую схему резервирования как у вас сейчас.
А зачем мне не Cisco аппараты? Вы предлагаете перед гонкой бабочки с тараканом повыдергивать у бабочки крылья? :)
Не Cisco аппараты у нас встречаются разве что в виде софтофонов на мобильниках. Да и там смысла в этом мало по причине наличия Jabber.
Эти метода СТАНДАРТНЫ хорошо описаны вот и все.
А стандарты традиционно отстают от проприетарных решений по возможностям.
у вас скорее всего подход был не правильный
Не, у меня-то хватает мозгов не пытаться заменить проприетарщину опенсорсом :)
У них так и нет полного auto-provisioning? Надо вручную выбирать сервер и DN
Почитали бы хоть внимательно что-ли.
Загрузка нод будет статистически одинаковой, когда мы говорим о тысячах конечных устройств
Так у вас и НЕТ балансировки, а выше пишите что есть.
Даже в маленьком бранче на 20 человек
В маленьких обычно поднимается все на одной машине+ резервирование по железу на 20 человек пойдет и Atom, а вообще все зависит от канала и место положения и важности определенных сервисов, не всегда телефония в приоритете!
ну а ставить SIP proxy перед регистраром для внутренних ендпоинтов настолько далеко от совершенстваОпять же это делается для балансировки нагрузки, если она не нужна можно обойтись обычным HA.
А стандарты традиционно отстают от проприетарных решений по возможностямЯ не буду разводить споры, ибо тема тут об другом
Не, у меня-то хватает мозгов не пытаться заменить проприетарщину опенсорсомНу поздравляю вас, вообще хотелось бы по делу, услышать про те грабли на которые натолкнулись, но похоже бесполезно ибо пошел какой-то флейм
Почитали бы хоть внимательно что-ли.
«Включаем патчкорд и питание в телефон. С помощью mDNS телефон видит доступные сервера»
"После выбора сервера отображается список добавочных номеров"
Куда уж внимательнее? И это абсолютно не похоже на адекватное решение. Адекватное решение — это когда на телефоне вообще ничего нажимать не требуется. Телефон распечатали, воткнули в сеть — он сам обновился до последней прошивки, зарегистрировался и получил номер. В целом, в зависимости от настроек на этом этапе он уже мог бы звонить. Но так делать не рекомендуется, потому номер ему задается вручную вместе с CSS и прочим. Не на самом телефоне, конечно, а на PBX :)
А если для банальной операции по смену номера кто-то должен тыкать в кнопки телефона — такое решение автоматически отправляется в мусор.
В маленьких обычно поднимается все на одной машине+ резервирование по железу на 20 человек пойдет и Atom
Замечательно. Итак, делаем 500 астерисков, по одному на бранч?
не всегда телефония в приоритете!
Ну-ну. Ни в хелпдеск позвонить, ни в скорую. Мобильники расчехлять?
если она не нужна можно обойтись обычным HA.
Балансировка (хотя бы ручная) нужна всегда. Должна иметься возможность размазать ендпоинты по серверам так, чтобы и нагрузка распределялась, и смерть одного-двух серверов прошла незаметно для пользователей. Но вы никак не поймете, что выделенный под это дело сервер там, где можно обойтись без него — не дело. Как не дело и вручную выбирать сервер на каждом телефоне.
вообще хотелось бы по делу, услышать про те грабли на которые натолкнулись
Так я ни на какие грабли не натыкался. Просто слышал про крайне печальный опыт у конкурентов. Да и ключевые проблемы уже были озвучены, решений так и не услышал.
Не на самом телефоне, конечно, а на PBX
Вы можете сами выбирать какой режим для регистрации вам нужен
Замечательно. Итак, делаем 500 астерисков, по одному на бранч?бранч=филиал, зачем 500 достаточно 1 в HA, но все зависит от технических условий
Ну-ну. Ни в хелпдеск позвонить, ни в скорую. Мобильники расчехлять?Возможно вы не поверите, но в России много промзон в которых нету даже обычных FXO линий и да там применяются GSM шлюзы. А если брать пример большого склада в промзоне в котором постоянно загружается фуры, то там важнее связь с основной базой для выписывания накладных и ТТН'ок, а все остальное вторично!
Балансировка (хотя бы ручная) нужна всегда.
В том то и дело что у вас ручная балансировка, я же приводил варианты с автоматической.
Да и ключевые проблемы уже были озвучены, решений так и не услышал.Про решение, я писал выше, если они вам не подходят по каким-то религиозным убеждениям, то это полностью ваще дело, я не собираюсь переубеждать, в техническом плане они работают, кстати недавно на хабре даже уже была прекрасная статья про международный call центр реализованный по схемам приводимым выше, к сожалению с ходу не нашел!
Вы можете сами выбирать какой режим для регистрации вам нужен
То есть телефон способен загрузиться в первый раз полностью автоматически, без участия пользователя?
бранч=филиал, зачем 500 достаточно 1 в HA
Вы неправильно поняли. Я говорю, что бранчей (филиалов) — 500. Еще раз: в каждый ставим по астериску?
в России много промзон в которых нету даже обычных FXO линий и да там применяются GSM шлюзы.
Обычно с каналами бывают проблемы. Один провайдер-монополист и, следовательно, никакого резервирования.
Но чтобы хотя бы Е1 не могли дотянуть — это странно.
Однако — какая разница? Пусть будет GSM шлюз. Надо в отсутствие каналов пустить звонки на него. Вот такое вот вполне ентерпрайсное требование.
В том то и дело что у вас ручная балансировка, я же приводил варианты с автоматической.
С введением отдельной переменной? Неинтересно. Зачем ставить что-то перед регистрарами? Пусть телефоны сразу на них регистрируются.
Про решение, я писал выше, если они вам не подходят по каким-то религиозным убеждениям
Убеждения вполне прагматические. Вы ведь до сих пор не можете понять, что бывают и крупные компании, и им нужна нормальная телефония :)
недавно на хабре даже уже была прекрасная статья про международный call центр реализованный по схемам приводимым выше
Это?
(на хабре надо искать через гугл)
«распределённый отказоустоичивый колл-центр на >500 операторов»
Детский лепет какой-то. У нас столько операторов на одной площадке сидит, а площадок несколько. И обработка вызовов вовсе не является основной сферой деятельности конторы.
А внутренние заказчики — очень требовательные ребята. Есть огромный список требований с системам статистики, звукозаписи, IVR и тому подобному.
Однако, выше в habrahabr.ru/post/148031/#comment_5002049 я уже просил не совершать глупейшую ошибку и не сравнивать внутреннюю корпоративную телефонию с контакт-центром, это — принципиально разные вещи. У той же циски под колл-центр идет совершенно отдельная линейка продуктов, с которыми я вообще ни разу не сталкивался, потому обсуждать их не готов.
То есть телефон способен загрузиться в первый разДа именно так, можно комбинировать разные варианты.
Еще раз: в каждый ставим по астериску?
Asterisk ставится туда, где нужна автономная работа, зависит от количества абонентов и стабильности каналов. Если канал стабилен и позволяет пропускать пиковый трафик телефонии+служебный, то можно отправлять на sip proxy
Но чтобы хотя бы Е1 не могли дотянуть — это странноЕсть места куда провайдеры не хотят заходить особенно промзоны, так как много накладных расходов из-за шальных крановщиков и ямокопателей. Приходится делать радиоканалы, и ставить тот же asterisk заворачивая его в IAX trunk + jitter буфер. E1 cейчас вообще умирает(много накладных расходов), тот же TTK предпочитает выдавать сразу SIP поток.
У нас столько операторов на одной площадке сидит, а площадок несколько
В том то и дело что сделать на одной площадке не проблема, а вот сделать балансировку между площадками, уже серьезно, заметьте я пиши именно БАЛАНСИРОВКУ, не резервирование!
я уже просил не совершать глупейшую ошибку и не сравнивать внутреннюю корпоративную телефонию с контакт-центром
Я особо не сравнивал, просто зачастую они пересекаются, но опять же внутренняя корпоративную телефония гораздо легче в реализации того распределенного call-центра.
Вы не компетентны по вопросу Digium телефонов.
Можно настраивать эти телефоны непосредственно с PBX.
Выбираете из списка мак-адрес, и указываете добавочный в системе. Полный автопровиженинг. Заливаются контакты, номера быстрого набора, прошивка аппарата, лого и т.п.
Можно настраивать эти телефоны непосредственно с PBX.
Выбираете из списка мак-адрес, и указываете добавочный в системе. Полный автопровиженинг. Заливаются контакты, номера быстрого набора, прошивка аппарата, лого и т.п.
«Вы» — имелось ввиду обращение к jDima
Если канал стабилен и позволяет пропускать пиковый трафик телефонии+служебный, то можно отправлять на sip proxy
Но зачем лишние звенья? Неужели никак нельзя общаться сразу с регистрарами?
а вот сделать балансировку между площадками, уже серьезно, заметьте я пиши именно БАЛАНСИРОВКУ, не резервирование!
На авайке реализовано. Как я уже говорил, в коллцентровое направление циски не углублялся, там иной софт используется, но я абсолютно уверен, что CUCCE так может.
Но вы так и не осознали простейший термин «резервирование». А оно всегда подразумевает откладывание какого-то ресурса в сторонку, дабы воспользоваться им, когда он потребуется. Если же запросы распределены по всем нодам кластера, то это и есть полноценная балансировка.
Пример. Если я на своем ACE создам правило вида «запросы с четных адресов кидать на первый сервер фермы, а с нечетных — на второй», то это балансировка. Если я исключаю ACE, и на самих клиентах скриптами прописываю «если у меня четный адрес, то хожу на первый сервер, если он умер — на второй», то это тоже балансировка. А если клиентов много, и распределение можно задать одним мизинцем, без всяких промежуточных звеньев вроде балансировщика, то эта балансировка куда предпочтительнее таковой с посредником.
Ну и все-таки — как там обстоят дела с фейловером телефонии в маленьком бранче с отвалившимися каналами? Не нужно, потому что астериск так не умеет? :)
Вы не компетентны по вопросу Digium телефонов.
Базара нет — не работал и надеюсь никогда не работать с ними :)
Исходя из представленного описания, вряд ли всему этим настройками будет заниматься руководитель, бухгалтер и пару менежеров, на которых, судя по Вашему описанию, ориентирована данная система. Все равно есть специфика с регистрацией SIP-транков и маршрутами звонков. Пока общая культура даже очень малого бизнеса не позволяет многим компаниям использовать такого рода решения. Для них слово «SIP» и «VoIP» уже является ругательством.
Это скорее для технически подкованного специалиста. И как обстоят дела с безопасностью? Информирование об апдейтах есть? fail2ban не решает всех задач, связанных с безопасностью в voip-каналах.
Это скорее для технически подкованного специалиста. И как обстоят дела с безопасностью? Информирование об апдейтах есть? fail2ban не решает всех задач, связанных с безопасностью в voip-каналах.
Ну куда уже проще? Вбить логин / пароль / IP адрес в настройках SIP провайдера и указать в правилах маршрутизации, чтобы все вызовы уходили именно на него.
Я хочу сказать, что система вполне доступна новичкам, но тем не менее предлагает продвинутые функции, которые позаимствовала от платных собратьев. Разумеется нужно потратить больше времени, чтобы их реализовать. А как по другому, все таки это корпоративный сервер телефонии, как бы это гордо не звучало.
Я хочу сказать, что система вполне доступна новичкам, но тем не менее предлагает продвинутые функции, которые позаимствовала от платных собратьев. Разумеется нужно потратить больше времени, чтобы их реализовать. А как по другому, все таки это корпоративный сервер телефонии, как бы это гордо не звучало.
Лично я — против SwitchVox. Причина проста до безобразия.
Суть и естество Астериска — быть свободным и открытым. С ним чувствуешь, что у тебя развязаны руки. Клиент тебе рисует бизнес-задачу, и на каждую строчку текста клиента у тебя в голове уже есть строчка диалплана.
А тут — ты повязан по рукам и ногам, не выпускаешь из рук калькулятора.
По внешнему виду — ничуть не удобнее Аскозии или Керио Оператора.
Суть и естество Астериска — быть свободным и открытым. С ним чувствуешь, что у тебя развязаны руки. Клиент тебе рисует бизнес-задачу, и на каждую строчку текста клиента у тебя в голове уже есть строчка диалплана.
А тут — ты повязан по рукам и ногам, не выпускаешь из рук калькулятора.
По внешнему виду — ничуть не удобнее Аскозии или Керио Оператора.
Не путайте холодное и горячее. SwitchVox не будет работать в качестве IVR-сервера для контент-провайдера. Он так же не решает задач операторского масштаба. Это просто морда для небольшой АТС за небольшие деньги. Когда всех задач — добавить пользователя и смаршрутизировать ему звонок. Все.
Астериск с AEL — это как PHP. Можно решить почти любую задачу. Но саппорт будет очень дорогой. Потребуется специалист. А SwitchVox максимально упрощает вполне конкретную задачу. Точка.
Астериск с AEL — это как PHP. Можно решить почти любую задачу. Но саппорт будет очень дорогой. Потребуется специалист. А SwitchVox максимально упрощает вполне конкретную задачу. Точка.
IVR сервер для контент-провайдера? Неправильное сравнение. Switchvox SMB позволяет это делать.
Если Вы про платные версии Switchvox, то калькулятор Вам понадобится только один раз. И то, чтобы перемножить кол-во юзеров на 50$, калькулятор не понадобится, все понятно и прозрачно.
Все функции Switchvox предоставляются сразу, без последующих доплат. Каждый хочет обладать голосовой почтой? Пожалуйста. Получать факс в виде документа на личный кабинет? Нет вопросов. Пользоваться панелью оператора, и управлять звонками мышкой? Welcome!
И так, абсолютно для каждого пользователя в системе.
Сравните с той же аваей, уж они умеют «развести» конечного пользователя в будущем ;)
Все функции Switchvox предоставляются сразу, без последующих доплат. Каждый хочет обладать голосовой почтой? Пожалуйста. Получать факс в виде документа на личный кабинет? Нет вопросов. Пользоваться панелью оператора, и управлять звонками мышкой? Welcome!
И так, абсолютно для каждого пользователя в системе.
Сравните с той же аваей, уж они умеют «развести» конечного пользователя в будущем ;)
А как обстоят дела в Switchvox с синхронизацией с AD общей адресной книгой, какой функционал у панели оператора?
Синхронизации с AD нет. Зато есть синхронизация с другими Microsoft продуктами: Приложение под Windows, Outlook, Word / Excel.
Как я уже сказал, веб-панель (называется в системе Switchboard) позволяет управлять звонками с помощью мыши. Звонок приходит — появляется возможность перетянуть его на коллегу, ему в голосовую почту, на мобильный, парковку, конференцию и т.д.
Очень красиво визуализировано на сайте Digium. Interactive Demo
Как я уже сказал, веб-панель (называется в системе Switchboard) позволяет управлять звонками с помощью мыши. Звонок приходит — появляется возможность перетянуть его на коллегу, ему в голосовую почту, на мобильный, парковку, конференцию и т.д.
Очень красиво визуализировано на сайте Digium. Interactive Demo
Возможности пользователя ограничены возможностями веб-интерфейса. Плюс к тому же, он еще и платный.
Yet another IP PBX.
Yet another IP PBX.
Дык, изначально надо было проектировать правильно.
zepps, не совсем так.
Возможности пользователя ограничены WEB интерфейсов, верно.
Но при необходимости можно дать пользователю еще один интерфейс, самописный, открытый в соседнем табе, где через API будет реализована нужная тема. API неплох, хотя и не идеален.
Т.е. более или менее все расширяемо, несмотря на закрытость.
> Плюс к тому же, он еще и платный.
Ты считаешь, это плюс? :-))
Возможности пользователя ограничены WEB интерфейсов, верно.
Но при необходимости можно дать пользователю еще один интерфейс, самописный, открытый в соседнем табе, где через API будет реализована нужная тема. API неплох, хотя и не идеален.
Т.е. более или менее все расширяемо, несмотря на закрытость.
> Плюс к тому же, он еще и платный.
Ты считаешь, это плюс? :-))
возможности _пользователя_ всегда должны быть ограничены, гуй не должен ограничивать возможности _администратора_.
Сейчас уже нет необходимости разбираться с астером, но в свое время из коробочных решенийй самым привлекательным был elastix. Там и встроенные настройки неплохие и при желании всегда можно было ручкамт подпилить, если что-то нестандартное требовалось. Так что если кто будет выбирать, обратите внимание на elastix. И, кстати только там я нашел встроенную поддержку ooh323.
Даешь бесплатную IP АТС народу с идеальной архитектурой!
Кто со мной? :-)
Кто со мной? :-)
Подскажите, для этих целей подходит?
Подходит, но Вы готовы держать целый сервер x86 для IP-АТС? После установки дистрибутива Switchvox Home, у Вас не будет рута.
Хотя, как вариант, устанавливать на машину с виртуальными серверами.
Хотя, как вариант, устанавливать на машину с виртуальными серверами.
Я в любом случае дома буду ставить какой-либо сервер для файлопомойки. С функционалом уже определился
— файлопомойка. (Фильмцы, семейные фотки-видео)
— DLNA
— Веб сервер
— Возможно видеонаблюдение
— Телефония.
— что-то ещё. Люблю на досуге поковыряться.
Так вот. Как я понял, чистый астериск нормально уживется с остальными фишками сервера. А вот можно ли (без использования виртуального сервера) совместить с Switchvox — пока не ясно.
— файлопомойка. (Фильмцы, семейные фотки-видео)
— DLNA
— Веб сервер
— Возможно видеонаблюдение
— Телефония.
— что-то ещё. Люблю на досуге поковыряться.
Так вот. Как я понял, чистый астериск нормально уживется с остальными фишками сервера. А вот можно ли (без использования виртуального сервера) совместить с Switchvox — пока не ясно.
Чистый астериск от такого виртуального соседства в рамках одной хост машины будет заикаться и квакать ;-)
В том плане, что он ресурсы жрет? Если сервер помощнее собрать, с ssd для астериска?
Вы вводите человека в заблуждение, при домашнем применение у него будет максимум 1 звонок, это смешная нагрузка(Asterisk скомплиленный на asusWL500GP может держать 5 параллельных звонков, при этом прогоняя через себя трафик трафика и раздавая wi-fi), проблема может быть с полосой пропуская для sip трафика, для этого надо настроить приоритезацию трафика и не будет проблем!
А в сравнении с oktell, который не такой дорогой (сравним со стоимостью хардварной ip атс) что лучше в итоге? Я лично выбрал хардварный вариант, потому что нужно было срочно и самостоятельно развернуть офис на пару человек. Потом понял что мне для этого не нужна была АТС, хватило бы возможностей IP телефона Siemens Gigaset и, при необходимости, потом купить Oktel и на него этот телефон повесить через рабочий компьютер.
Современная IP-АТС для обычного офиса до 100 человек должна стоить не более 200$ со всеми потрохами :-)
P.S. Под потрохами понимается embedded server + софт.
P.S. Под потрохами понимается embedded server + софт.
DLink что-то такое сделал с Linux + asterisk на борту.
Хде?
Знаешь, Макс, не хочу показаться голословным, но точно не скажу. На конференциях OSDN-2008..2010 об этом рассказывал Олег Лещинский, который до недавних пор работал в DLink Ukraine.
Можешь поднять архивы OSDN, они вроде бы доступны.
Можешь поднять архивы OSDN, они вроде бы доступны.
dlink.ru/ru/products/8/814.html
Но оно уже не поддерживается, вроде бы.
Но оно уже не поддерживается, вроде бы.
У кого-нибудь получилось сконфигурировать eth1 в статик, в вэбке доступна лишь eth0?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Switchvox Home — IP-АТС для очень малого бизнеса