> а в чём они конкретно brain, а в чём они damaged?Насчет того в чем там brain я не знаю -- сколько не силился, не нашел.
Если конкретнее:
- 8kHz. Только. G.722 идет нафиг
- 8bit. Только. Несмотря на возможность API верхнего уровня отдавать данные в 16-и битном виде, lowlevel API этого не позволяет принципиально
- API для транскодинга параллельное. Нет возможности сказать "я хочу от этого устройства G.729, и если оно его умеет -- пущай отдает именно его", данные от платки надо засасывать в G.711, потом запихивать назад, потом читать G.729. Это приемлимо только потому, что Digium не делает платки "все в одном", и делать такие платки другим совместимым с Asterisk образом не дают
И т.д.
А реализации SS7 штатной там, кстати, вообще нет. Будет на базе их же libss7 в 1.6, которое неизвестно в каком году выйдет (я бы ждал к осени... с учетом того что прошлый раз после заморозки понадобилось более полугода для выпуска, а пока ничего похожего на заморозку нет).
Для 1.4 есть кодек от Sifira http://www.seiros.ru/products/chan_ss7 который был мною слегка доработан напильником. А для работы с железкой тот же Yate использует тот же самый zaptel, который уже стал стандартном де факто.
Если кратко -- zaptel это ужас, летящий на крыльях ночи. Но для этой задачи больше никто не сделал решения лучше. Да, у Sangoma есть еще какое-то свое API, у Cronyx есть свое API. Но эти API никто кроме них не умеет :) А zaptel это все-таки стандарт де-факто. Хотя и без документации, который приходится изучать по кривому коду и через строчку ругаться.
Ну про то, что коллега уже находил баг в одном из дигиодиных драйверов с выводом в _чужие_ ioports (который остался незамеченым ранее, потому что этот вывод был вообще нафиг не нужен) я уже молчу.
Digium лучшие в своей сфере, если их сферу называть "телефония под Linux", но ни в коем случае не "системное программирование под Linux".
