[asterisk-dev] Switching unrestricted digital calls

[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.
  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.). 
  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. 
  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...
  With regards, Pavel

> Pavel, Asterisk does not handle digital data correctly (discussed several 
> times before), it always assumes a certain codec. Depending on the 
> interface card setting PRI/BRI-E1/T1/J1 it assumes either a-law or u-law as 
> codec. One possible problem is if Asterisk for some reason does transcoding 
> of the digital data. Use "core show channel ..." for the relevant channels 
> and check if they use different codecs (=transcoding). DAHDI makes the 
> situation even worse as transcoding may even happen in DAHDI modules.
>
> regards
> Klaus
>
>
>
> Pavel Troller wrote:
>> Hi!
>>   I was trying to google answers to my questions, but I didn't find anything
>> relevant, so I'm asking here.
>>   I'm developing an application, which needs to establish ISDN 64kbps
>> Unrestricted Digital call. These are coming from PRI ports (which are connected
>> to a legacy PBX) and they are going to either the same or another PRI port.
>>   There are no problems with signalling, but with the media. The terminal
>> devices (ISDN TAs) are having problems establishing and maintaining V.120 
>> connection.
>>   To find the problem, I used a BRI tester (connected instead of the ISDN TA)
>> and called to a single internal extension, which does just Echo(). A BERT test
>> was then started on the tester. And this is the most interesting thing there.
>> Depending on the BERT pattern selected, various results were obtained. Complex
>> patterns, like 2^15-1 or similar, showed permanent error rate about 4E-4. The
>> errors were distributed smoothly in time, every second appeared about 30
>> errors. Simple patterns, like 1:1, 1:3 or hex pattern 55 AA, were transmitted
>> with no errors during 4 consecutive hours.
>>   Of course the PRI E1 stream was perfectly synchronized. BERT towards a
>> loopback in the PBX into which the tester is connected is also error free
>> with any BERT pattern. Dahdi channels are configured with echo cancellation
>> disabled.
>>   Any hints ?
>>
>>   With regards, Pavel Troller
>>