asterisk.ru

Добрый день!
Помогите решить проблему.

Есть Asterisk 1.8.6.0 на 6-м ЦентОсе с ядром 2.6.18-274.7.1.el5 с платой Digium TE200 PCI-Express. Сервер HP Proliant DL120 G6

1 порт E1 идёт к провайдеру, второй в АТС Panasonic TD500

Проблема:
постоянно обрывается D канал с провайдером. Связь падает
[Apr 13 13:28:37] VERBOSE[3777] sig_pri.c: == Primary D-Channel on span 1 down
[Apr 13 13:28:37] VERBOSE[3777] sig_pri.c: == Primary D-Channel on span 1 up
[Apr 13 13:28:41] VERBOSE[3777] sig_pri.c: == Primary D-Channel on span 1 down
[Apr 13 13:29:18] VERBOSE[3777] sig_pri.c: == Primary D-Channel on span 1 up

Симтомы:
Постоянный треск в трубке при разговоре.
Периодически возникает ошибка [Apr 13 13:41:57] WARNING[3777] sig_pri.c: PRI Error on span 1: Received MDL/TEI managemement message, but configured for mode other than PTMP!
в pri логах постоянно запись типа
PRI Span: 1 -- Stopping T200 timer
PRI Span: 1 -- Starting T203 timer
Что это - я не знаю.

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER: подробнее

PRI Span: 1 -- Stopping T203 timer
PRI Span: 1 -- Starting T200 timer
PRI Span: 1 q931_hangup: other hangup
PRI Span: 1 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null, hold-state Idle
PRI Span: 1 NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null, hold-state Idle
PRI Span: 1
PRI Span: 1 < TEI: 0 State 7(Multi-frame established)
PRI Span: 1 < V(A)=25, V(S)=26, V(R)=16
PRI Span: 1 < K=7, RC=0, l3initiated=0, reject_except=0, ack_pend=0
PRI Span: 1 < T200_id=1, N200=3, T203_id=0
PRI Span: 1 < [ 00 01 01 34 ]
PRI Span: 1 < Supervisory frame:
PRI Span: 1 < SAPI: 00 C/R: 0 EA: 0
PRI Span: 1 < TEI: 000 EA: 1
PRI Span: 1 < Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
PRI Span: 1 < N(R): 026 P/F: 0
PRI Span: 1 < 0 bytes of data
PRI Span: 1 -- Got ACK for N(S)=25 to (but not including) N(S)=26
PRI Span: 1 -- ACKing N(S)=25, txqueue head is N(S)=-1 (-1 is empty, -2 is not transmitted)
PRI Span: 1 -- Stopping T200 timer
PRI Span: 1 -- Starting T203 timer
PRI Span: 1 Done handling message for SAPI/TEI=0/0
PRI Span: 1 t203_expire
PRI Span: 1
PRI Span: 1 > TEI: 0 State 7(Multi-frame established)
PRI Span: 1 > V(A)=26, V(S)=26, V(R)=16
PRI Span: 1 > K=7, RC=0, l3initiated=0, reject_except=0, ack_pend=0
PRI Span: 1 > T200_id=0, N200=3, T203_id=0
PRI Span: 1 > [ 00 01 01 21 ]
PRI Span: 1 > Supervisory frame:
PRI Span: 1 > SAPI: 00 C/R: 0 EA: 0
PRI Span: 1 > TEI: 000 EA: 1
PRI Span: 1 > Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
PRI Span: 1 > N(R): 016 P/F: 1
PRI Span: 1 > 0 bytes of data
PRI Span: 1 -- Starting T200 timer
PRI Span: 1
PRI Span: 1 < TEI: 0 State 8(Timer recovery)
PRI Span: 1 < V(A)=26, V(S)=26, V(R)=16
PRI Span: 1 < K=7, RC=0, l3initiated=0, reject_except=0, ack_pend=0
PRI Span: 1 < T200_id=1, N200=3, T203_id=0
PRI Span: 1 < [ 00 01 01 35 ]
PRI Span: 1 < Supervisory frame:
PRI Span: 1 < SAPI: 00 C/R: 0 EA: 0
PRI Span: 1 < TEI: 000 EA: 1
PRI Span: 1 < Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
PRI Span: 1 < N(R): 026 P/F: 1
PRI Span: 1 < 0 bytes of data
PRI Span: 1 -- Got ACK for N(S)=26 to (but not including) N(S)=26
PRI Span: 1 -- Stopping T200 timer
PRI Span: 1 -- Starting T203 timer

Конфигурация:

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER: cat chan_dahdi.conf

[trunkgroups]
[channels]
language=ru
context=from-zaptel
signalling=fxs_ks
rxwink=300 ; Atlas seems to use long (250ms) winks
;
; Whether or not to do distinctive ring detection on FXO lines
;
;usedistinctiveringdetection=yes

usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
;echotraining=800
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
immediate=no
faxdetect=incoming

group=1

group=0
context=from-comstar
switchtype = euroisdn
pridialplan=unknown
resetinterval=100000000
signalling = pri_cpe
channel => 1-15,17-31

; Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" HDB3/CCS
group=1
pridialplan=private
prilocaldialplan=private
overlapdial=yes
facilityenable = yes
context=from-my-internal
switchtype = qsig
signalling = pri_net
channel => 32-46,48-62

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER: cat /etc/dahdi/system.conf

# Autogenerated by /usr/sbin/dahdi_genconf on Sun May 29 16:30:33 2011
# If you edit this file and execute /usr/sbin/dahdi_genconf again,
# your manual changes will be LOST.
# Dahdi Configuration File
#
# This file is parsed by the Dahdi Configurator, dahdi_cfg
#
# Span 1: TE2/0/1 "T2XXP (PCI) Card 0 Span 1" (MASTER) HDB3/CCS ClockSource
span=1,0,0,ccs,hdb3
# termtype: te
bchan=1-15,17-31
dchan=16
echocanceller=mg2,1-15,17-31

# Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" HDB3/CCS
span=2,1,0,ccs,hdb3
# termtype: te
bchan=32-46,48-62
dchan=47
echocanceller=mg2,32-46,48-62

# Global data

loadzone = ru
defaultzone = ru

dahdi_test
Opened pseudo dahdi interface, measuring accuracy...
99.988% 99.987% 99.985% 99.997% 99.992% 99.984% 99.991% 99.994%
99.988% 100.000% 99.985% 99.987% 99.994% 99.985% 99.995% 99.989%
99.996% 99.990% 99.986% 99.988% 99.990% 99.994% 99.992% 99.990%
99.989% 99.985% 99.990% 99.994% 99.990% 99.989% 99.989% 99.986%
--- Results after 32 passes ---
Best: 100.000 -- Worst: 99.984 -- Average: 99.989954, Difference: 99.989954

Провод переобжимался не раз. Длинна менее 3-х метров.

После перезагрузки сервера бывает работает без падения пару дней, затем снова начинает постоянно падать канал.
До платы Digium была плата Sangoma, была такая же ситуация. После замены платы на Digium около полу года проблем замечено не было.

Сервер находится в Москве, если есть у кого нить желание помочь лично за вознаграждение - стучите в icq 9559883.

как минимум выставить правильно откуда брать синхру
span=1,1,0,ccs,hdb3
span=2,0,0,ccs,hdb3

с синхрой я тоже игрался, не помогало, но сейчас сделаю, как ты предлагаешь, посмотрим на результат.

Не знаю, может это может влиять, но с пол года назад я настроил запись всех звонков на соседний ЖД и запись всех логов. сейчас и это отключил, посмотрим что выйдет.

поменял конфиг, теперь так
# Span 1: TE2/0/1 "T2XXP (PCI) Card 0 Span 1" (MASTER) HDB3/CCS ClockSource
span=1,1,0,ccs,hdb3

# Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" HDB3/CCS
span=2,0,0,ccs,hdb3

ребутнул, запустил dahdi_scan
[1]
active=yes
alarms=LMFA/OK
description=T2XXP (PCI) Card 0 Span 1
name=TE2/0/1
manufacturer=Digium
devicetype=Wildcard TE220 (5th Gen)
location=Board ID Switch 0
basechan=1
totchans=31
irq=169
type=digital-E1
syncsrc=1
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=AMI,HDB3
framing_opts=CCS,CRC4
coding=HDB3
framing=CCS
[2]
active=yes
alarms=LMFA/OK
description=T2XXP (PCI) Card 0 Span 2
name=TE2/0/2
manufacturer=Digium
devicetype=Wildcard TE220 (5th Gen)
location=Board ID Switch 0
basechan=32
totchans=31
irq=169
type=digital-E1
syncsrc=1
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=AMI,HDB3
framing_opts=CCS,CRC4
coding=HDB3
framing=CCS

Значит ли это, что параметр timing в span 2 встал не в 0 а в 1? и почему?

ХЗ что это значит
синхра всегда должна браться от оператора, а не от станции отрезаной от ТФОП
и теперь так и есть, если никто ничего не перепутал и оператор на самом деле в первом порту

в общем такой расклад синхры не помагает, более того, канал вообще не поднимается.
Оператор и в самом деле в первом порту, ошибки быть не может.

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER: pri set debug 2 span 1

PRI Span: 1 t200_expire
PRI Span: 1 TEI: 0 State 5(Awaiting establishment)
PRI Span: 1 V(A)=90, V(S)=90, V(R)=78
PRI Span: 1 K=7, RC=2, l3initiated=1, reject_except=0, ack_pend=0
PRI Span: 1 T200_id=1, N200=3, T203_id=0
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1
PRI Span: 1 > TEI: 0 State 5(Awaiting establishment)
PRI Span: 1 > V(A)=90, V(S)=90, V(R)=78
PRI Span: 1 > K=7, RC=3, l3initiated=1, reject_except=0, ack_pend=0
PRI Span: 1 > T200_id=0, N200=3, T203_id=0
PRI Span: 1 > [ 00 01 7f ]
PRI Span: 1 > Unnumbered frame:
PRI Span: 1 > SAPI: 00 C/R: 0 EA: 0
PRI Span: 1 > TEI: 000 EA: 1
PRI Span: 1 > M3: 3 P/F: 1 M2: 3 11: 3 [ SABME (set asynchronous balanced mode extended) ]
PRI Span: 1 > 0 bytes of data
PRI Span: 1 -- Starting T200 timer
PRI Span: 1 t200_expire
PRI Span: 1 TEI: 0 State 5(Awaiting establishment)
PRI Span: 1 V(A)=90, V(S)=90, V(R)=78
PRI Span: 1 K=7, RC=3, l3initiated=1, reject_except=0, ack_pend=0
PRI Span: 1 T200_id=1, N200=3, T203_id=0
PRI Span: 1 TEI=0 MDL-ERROR (G): T200 expired N200 times sending SABME in state 5(Awaiting establishment)
PRI Span: 1 Changing from state 5(Awaiting establishment) to 4(TEI assigned)
PRI Span: 1 TEI=0 DL event: Q931_DL_EVENT_DL_RELEASE_IND(3)
PRI Span: 1 -- T203 requested to stop when not started
PRI Span: 1 -- Restarting T200 timer
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1
PRI Span: 1 > TEI: 0 State 4(TEI assigned)
PRI Span: 1 > V(A)=90, V(S)=90, V(R)=78
PRI Span: 1 > K=7, RC=0, l3initiated=1, reject_except=0, ack_pend=0
PRI Span: 1 > T200_id=1, N200=3, T203_id=0
PRI Span: 1 > [ 00 01 7f ]
PRI Span: 1 > Unnumbered frame:
PRI Span: 1 > SAPI: 00 C/R: 0 EA: 0
PRI Span: 1 > TEI: 000 EA: 1
PRI Span: 1 > M3: 3 P/F: 1 M2: 3 11: 3 [ SABME (set asynchronous balanced mode extended) ]
PRI Span: 1 > 0 bytes of data
PRI Span: 1 Changing from state 4(TEI assigned) to 5(Awaiting establishment)
Span: 1 Processing event: PRI_EVENT_DCHAN_DOWN

Если Астериск включен транзитно
Город == е1 == Астериск == е1 == АТС
то сделать
span=1,1,0,ccs,hdb3 (это порт из города)
span=2,2,0,ccs,hdb3 (это порт в АТС)

Нигде не надо выставлять
span=Х,0,0,ccs,hdb3
это и есть причина падения и треска.

Не должно быть двух источников синхронизации - город даёт синхру, а все остальные на этой линии под неё подстраиваются, по ранжиру.
В варианте
span=1,1,0,ccs,hdb3 мы типа принимаем из города синхру
span=2,0,0,ccs,hdb3 сами являемся источником,
но это рассинхронизация на самом деле.

выстававил

span=1,1,0,ccs,hdb3
span=2,2,0,ccs,hdb3

Поток с такой настройка не поднимается в чём моежт быть причина?

ded, любая TDM станция должна принимать синхронизацию столько с одного источника (заведомо синхронизированного), при его падении со следующего по приоритету (так же заведомо синхронизированного) и отдавать синхру на все остальные потоки.
таким образом в схеме транзита первым приоритетом поток оператора, а второго просто нет, т.к. АТС Panasonic TD500 не синхронизирована вследствии отсутствия прямого присоединения к оператору и должна брать синхру с потока на астериск.

поэтому должно быть именно так
span=1,1,0,ccs,hdb3 ; берем синхру
span=2,0,0,ccs,hdb3 ; никогда не берем с этого потока и сами являемся источником синхронизации

из-за не выставленной синхры поток неподняться не может нужно проверять другие параметры возможно CRC4 (самая первая причина)
вобщем нужно проверять последующие параметры
span=<span num>,<timing source>,<line build out (LBO)>,<framing>,<coding>[,yellow]

quiet писал(а):выстававил

span=1,1,0,ccs,hdb3
span=2,2,0,ccs,hdb3

Поток с такой настройка не поднимается в чём моежт быть причина?

Их два, который не поднимается? Как поднимаете?
Vlad, параметры

Код: Выделить всё

<line build out (LBO)>,<framing>

не критичны, ибо он написал - шнур короткий, не более 3 метров]<line build out (LBO)>, ну а <framing> другой бы просто не работал.
Возможно, что crc4 на стороне провайдера. На Cisco шлюзе порт Е1 вообще не поднимется если не угадал с crc4.

asterisk.ru

E1 падение канала

E1 падение канала

Re: E1 падение канала

Re: E1 падение канала

Re: E1 падение канала

Re: E1 падение канала

Re: E1 падение канала

Re: E1 падение канала

Re: E1 падение канала

Re: E1 падение канала

Re: E1 падение канала