[asterisk-dev] Switching unrestricted digital calls

[Klaus Darilion]

Am 03.11.2010 07:08, schrieb Pavel Troller:
> Dear Klaus,
>    I was afraid of something like this. It may be a serious drawback, preventing
> usage of Asterisk in some environments, which are now covered by commercial
> devices only.

Yes, it is.

>    For example, there are OneAccess CPEs on the market, which are simple
> multi-purpose boxes, scaled from a few POTS/BRI up to many E1s on the TDM side.
> They can handle unrestricted digital calls, and they do it using a special
> "clear-channel" codec, which can be configured in the codec list exactly as
> other ones, one can even choose a ptime (10 - 30 ms). This codec is selected
> automatically for all the bearer types, which require unrestricted digital
> transmission. The payload ID in RTP stream can also be specified (similarly as
> for other codecs or DTMF etc.).

Yes, "clear-channel" is rather common. I remember I once had a patch for 
"clear-channel" for Asterisk - can't find it anymore.

>    Together with clock recovery by another special RTP stream (patented
> technology of OneAccess), these devices are perfectly suited for full E1/PRI
> replacement purposes, when the customer requires legacy TDM service but there
> is no TDM connectivity available on their site.

For full E1 replacement IMO TDMoIP or TDMoE would be more suitable. But 
of course if only some channels should be forwarded then a 
"clear-channel" is needed.

>    I think that implementing idea of a "clear-channel" codec, which would
> ensure strict 1:1 data transmission without any transcodings, gain
> manipulations etc. would be a really good idea, and that it would not be so
> hard to write the code. And because Asterisk has to be a really flexible and
> universal switching platform, it would be really good to have such possibility
> in it...

I remember it was rather easy to add "clear-channel" to Asterisk core + 
chan_sip, but I was rather PITA for chan_dahdi and DAHDI (IMO lot of 
ugly codec handling).

So, all the best for your implementation.

regards
Klaus