Asterisk: дистрибутив с LDAP-интеграцией «из коробки»

А зачем? Не легче самому на debian/centos? Всё таки далеко не каждая инсталяция pbx предполагает использовать ldap, так что, думаю, врядли будет готовое что-то.

>все популярные solution'ы на базе Asterisk'а как-то деликатно или даже очень грубо обошли интеграцию с LDAP стороной
Мне добавить нечего :)

не каждая инсталяция pbx предполагает использовать ldap

плюсую. К тому-же если требуется LDAP то это уже скорее opensips, так как подразумеваются корпоративное использование и соответственно нагрузки. На Asterisk остаются второстепенные роли голосовых шлюзов и всяких voice-меню. Дважды наблюдал и участвовал в именно таких процессах - сначала перенос proxy/registrar с Asterisk`а и только потом LDAP.

p.s. Но и тут засада - кодеки, эхо-компенсация, генерация шума и прочие вкусности поддерживаются конечным оборудованием, но не Asterisk`ом; так что и как шлюз его тоже меняли при первой возможности.

плюсую. К тому-же если требуется LDAP то это уже скорее opensips, так как подразумеваются корпоративное использование и соответственно нагрузки. На Asterisk остаются второстепенные роли голосовых шлюзов и всяких voice-меню. Дважды наблюдал и участвовал в именно таких процессах - сначала перенос proxy/registrar с Asterisk`а и только потом LDAP.

p.s. Но и тут засада - кодеки, эхо-компенсация, генерация шума и прочие вкусности поддерживаются конечным оборудованием, но не Asterisk`ом; так что и как шлюз его тоже меняли при первой возможности.

Это именно у корпоративного клиента, а не ITSP. В двух словах можно подробности, если не сложно, какое оборудование использовалось и кто выполнял фукции «классической» АТС, если asterisk меняли при необходимости.

Она не предполагает только потому, что качество интеграции аховое, даже пароли нельзя использовать одни и те же в * и для nix-аккаунтов, я уж не говорю о том, что этот realtime модуль в принципе работает с LDAP неправильно, пытаясь в него записывать всякую временную муру.
Если бы интеграция была удобной или даже LDAP был основой для системы аккаунтов в *, то и для организации в 3 человека это было бы актуально

А какие преимущества видятся в организации на, скажем, 50 человек?

какое оборудование использовалось и кто выполнял фукции «классической» АТС, если asterisk меняли при необходимости

в одном случае меняли на Mera MVTS и голосовые шлюзы от D-Link. Функции внутренней АТС (для подключения аналоговых телефонов) играли DVG-2024S - у них большая плотность портов, и любимый телефонистами амфенол, просто сняли старую станцию и по её хвосту зашили новый. Внешние каналы - тоже на аналоговые шлюзы + H.323 от Корбины. IP телефоны все D-Link. За глюки телефонов получали нехилых п#%$лей от руководства, пока (через пару месяцев пока искали причину) оптом не заменили блоки питания.

во втором случае registrar+proxy переехал на софтверный (не коробочное решение) CentOS+opensips, шлюзы - оставшийся Aster, и D-Link`и (к шлюзам нареканий небыло), абонентские аппараты - разношёрстые, потому как сеть разнесена на несколько офисов.

зы Самая большая проблема на самом деле - факсы. Тюнинг шлюза к конкретному факсу занимал какое-то неприличное время более недели, пока не начинало таки работать как часы :(

Астериск впринципе не умеет использовать внешние источники авторизации, так что прозрачно его интегрировать в корпоративную среду построенную на Active Directory уже не выйдет. Можно держать схему диалплана в ldap вот только зачем это может понадобится?

В AD интегрировать наверное можно, если удастся прикрутить как-то схему. А слово Схема в данном случае нужно писать с двух больших букв, потому что она зело огромна и ужасна, существует во множестве вариаций и писалась в разное время разными людьми. В общем, это одна из самых геморройных схем, какие я когда-либо видел. Насчёт AD в корпоративной среде - слава Богу, не все его используют. Как сервер каталогов он совершенно никакой (производительность низкая, соответствие стандартам хреновое, конфигурационные данные и схема представлены в плохо читабельном формате), а как некая «чудесная» технология - ну извините меня, AD просто неотделим от Windows Server! И при чём здесь в этом случае LDAP вовсе непонятно, потому что с таким же успехом WinServer мог использовать MS SQL или даже вовсе текстовые файлики с кракозябликами.
В каталоге, реализованном на ПО от OpenLDAP или любом другом аналогичном серверном ПО, стремящемся соответствовать стандартам RFC, можно хранить аккаунты, очереди, диалпланы... На самом деле это просто здорово, что учётной записи пользователя можно добавить два objectClass'а, минимум необходимых атрибутов - и этот аккаунт будет ещё и номером телефона обеспечен. Другое дело, что из-за концептуальной проблемы с паролями самый большой профит - единый пароль на всё: разработчики realtime LDAP-драйвера почему-то считают, что * должен использовать свой парольный атрибут, что противоречит всей здравой логике каталогов, которые ставят по главу угла объекты (в совокупности составляющие информационную модель предприятия), а не те приложения, которые с ними работают.