Наша система использует Астериск только как коммутатор на ровне с целым рядом другого оборудования. GUI используем только свои. Единственное, что приходится тянуть из Астериск - sip.conf. Эта задача тоже решается на нашей стороне.
В общем смысле различного рода планы наборов (dialplan) оказываются не при делах. Используем AMI для реализации точки управления и построения софтсвича в свой протокол управления сигнализацией и коммутацией. Для поддержки внутрисистемных рабочих мест (и файлового сервера центрального репозитария звукозаписей) возник вопрос реализации каналов без сигнализации на основе RTP. Покопавшись в интернете, каких-нибудь немного подходящих решений я не обнаружил. По этой причине инициировал разработку соответствующего канального драйвера.
По этой причине вскочили 2 вопроса:
1. Может я чего-то не знаю о существующих реализациях данной темы?
2. Насколько это актуально для народа?

вопрос реализации каналов без сигнализации на основе RTP?

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

Через месяц надо вспомнить ситуацию, выяснить кто перенаправил, или на кого перенаправили - задача! Так что трудно без сигнализации.

Эту задачу решает наша система СОРМ, которая никак не связана планом набора, по которому пришел звонок. Передача вызова между операторами или абонентами нашего сценария миниАТС осуществляется не сигнальными трансферами, а внутренним протоколом оповещения, вообще говоря, связанными с Астериском только канальной абстракцией. Коммутируется всё при помощи приложения MeetMe. Ещё одно применение, которое предполагается для этих каналов - организация транзитных соединений между сегментами оборудования: другими Астерисками или оборудованием, управляемым нашим софтсвичем (гибридизация).

Ну тогда ответы мне кажутся простыми:
1. Очень возможная вещь.
2. Народ не сможет реализоваться такими каналами, поскольку у вас свой протокол управления сигнализацией и коммутацией (или вы тоже его планировали в открытый доступ?).

По поводу возможности - не сомневаюсь - уже имеется рабочий прототип.
Я просто знаю некоторые системы, которые реализуют логику сценария не на dialplan, а на AMI или AGI. Есть достаточное количество файловых хранилищ, которые позволяют получить доступ к ресурсам по RTP (AMI+RTP=достаточно навороченная удаленная говорилка, которых большая тьма развелось). Можно это всё залудить по MGCP, но там свои косяки.
Наш протокол, который над AMI торчит уж точно для народа никакой практической ценности иметь не будет.
Там такая архитектура (нет никакого секрета):
[сценарии]~[сервер автоматики]<-(вн.прот1)->[hard сервер]<-(вн.прот2)->[softswitch]<-(спец. протокол)->[сегм.оборуд]
[бланки]~[рабочие места]<-----(вн.прот1)------^
сценарии-логика, тарификация
бланки-логика, тарификация
сервер автоматики-плагины, стытки с оборудованием и АСР
рабочие места-плагины, стытки с оборудованием и АСР, дополнительные функции управления гарнитурой
hard сервер-интегратор служб (автоматик, рабочих мест), интегратор сегментов оборудования
softswitch-конвертер протоколов управления (вн.прот2)и (спец. протокол)
сегм.оборуд-коммутационное оборудование (в том числе Астериск)
(вн.прот1) - протокол взаимодействия сервисов системы с оборудованием
(вн.прот2) - протокол взаимодействия с сегментом оборудования
(спец. протокол) - специфический для оборудования протокол управления (в случае Астериска - AMI)