Мне кажется, что не нужен :-)
1) Он "утяжеляет" систему (в случае с Apache + PHP / Perl или другим фреймворком).
2) Он ограничивает возможности той бизнес-логикой, которую заложили авторы.
Клиенту нужен не WEB интерфейс, а способ управления своей АТС. Они не хотят завесеть от одного поставщика.
У панаса сколько лет не было другого интфрейса, кроме консольного кабеля и страшных команд?
Я думаю, что если написать хорошую документацию админа, то это будет решением.
А вы как думаете?

P.S. Кстати, отсутствие WEB интерфейса на руку интегратору. Теперь вопрос стоит ребром - либо читай мануалы и разбирайся, либо обратись за платной поддержкой. При наличии интерфейса есть соблазн потыкать мышкой :-)

Полагаю, нужен разумный компромисс.
1а) как админу, мне намного проще делать 80% вещей напрямую командными файлами: рулить маршруты, потоки и делать приложения.
1б) в то же время заводить пользователя во freepbx ручками - гимор тот еще:
- прописать в sip.conf
- прописать в ext-local
- прописать в БД всякие там callerid и прочее
- прописать в MYSQL емайл и прочие опции
- сделать кнопку в FOP (та еще засада)
т.о. пользователя я завожу во freepbx. А редактировать удобней в phpconfig, а не в mc. (хотя некоторые из моих знакомых юзают VI, а с mysql работают только через CLI)
2а) удобно открыть cli и настрочить команду show channels. или другую.
2б) неудобно после sip show peers лезть в браузер и открывать ручками веб интерфейс девайса для настройки. Удобно, когда открываешь страничку модуля freepbx, а там список всех телефонов, их статусы, контексты, пинги, опции и ссылки на вебинтерфейсы. кликаешь мышкой и получаешь нужное.
3а) админство циски с командной строки - дело хорошее, но заумное. даже настройка телефона с веб интерфеса - уже прогресс. уж с двумя РАР2 можно српавиться.
3б) но у нас же бизнес, верно? а если телефонов не 3 а в 100 раз больше? вот это превращается в кошмар. Удобно приехать к клиенту на газели, груженой телефонами, достать сканер штрихкода и разом прописать все телефоны. удобно и быстро. время - это деньги.
4а) правильно организованные конфигурационные файлы править удобно.
4б) чтобы клиент это делал сам нужно потратить много времени на его обучение:
- как завести пользователя (см. выше)
- как сделать ring группу
- как настроить followme
- как определить переадресацию
- как конечный (не админ) пользователь может сменить свои настройки, послушать голосовую почту?
- как прослушать записи разговоров
- как посмотреть, кто сейчас разговаривает?
- как настроить телефон/шлюз?
5а) платная ТП это хорошо, имеется стабильный ежемесячный доход. когда клиентов становится много, и половина из них не рубит в * ничего, они просто затрахают с просьбами " у нас добавилось еще 5 абонентов, придите и настройте, мы же платим! Высокооплачиваемы персонал срывается с места и ломится через пробки настраивать 5 телефонов. а чтобы упеть с новыми проектами - нанимаем еще больше людей. как следствие - превращение компании-интегратора в службу техподдержки. такое часто случается с интеграторами традиционных атс.
5б) платная ТП это хорошо, но клиент платит только за решение проблем. нет проблем - не нужна ТП. Заведение юзеров, настройка очередей и прочего - все клиенты делают сами. У меня например, кучка клиентов :), но они меня особо не напрягают и пока справляюсь в одиночку. Есть мануалы, куда тыкать мышкой, они и тыкают, меня не трогают. но за ТП платят.
6а) удобно держать список телефонов компании на бумажке.
6б) когда список начинает занимать 5 листов, это начинает напрягать. выход - интерактивная телефонная книга, которая еще и собирает инфу с других филиалов.

можно много понаписать в таком духе, но когда речь идет о сотнях абонентов, поддерживать все вручную крайне тяжело.
По большому счету MYSQL, PHP, APACHE ресурсов не кушают, все процессы на маленьких системах, кроме * обычно спят, а на больших - мощи хватает чтоб держать 100 сайтов, что там говорить об одном freepbx.

Важен и еще один момент: ЮЗАБИЛИТИ. да-да, большими красными буквами в офисе интегратора. Есть много хороших АТС, насыщенных функционально. Ну что с того? 80% функций использует 20% пользователей. Все потому, что НЕУДОБНО.
Можно долго спорить на тему linux и windows, но Биллу Гейтсу нужно отдать должное: он сделал компьютер УДОБНЫМ. делает удобным и сейчас. Причем удобным не только для юзеров, но и для админов.

Мы используем Freepbx со своими самописными модулями, повышающими удобство работы как конечного пользователя, так и админа. Для клиентов это как красная тряпка. Показываешь Freepbx, говоришь "вы все будете делать сами и не зависеть от нас" и все - клиент твой. Ты ставишь сервак, втыкаешь телефоны и идешь к следующему клиенту, зарабатывать бабло. "Поставил и забыл". Для клиента это настоящая независимость от поставщика.

litnimax, не ставь в пример панас. он убог функционально. Мир изменился. Сейчас век usability. и потом, положа руку на сердце, я изучил твой extension.conf. функционально слабо :(. диалплан freepbx намного сложней и интересней. Будем надеяться, что и ты достигешь такого уровня, но в одиночку тяжело будет.

Один из моих клиентов говорит про какие-либо ИТ решения так: "умнож все на 10 и представь, сколько будет проблем" (это он про филиалы, телефонию, сервера, клиентские машины, маршрутизаторы). А если в организации не один VoIP сервер, а 50? вот тут начинается веселье. Сейчас пытаемся переделать freepbx для монолитного управления десятками серверов.

Как-то к этому клиенту зашел представитель микрософта (клиент - крупный продавец ихнего ПО), увидел вебинтрефейс, что сваливаются сообщения о пропущенных звонках, где кликнул - позвонил, увидел ARI, Spark со статусами звонит/не занят и сказал: "микрософт обещает это токо в 2009 году. и то не все"

что-то я опять пографоманствовал

Нужна Веб-морда для пользователей не админская.
litnimax

1) Он "утяжеляет" систему (в случае с Apache + PHP / Perl или другим фреймворком).

Если это не большая система то не проблемма. А если большая то Веб морда должна быть отдельно на другом серваке.
PS: Почти польностью согласен с switch.

Это нужно в "законченных решениях", интересно заказчику(пользователю) ... . Для специалиста - это не нужно. Да и через интерфейс не сделаешь всего того, что позволяет командная строка.

Через IVR. Админ использует database show для просмотра что они там себе наконфигурировали, а пользователи звонят на всякие служебные IVR для установки номеров CF, активации-деактивации, установки времени dial timeout, и многих других настроек. Ну а вот почту, да, надо админа просить поменять :-)

как прослушать записи разговоров

А вот это я еще не придумал :-( Прошу продолжить обсуждение в тикете.

как посмотреть, кто сейчас разговаривает?

Телефон с BLF? Решение?

они просто затрахают с просьбами " у нас добавилось еще 5 абонентов, придите и настройте, мы же платим!

А зачем приходить? Это же не панас. SSH и 40 мин работы.

когда список начинает занимать 5 листов, это начинает напрягать. выход - интерактивная телефонная книга, которая еще и собирает инфу с других филиалов.

А это че такое? Может в LDAP загнать?

Для клиентов это как красная тряпка. Показываешь Freepbx, говоришь "вы все будете делать сами и не зависеть от нас" и все - клиент твой.

А я говорю: "WEB интерфейса не будет. Вместо этого будет документация администратора, и платная поддержка при нежелании самому рулить". И ничего, не уходят. Наши люди не привыкли сами рулить АТС :-)
Ты правильно говоришь про то, что не используют фичи так как неудобно! Система должна просто работать, и делать это удобно. А за изменение конфигурации при необходимости можно и заплатить.

litnimax, не ставь в пример панас. он убог функционально. Мир изменился. Сейчас век usability. и потом, положа руку на сердце, я изучил твой extension.conf. функционально слабо :(. диалплан freepbx намного сложней и интересней. Будем надеяться, что и ты достигешь такого уровня, но в одиночку тяжело будет.

Скорее всего, в репозитарии лежал старый, залитый для проверки репо. Погляди extensions.conf и extensions_services.conf. И вот что эти два файла дают пользователю.
Этого достаточно среднему клиенту. Я сейчас собираю по всем инсталяциям разные кирпичики, которые заношу туда. Через месяц посмотрим, как продвинусь. А если с твоей или другой стороны будут конкретные советы, что добавить, будет еще лучше.

что-то я опять пографоманствовал

Большое спасибо :-)

У *NIX систем до сих пор основной инструмент - CLI. А юзеру можно некоторые вещи и в легкий интферфейс вынести. Получается, на AJAM надо делать не админку, а юзерский интерфейс!

Кстати, а для просмотра звонков активных можно и Digium GUI использовать! И для выполнения команд. WinSCP + HTTP Digium GUI - вот тебе интерфейс админа (хотя я за SSH).

Действительно, интерфейс от Digium для облегченного "администрирования" вполне подходит.
Давно кстати его не щупал, должен уже быть в "форме". Нужно посмотреть. Качаю ...

Для себя давно определился с интерфейсом - tty! (очень функционально ... ) :)

Не думаю, что его достаточно высушили. Но ты все же пощупай :-)
Аккуратно с ним. Бэкап конфигов сделай.

Я его только смотрю, определяю степень готовности для предложения заказчику ... Самое большое, что я делал через ГУЙ (давно) - заводил юзеров. А когда их - сотня, другая то здесь никакой ГУЙ не спасет. Bash в руки и вперед ...

litnimax

Через IVR. Админ использует database show для просмотра что они там себе наконфигурировали, а пользователи звонят на всякие служебные IVR для установки номеров CF, активации-деактивации, установки времени dial timeout, и многих других настроек. Ну а вот почту, да, надо админа просить поменять :-)

Мне кажется, что во многих случаях в маленьких организациях есть один человек который выполнять все функции (заправка картриджей, установка винды и т.д.). И в большинстве случаев он не знает что такой SSH, а проводить долгую тех. учебу просто гемор. Для этого нужен Web.