[asterisk-dev] Switching unrestricted digital calls
Klaus Darilion
klaus.mailinglists at pernau.at
Mon Nov 1 12:16:50 CDT 2010
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
>
More information about the asterisk-dev
mailing list