Nir Simionovich wrote:
Hi Steve,
Hmmm.... lets see, NOT !
In Israel the connection of the E1 at the wall socket is not an RJ45, but
a British Connector.
I'm fully aware of the fact that the connection of E1 on the Router/Server
side are 1,2 and 4,5 as pair for TX and RX. Steve, my question may sound a
little stupid, but
here is my current setup.
1. The cable connecting from the wall to the server is a flat 4 wire cable,
used by our Telco.
2. The cable also has a noise filter on it, the same one used for Data
Connection by our Telco.
3. The cable is around 60cm long, which means that it's just the right
length.
4. The length of connections from my wall socket to the E1 Grouping device
is around 30 meters,
well within the specs.
Maybe that 30m cable is paired incorrectly.
However, what you said poses a really interesting question. Although I'm a
CCNA, I couldn't find an answer to it. As far as I know, E1 is supposed to
be an un-balanced
medium, which suggests that there is no significance to the order of wires
within the pair. Question is, is this true? If not, this might be the cause
of problems. However, the line works fine
from my side, and I due to the fact that I can't see any errors on my side
(actually, I don't have an
ability to see errors), I'm a bit at a loss.
Er, unbalanced means there _is_ significance in which way round you wire
things. Balanced means there is not. In the case (or cases) of E1 you
can get either. If you have is supplied on TP is should be balanced. On
co-ax it will be unbalanced. You have TPs, so your is balanced. However
this is entirely irrelevant. E1s and T1s can both tolerate reversal of
the data.
Now, here are the symptoms according to our testing (The Telco and
Myself):
1. We've managed to bring down the number of errors to around 60 per hour.
This was achieved by changing the default ToneZone in zaptel.conf to FR,
while before it
was set to UK. That's why I believe that the problem resides zomewhere
in the zonedata.c file.
I don't think so. zonedata.c only affects the data content of the E1
stream. Your CRC4 errors mean you have bit errors in the stream itself.
Changing the tone zone has probably just changed the data on the line to
something more benign that is giving less trouble.
2. When errors go up, I can create outgoing calls, but incoming calls
receive busy signals on all PRI channels.
3. The errors seem to go away without any specific reason. The only common
denominator
for reseting the errors is, performing several resets to the zaptel
driver and performing a
reset to the Telco System 12 connection card. And only after a variable
number of resets,
everything works fine again.
4. It can work fine for a couple of days, and then start making hell.
Problems tend to come and go when things are marginal. It sounds like
crosstalk, weak signal or some such PITA. With T1s you can get quirky
problems like this with AMI vs B8ZS mismatches. E1 is always HDB3, and I
can't think of any other optional things which give almost but not quite
right results.
Regards,
Steve
_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
