В ss7 есть требование когда сигналка пустая передавать не флаг а FISU (fill in signal unit). Это всё (и кое что ещё - т.н. "фазирование" линка) прописано в MTP протоколе.
Соответственно на рынке полно дорогого железа, в котором MTP полностью или частично исполняется на плате.
Эксперименты показывают, что с современными процессорами это совсем не нужно - sifira ag сделали реализацию, которая работает целиком в userspace (включая HDLC и MTP) - см chan_ss7.
Для пущей уверенности mtp2 можно поместить в ядро - как раз в прерывание в котором буфер на отправку готовить - тогда появляется большая свобода в написании user parts SS7 (хоть на питоне пиши).

Так что, вкратце, ничего делать не надо - кроме предоставления opensource драйвера, в который можно вставить соответствующую часть.

В принципе для иллюстрации этого можно уже сейчас написать протокол mtp2 с binderным интерфейсом и посмотреть как это будет выглядеть. Но это позже :)

Насчёт кроссконнекторов. Второй абзац - я не разобрался до конца, спасибо. И про проблему у меня пока не было возможности выяснить.
Идея такая. Для сохранения процессора и входных каналов я беру порт tau32 и делю его на два канала. Один хдлц 16 таймслот, другой - clear channel все остальные. Выше по стеку я потом второй канал разделяю на отдельные таймслоты по байтам.

В поределённый момент времени мне нужно запихнуть б-канал обратно в тот же поток откуда он пришёл. То есть я установил ещё одно соединение, у меня получилось 2 б-канала заняты, и мне нужно их друг с другом соединить.
Допустим, я готовлю матрицу кроссконнекта и её активирую. Что у меня произойдёт с каналом с которым я работаю с телефонией? Туда начнёт поступать меньше данных - таймслоты оттуда ведь убежали?

С точке зрения простоты реализации лучше было бы если бы после активации кроссконнекта в соответствующих байтах шли нули или любой мусор (размер порции данных соответственно не уменьшался) и вообще она всегда была кратна mtu таким образом чтобы в mtu помещалось не больше сегодняшнего zt_chunksize (8 байт) - из соображений эходава.

Возможно, оно так уже работает - я к сожалению ещё не добрался до ddk и кросс-коннектов ;(

Со стороны астериска есть возможность сообщить драйверу канала что 1) эти два канала одного типа нужно забриджить 2) астериск не хочет оставаться в media path. В zaptel на это дело даже функция есть соответствующая. Как раз для этого я кроссконнектить таймслоты и собрался.

Насчёт каналов HDLC - для таких вещей как СМС-центр или IN-платформа нужны как раз каналы, в каждом таймслоте отдельный сигнальный линк идёт ... в принципе, можно и программно это сделать, тем более что это будет очень редкое применение :)

Насчёт эхоканселера - поэкспериментируйте с программным подавлением. У вас в tdmoip какой проц? C3 ? или geode?