Чат  ::   FAQ  ::   Поиск  ::   Регистрация  ::   Вход

OpenVox D230E cause 27

Модератор: april22

OpenVox D230E cause 27

Сообщение sach3000 » 11 авг 2019, 00:24

Приветствую вас, коллеги

Пришел с вопросом.
Имею карту OpenVox D230E на PCE-E.
Вставлена в сервак DELL PowerEdge 730
Все определилось, модули загрузились, конфигурация сгенерилась.

Имею проблему с sig_pri.c: Span 1: Channel 0/1 got hangup, cause 27 (Destination out of order)
Дозвон через любой таймслот показывает занято.
Может уже замылился глаз, прошу помощи.

Астериск
Код: выделить все
cleep1*CLI> core show version
Asterisk 16.5.0 built by root @ cleep1 on a x86_64 running Linux on 2019-08-07 16:01:43 UTC


Система
Код: выделить все
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS"


Модуль dahdi
Код: выделить все
root@cleep1:~# lsmod | grep wc
wct4xxp                86016  62
oct612x               167936  1 wct4xxp
dahdi                 233472  126 wct4xxp,oct612x


В системе определяется как:
[Показать] Спойлер:
06:00.0 Network controller: Digium, Inc. Wildcard TE220 dual-span T1/E1/J1 card 3.3V (PCI-Express) (5th gen) (rev 15)
Subsystem: Device 0005:0000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (8000ns min, 32000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 15
NUMA node: 0
Region 0: Memory at 91c00000 (32-bit, non-prefetchable) [size=32K]


из файла dahdi-blacklist.conf выключил #blacklist wct4xxp
system.conf
[Показать] Спойлер:
span=1,1,0,ccs,hdb3,crc4
# 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".
span=2,2,0,ccs,hdb3,crc4
# termtype: te
bchan=32-46,48-62
dchan=47
#echocanceller=mg2,32-46,48-62

# Global data

loadzone = ru
defaultzone = ru


Да и echocanceller, был пробовал включать/выключать выключил потому что ругался на
Код: выделить все
[89881.430048] wct4xxp 0000:06:00.0: VPM450: Not Present


dahdi-channels.conf
[Показать] Спойлер:
; Span 1: TE2/0/1 "T2XXP (PCI) Card 0 Span 1" (MASTER).
group=0,11
context=to-beeline-grp
pridialplan=unknown
prilocaldialplan=unknown
switchtype = euroisdn
signalling = pri_cpe
channel => 1-15,17-31
context = default
group = 63

; Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2".
group=0,12
context=to-beeline-grp
pridialplan=unknown
prilocaldialplan=unknown
switchtype = euroisdn
signalling = pri_cpe
channel => 32-46,48-62
context = default
group = 63


в chan_dahdi.conf добавил только #include dahdi-channels.conf

extensions.conf
[Показать] Спойлер:
[to-beeline-grp]
exten => _X.,1,Noop(Set CallerID)
exten => _X.,n,Set(CALLERID(number)=091115217)
exten => _X.,n,Dial(DAHDI/g11/${EXTEN})


в Астериске
[Показать] Спойлер:
cleep1*CLI> dahdi show status
Description Alarms IRQ bpviol CRC Fra Codi Options LBO
T2XXP (PCI) Card 0 Span 1 OK 1 0 0 CCS HDB3 CRC4 0 db (CSU)/0-133 feet (DSX-1)
T2XXP (PCI) Card 0 Span 2 OK 1 0 0 CCS HDB3 CRC4 0 db (CSU)/0-133 feet (DSX-1)

cleep1*CLI> pri show spans
PRI span 1/0: Up, Active
PRI span 2/0: Down, Active

pri show channels
все 62 линии в
1 2 Yes Yes Idle No


Вот что происходит, это из full лога астера:
[Показать] Спойлер:
[Aug 10 23:26:25] VERBOSE[4799][C-00000006] pbx.c: Executing [091201942@to-beeline-grp:1] NoOp("SIP/100-00000004", "Set CallerID") in new stack
[Aug 10 23:26:25] DEBUG[4799][C-00000006] pbx.c: Launching 'Set'
[Aug 10 23:26:25] VERBOSE[4799][C-00000006] pbx.c: Executing [091201942@to-beeline-grp:2] Set("SIP/100-00000004", "CALLERID(number)=091115217") in new stack
[Aug 10 23:26:25] DEBUG[4799][C-00000006] pbx.c: Launching 'Dial'
[Aug 10 23:26:25] VERBOSE[4799][C-00000006] pbx.c: Executing [091201942@to-beeline-grp:3] Dial("SIP/100-00000004", "DAHDI/g11/091201942") in new stack
[Aug 10 23:26:25] DEBUG[4799][C-00000006] chan_dahdi.c: Using channel 1
[Aug 10 23:26:25] DEBUG[4799][C-00000006] sig_pri.c: sig_pri_request 1
[Aug 10 23:26:25] DEBUG[4799][C-00000006] stasis.c: Creating topic. name: channel:1565465185.8, detail:
[Aug 10 23:26:25] DEBUG[4799][C-00000006] stasis.c: Topic 'channel:1565465185.8': 0x7f2f2c007cc0 created
[Aug 10 23:26:25] DEBUG[4799][C-00000006] stasis.c: Creating topic. name: cache:14/channel:1565465185.8, detail:
[Aug 10 23:26:25] DEBUG[4799][C-00000006] stasis.c: Topic 'cache:14/channel:1565465185.8': 0x7f2f2c003b90 created
[Aug 10 23:26:25] DEBUG[4799][C-00000006] channel.c: Channel 0x7f2f2c004ee0 'DAHDI/i1/091201942-1' allocated
[Aug 10 23:26:25] DEBUG[4799][C-00000006] dsp.c: Setup tone 1100 Hz, 500 ms, block_size=160, hits_required=21
[Aug 10 23:26:25] DEBUG[4799][C-00000006] dsp.c: Setup tone 2100 Hz, 2600 ms, block_size=160, hits_required=116
[Aug 10 23:26:25] DEBUG[3858] devicestate.c: Changing state for DAHDI/i1/091201942 - state 2 (In use)
[Aug 10 23:26:25] DEBUG[3858] devicestate.c: Changing state for DAHDI/I1/congestion - state 1 (Not in use)
[Aug 10 23:26:25] DEBUG[4799][C-00000006] channel_internal_api.c: Channel Call ID changing from [C-00000006] to [C-00000006]
[Aug 10 23:26:25] DEBUG[4799][C-00000006] rtp_engine.c: Can't find native functions for channel 'DAHDI/i1/091201942-1'
[Aug 10 23:26:25] DEBUG[3898] app_queue.c: Device 'DAHDI/i1/091201942' changed to state '2' (In use) but we don't care because they're not a member of any queue.
[Aug 10 23:26:25] DEBUG[3898] app_queue.c: Device 'DAHDI/I1/congestion' changed to state '1' (Not in use) but we don't care because they're not a member of any queue.
[Aug 10 23:26:25] DEBUG[4799][C-00000006] sig_pri.c: CALLER NAME: NUM: 091115217
[Aug 10 23:26:25] VERBOSE[4799][C-00000006] sig_pri.c: Requested transfer capability: 0x00 - SPEECH
[Aug 10 23:26:25] VERBOSE[4799][C-00000006] app_dial.c: Called DAHDI/g11/091201942
[Aug 10 23:26:25] DEBUG[3858] devicestate.c: Changing state for DAHDI/i1/091201942 - state 2 (In use)
[Aug 10 23:26:25] DEBUG[4799][C-00000006] channel.c: Channel DAHDI/i1/091201942-1 setting read format path: alaw -> alaw
[Aug 10 23:26:25] DEBUG[4799][C-00000006] channel.c: Channel SIP/100-00000004 setting write format path: alaw -> alaw
[Aug 10 23:26:25] DEBUG[4799][C-00000006] channel.c: Channel SIP/100-00000004 setting read format path: alaw -> alaw
[Aug 10 23:26:25] DEBUG[3898] app_queue.c: Device 'DAHDI/i1/091201942' changed to state '2' (In use) but we don't care because they're not a member of any queue.
[Aug 10 23:26:25] DEBUG[4799][C-00000006] channel.c: Channel DAHDI/i1/091201942-1 setting write format path: alaw -> alaw

[Aug 10 23:26:29] VERBOSE[4785] sig_pri.c: Primary D-Channel on span 1 up
[Aug 10 23:26:29] VERBOSE[4785][C-00000006] sig_pri.c: Span 1: Channel 0/1 got hangup, cause 27
[Aug 10 23:26:29] VERBOSE[4799][C-00000006] app_dial.c: DAHDI/i1/091201942-1 is circuit-busy
[Aug 10 23:26:29] DEBUG[4799][C-00000006] channel.c: Channel 0x7f2f2c004ee0 'DAHDI/i1/091201942-1' hanging up. Refs: 2
[Aug 10 23:26:29] DEBUG[4799][C-00000006] chan_dahdi.c: dahdi_hangup(DAHDI/i1/091201942-1)
[Aug 10 23:26:29] DEBUG[4799][C-00000006] chan_dahdi.c: Set option AUDIO MODE, value: ON(1) on DAHDI/i1/091201942-1
[Aug 10 23:26:29] DEBUG[3867] cdr.c: Finalized CDR for SIP/100-00000004 - start 1565465185.976958 answer 0.000000 end 1565465189.863648 dispo FAILED
[Aug 10 23:26:29] DEBUG[4799][C-00000006] sig_pri.c: sig_pri_hangup 1
[Aug 10 23:26:29] DEBUG[4799][C-00000006] sig_pri.c: Channel 'DAHDI/i1/091201942-1' MOH-Event: SIG_PRI_MOH_EVENT_RESET in state SIG_PRI_MOH_STATE_IDLE
[Aug 10 23:26:29] DEBUG[4799][C-00000006] sig_pri.c: Channel 'DAHDI/i1/091201942-1' MOH-Next-State: $
[Aug 10 23:26:29] DEBUG[4799][C-00000006] sig_pri.c: Already hungup... Calling hangup once, and clearing call
[Aug 10 23:26:29] DEBUG[4799][C-00000006] chan_dahdi.c: Set option TDD MODE, value: OFF(0) on DAHDI/i1/091201942-1
[Aug 10 23:26:29] DEBUG[4799][C-00000006] chan_dahdi.c: Updated conferencing on 1, with 0 conference users
[Aug 10 23:26:29] DEBUG[4799][C-00000006] chan_dahdi.c: Set option AUDIO MODE, value: OFF(0) on DAHDI/i1/091201942-1
[Aug 10 23:26:29] VERBOSE[4799][C-00000006] chan_dahdi.c: Hungup 'DAHDI/i1/091201942-1'
[Aug 10 23:26:29] DEBUG[4799][C-00000006] channel.c: Channel 0x7f2f2c004ee0 'DAHDI/i1/091201942-1' destroying
[Aug 10 23:26:29] DEBUG[3867] cdr.c: Finalized CDR for DAHDI/i1/091201942-1 - start 1565465185.977898 answer 0.000000 end 1565465189.863858 dispo NO ANSWER
[Aug 10 23:26:29] DEBUG[3867] cdr.c: CDR for DAHDI/i1/091201942-1 is dialed and has no Party B; discarding
[Aug 10 23:26:29] DEBUG[4799][C-00000006] stasis.c: Destroying topic. name: cache:14/channel:1565465185.8, detail:
[Aug 10 23:26:29] DEBUG[4799][C-00000006] stasis.c: Topic 'cache:14/channel:1565465185.8': 0x7f2f2c003b90 destroyed
[Aug 10 23:26:29] DEBUG[4799][C-00000006] stasis.c: Destroying topic. name: channel:1565465185.8, detail:
[Aug 10 23:26:29] DEBUG[4799][C-00000006] stasis.c: Topic 'channel:1565465185.8': 0x7f2f2c007cc0 destroyed
[Aug 10 23:26:29] VERBOSE[4799][C-00000006] app_dial.c: Everyone is busy/congested at this time (1:0/1/0)
[Aug 10 23:26:29] DEBUG[4799][C-00000006] app_dial.c: Exiting with DIALSTATUS=CONGESTION.
[Aug 10 23:26:29] VERBOSE[4799][C-00000006] pbx.c: Auto fallthrough, channel 'SIP/100-00000004' status is 'CONGESTION'
[Aug 10 23:26:29] DEBUG[3858] devicestate.c: Changing state for DAHDI/i1/091201942 - state 0 (Unknown)
[Aug 10 23:26:29] DEBUG[3898] app_queue.c: Device 'DAHDI/i1/091201942' changed to state '0' (Unknown) but we don't care because they're not a member of any queue.


Да и звоню через консольный pjsua, на том же сервере
, вот его конфа
[Показать] Спойлер:
--log-file=/opt/distr/client/pjlog
--color
--duration=5
--log-level=5
--null-audio
--local-port=5066
--registrar sip:100@10.3.0.145
--id sip:100@10.3.0.145
--username 100
--password 123
--realm *
--use-srtp 0
--srtp-secure=0



Спасибо.
sach3000
 
Сообщений: 12
Зарегистрирован: 10 авг 2019, 23:46

Re: OpenVox D230E cause 27

Сообщение awsswa » 11 авг 2019, 19:02

Не те логи снимаете
вам надо снимать общее с провайдером, проблемы в общении
по логам поймете что ему не нравиться
платный суппорт по мере возможностей
awsswa
 
Сообщений: 2379
Зарегистрирован: 09 июн 2012, 10:52
Откуда: Россия, Пермь skype: yarick_perm

Re: OpenVox D230E cause 27

Сообщение sach3000 » 11 авг 2019, 19:28

Добрый день

Да, ессно задал вопрос провайдеру, на что получил ответ:
"Каналы заблокированы, можете попробовать разблокировать с вашей стороны?"
и что-то я затупил, как понять заблокированы и как это их разблокировать... таймслот ведь либо свободен, либо нет.

Может кто прояснить ?

Спасибо.
sach3000
 
Сообщений: 12
Зарегистрирован: 10 авг 2019, 23:46

Re: OpenVox D230E cause 27

Сообщение ded » 11 авг 2019, 21:17

sach3000 писал(а):Имею проблему с sig_pri.c: Span 1: Channel 0/1 got hangup, cause 27 (Destination out of order)
Дозвон через любой таймслот показывает занято.
Дозвон показывает Destination out of order, это не занято (BUSY).
Cause 27 Destination out of order - This cause indicates that the destination indicated by the user can not be reached because the interface to the destination is not functioning correctly.

То есть тот узел, куда вы направляете вызов 091201942 не готов принять от вас этот вызов. Хотя физически этот линк E1 PRI в порядке, на уровне Layer 2-3 всё у вас ОК. Куда воткнуты оба порта? В конвертер провайдера Beeline?

Вряд ли он ждёт номера в формате 9-тизнак 091201942. Пробуйте набирать 10-тизначные номера. Чтобы видеть чистый лог -
CLI> core set verbose 0
CLI> pri set debug on span 1

sach3000 писал(а):Да и echocanceller, был пробовал включать/выключать выключил потому что ругался на
Код: выделить все
[89881.430048] wct4xxp 0000:06:00.0: VPM450: Not Present
Он не ругался, а сообщал, что аппаратный модуль эхоподавления VPM450 на карте, который поставляется опционально, не присутствует.
Не имеет отношения к проблеме.
ded
 
Сообщений: 14301
Зарегистрирован: 26 авг 2010, 19:00

Re: OpenVox D230E cause 27

Сообщение sach3000 » 11 авг 2019, 22:03

Номер 091201942 вполне валидный, и оператором жуется, это VEON (Би Армения). Пробовал и через префикс страны 374 (проблемы не меняет).

"Куда воткнуты оба порта? В конвертер провайдера Beeline?"
Это не могу сказать, уточню у них...вроде в стойку SDH

"VPM450 на карте, который поставляется опционально, не присутствует. "
Да, это я понял, поэтому и отключил.

По поводу дебага, PRI есть один нюанс
Выкладываю
[Показать] Спойлер:
cleep1*CLI> pri set debug on span 1
Enabled debugging on span 1
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 SAPI/TEI=0/0 Kick starting link
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 Changing from state 4(TEI assigned) to 5(Awaiting establishment)
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 TEI=0 Sending SABME
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 SAPI/TEI=0/0 Kick starting link
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 Changing from state 4(TEI assigned) to 5(Awaiting establishment)
PRI Span: 1 -- Making new call for cref 32770
PRI Span: 1
PRI Span: 1 > DL-DATA request
PRI Span: 1 > Protocol Discriminator: Q.931 (8) len=41
PRI Span: 1 > TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent from originator)
PRI Span: 1 > Message Type: SETUP (5)
PRI Span: 1 TEI=0 Just queued I-frame since in state 5(Awaiting establishment)
PRI Span: 1 q931.c:6531 q931_setup: Call 32770 enters state 1 (Call Initiated). Hold state: Idle
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 TEI=0 Sending SABME
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 Cancel call cref=32770 on channel 1 in state 1 (Call Initiated)
PRI Span: 1 Cancel call after data link failure
PRI Span: 1 q931.c:9975 pri_dl_down_cancelcall: Call 32770 enters state 0 (Null). Hold state: Idle
PRI Span: 1 q931.c:9910 pri_internal_clear: alive 1, hangupack 1
Span 1: Processing event PRI_EVENT_HANGUP(6)
PRI Span: 1 q931.c:7332 q931_hangup: Hangup other cref:32770
PRI Span: 1 q931.c:7089 __q931_hangup: ourstate Null, peerstate Null, hold-state Idle
PRI Span: 1 Destroying call 0x7f2f30006750, ourstate Null, peerstate Null, hold-state Idle
PRI Span: 1 SAPI/TEI=0/0 Kick starting link
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 Changing from state 4(TEI assigned) to 5(Awaiting establishment)
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 TEI=0 Sending SABME
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 SAPI/TEI=0/0 Kick starting link
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 Changing from state 4(TEI assigned) to 5(Awaiting establishment)
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 TEI=0 Sending SABME
cleep1*CLI> pri set debug off span 1


ну и в full логе, тож самое
[Показать] Спойлер:
[Aug 11 21:41:10] DEBUG[3898] app_queue.c: Device 'DAHDI/i1/091201942' changed to state '2' (In use) but we don't care because they're not a member of any queue.
[Aug 11 21:41:11] VERBOSE[4785] chan_dahdi.c: PRI Span: 1 TEI=0 Sending SABME
[Aug 11 21:41:11] DEBUG[3889] chan_sip.c: Allocating new SIP dialog for 5f94e6763d6620570cfa50b6111ad9d8@[2a00:f38:a:3:1618:77ff:fe66:f201]:5060 - OPTIONS (No RTP)
[Aug 11 21:41:11] DEBUG[3889] acl.c: For destination '10.3.0.145', our source address is '10.3.0.145'.
[Aug 11 21:41:11] DEBUG[3889] chan_sip.c: Setting AST_TRANSPORT_UDP with address 10.3.0.145:5060
[Aug 11 21:41:11] DEBUG[3889] chan_sip.c: SIP call-id changed from '5f94e6763d6620570cfa50b6111ad9d8@[2a00:f38:a:3:1618:77ff:fe66:f201]:5060' to '76fc944f51fdd9ae06ad68d02b8f0f25@10.3.0.145:5060'
[Aug 11 21:41:11] DEBUG[3889] chan_sip.c: Initializing initreq for method OPTIONS - callid 76fc944f51fdd9ae06ad68d02b8f0f25@10.3.0.145:5060
[Aug 11 21:41:11] DEBUG[3889] chan_sip.c: Trying to put 'OPTIONS sip' onto UDP socket destined for 10.3.0.145:5066
[Aug 11 21:41:11] DEBUG[3889] chan_sip.c: Stopping retransmission on '76fc944f51fdd9ae06ad68d02b8f0f25@10.3.0.145:5060' of Request 102: Match Found
[Aug 11 21:41:11] DEBUG[3889] chan_sip.c: Destroying SIP dialog 76fc944f51fdd9ae06ad68d02b8f0f25@10.3.0.145:5060
[Aug 11 21:41:12] VERBOSE[4785] chan_dahdi.c: PRI Span: 1 TEI=0 Sending SABME
[Aug 11 21:41:13] VERBOSE[4785] chan_dahdi.c: PRI Span: 1 TEI=0 Sending SABME
[Aug 11 21:41:14] VERBOSE[4785] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (G): T200 expired N200 times sending SABME in state 5(Awaiting establishment)
[Aug 11 21:41:14] VERBOSE[4785] chan_dahdi.c: PRI Span: 1 Changing from state 5(Awaiting establishment) to 4(TEI assigned)
[Aug 11 21:41:14] VERBOSE[4785] chan_dahdi.c: PRI Span: 1 TEI=0 DL event: Q931_DL_EVENT_DL_RELEASE_IND(3)
[Aug 11 21:41:14] VERBOSE[4785] chan_dahdi.c: PRI Span: 1 Cancel call cref=32770 on channel 1 in state 1 (Call Initiated)
[Aug 11 21:41:14] VERBOSE[4785] chan_dahdi.c: PRI Span: 1 Cancel call after data link failure
[Aug 11 21:41:14] VERBOSE[4785] chan_dahdi.c: PRI Span: 1 q931.c:9975 pri_dl_down_cancelcall: Call 32770 enters state 0 (Null). Hold state: Idle
[Aug 11 21:41:14] VERBOSE[4785] chan_dahdi.c: PRI Span: 1 q931.c:9910 pri_internal_clear: alive 1, hangupack 1
[Aug 11 21:41:14] VERBOSE[4785] sig_pri.c: Span 1: Processing event PRI_EVENT_HANGUP(6)
[Aug 11 21:41:14] VERBOSE[4785][C-00000007] sig_pri.c: Span 1: Channel 0/1 got hangup, cause 27
[Aug 11 21:41:14] VERBOSE[5841][C-00000007] app_dial.c: DAHDI/i1/091201942-2 is circuit-busy
[Aug 11 21:41:14] DEBUG[5841][C-00000007] channel.c: Channel 0x7f2f30005a20 'DAHDI/i1/091201942-2' hanging up. Refs: 2
[Aug 11 21:41:14] DEBUG[5841][C-00000007] chan_dahdi.c: dahdi_hangup(DAHDI/i1/091201942-2)
[Aug 11 21:41:14] DEBUG[5841][C-00000007] chan_dahdi.c: Set option AUDIO MODE, value: ON(1) on DAHDI/i1/091201942-2
[Aug 11 21:41:14] DEBUG[5841][C-00000007] sig_pri.c: sig_pri_hangup 1
[Aug 11 21:41:14] DEBUG[5841][C-00000007] sig_pri.c: Channel 'DAHDI/i1/091201942-2' MOH-Event: SIG_PRI_MOH_EVENT_RESET in state SIG_PRI_MOH_STATE_IDLE
[Aug 11 21:41:14] DEBUG[5841][C-00000007] sig_pri.c: Channel 'DAHDI/i1/091201942-2' MOH-Next-State: $
[Aug 11 21:41:14] DEBUG[5841][C-00000007] sig_pri.c: Already hungup... Calling hangup once, and clearing call


Пробую в национальном формате, в принципе получаю ту же картину
[Показать] Спойлер:
-- Executing [+37491201942@to-beeline-grp:1] NoOp("SIP/100-00000001", "Set CallerID") in new stack
-- Executing [+37491201942@to-beeline-grp:2] Set("SIP/100-00000001", "CALLERID(number)=37491115217") in new stack
-- Executing [+37491201942@to-beeline-grp:3] Dial("SIP/100-00000001", "DAHDI/g11/+37491201942") in new stack
-- Requested transfer capability: 0x00 - SPEECH
-- Called DAHDI/g11/+37491201942

<--- SIP read from UDP:10.3.0.145:5066 --->

<------------->
== Primary D-Channel on span 1 up
-- Span 1: Channel 0/1 got hangup, cause 27
-- DAHDI/i1/+37491201942-1 is circuit-busy
-- Hungup 'DAHDI/i1/+37491201942-1'
== Everyone is busy/congested at this time (1:0/1/0)
-- Auto fallthrough, channel 'SIP/100-00000001' status is 'CONGESTION'

<--- Reliably Transmitting (no NAT) to 10.3.0.145:5066 --->
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 10.3.0.145:5066;branch=z9hG4bKPj45ee4b9b-889a-4c31-a463-e0e7f66cd543;received=10.3.0.145;rport=5066
From: sip:100@10.3.0.145;tag=34102aff-e91f-4e26-b94b-0f1a6e0b9616
To: sip:+37491201942@10.3.0.145;tag=as7f5eb353
Call-ID: f4ae4495-0e8a-4201-b80a-b907fd584e7a
CSeq: 11324 INVITE
Server: Asterisk PBX 16.5.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
X-Asterisk-HangupCause: Destination out of order
X-Asterisk-HangupCauseCode: 27
Content-Length: 0


и с дебаг pri span 1
[Показать] Спойлер:
PRI Span: 1 > DL-DATA request
PRI Span: 1 > Protocol Discriminator: Q.931 (8) len=46
PRI Span: 1 > TEI=0 Call Ref: len= 2 (reference 2/0x2) (Sent from originator)
PRI Span: 1 > Message Type: SETUP (5)
PRI Span: 1 TEI=0 Just queued I-frame since in state 5(Awaiting establishment)
PRI Span: 1 q931.c:6531 q931_setup: Call 32770 enters state 1 (Call Initiated). Hold state: Idle
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 Cancel call cref=32770 on channel 1 in state 1 (Call Initiated)
PRI Span: 1 Cancel call after data link failure
PRI Span: 1 q931.c:9975 pri_dl_down_cancelcall: Call 32770 enters state 0 (Null). Hold state: Idle
PRI Span: 1 q931.c:9910 pri_internal_clear: alive 1, hangupack 1
Span 1: Processing event PRI_EVENT_HANGUP(6)
PRI Span: 1 q931.c:7332 q931_hangup: Hangup other cref:32770
PRI Span: 1 q931.c:7089 __q931_hangup: ourstate Null, peerstate Null, hold-state Idle
PRI Span: 1 Destroying call 0x7f4754008ad0, ourstate Null, peerstate Null, hold-state Idle
PRI Span: 1 SAPI/TEI=0/0 Kick starting link
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 Changing from state 4(TEI assigned) to 5(Awaiting establishment)
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 TEI=0 Sending SABME
PRI Span: 1 TEI=0 Sending SABME


Мне бы понять, на провайдера давить или все-таки у меня что-то не так настроено...

Спасибо.
sach3000
 
Сообщений: 12
Зарегистрирован: 10 авг 2019, 23:46

Re: OpenVox D230E cause 27

Сообщение ded » 12 авг 2019, 10:22

Проблема линка на уровне Layer 2. Может быть по разным причинам, в том числе по длине патч-корда Е1 до порта провайдера (регулируется третьей цифрой в указании параметров span= )
Попробуйте выключить crc4
span=1,1,0,ccs,hdb3
ded
 
Сообщений: 14301
Зарегистрирован: 26 авг 2010, 19:00

Re: OpenVox D230E cause 27

Сообщение sach3000 » 12 авг 2019, 11:36

убрал crc4, пока все тоже самое. ((
sach3000
 
Сообщений: 12
Зарегистрирован: 10 авг 2019, 23:46

Re: OpenVox D230E cause 27

Сообщение ded » 12 авг 2019, 11:38

Узнавайте как-то: как далеко порт в стойке провайдера, куда втыкается Е1 линк? Сколько метров?
ded
 
Сообщений: 14301
Зарегистрирован: 26 авг 2010, 19:00

Re: OpenVox D230E cause 27

Сообщение sach3000 » 12 авг 2019, 13:20

Узнал про длину, около 5 метров.
Тут другой вопрос, что провайдер, говорит, поднятых линков так и нет
У них Signaling link code 0

у меня в system.conf
bchan=1-15,17-31
dchan=16

как я понимаю нужно исправить на

bchan=1-31
dchan=0

Или нужно все-таки выставлять в
; Set the Signaling Link Code (SLC) for each sigchan.
; If you manually set any you need to manually set all.
; Should be defined before sigchan.
; The default SLC starts with zero and increases for each defined sigchan.
;slc=

принудительно

Спасибо.
sach3000
 
Сообщений: 12
Зарегистрирован: 10 авг 2019, 23:46

Re: OpenVox D230E cause 27

Сообщение ded » 12 авг 2019, 13:47

Значит имеем такую проблему: с вашей стороны зелёный - ОК
dahdi_tool
покажет оба span ОК?
А на стороне провайдер - не поднят линк?
Тогда какая версия библиотек libpri & dahdi linux? Есть недостатки использования морально устаревающих PCI-карт и новых PCI-express карт на новых ОС и версиях Астериск.
OpenVox рекомендует собирать эти библиотеки из своих сорцев
https://openvoxwiki.atlassian.net/wiki/ ... ntypesetup
sach3000 писал(а):как я понимаю нужно исправить на

bchan=1-31
dchan=0
Нет.

По поводу длины (третья цифра в параметрах span= ):
# The line build-out (or LBO) is an integer, from the following table:
#
# 0: 0 db (CSU) / 0-133 feet (DSX-1)
# 1: 133-266 feet (DSX-1)
# 2: 266-399 feet (DSX-1)
# 3: 399-533 feet (DSX-1)
# 4: 533-655 feet (DSX-1)
# 5: -7.5db (CSU)
# 6: -15db (CSU)
# 7: -22.5db (CSU)
133 фута = 40,5 метров
То есть 0 проходит для 5 метров.
ded
 
Сообщений: 14301
Зарегистрирован: 26 авг 2010, 19:00

След.

Вернуться в Карты Е1 разных вендоров

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

© 2008 — 2020 Asterisk.ru
Digium, Asterisk and AsteriskNOW are registered trademarks of Digium, Inc.
Design and development by PostMet-Netzwerk GmbH