Asterisk+Dahdi+E1

[barkosa]

ответ - во внерабочее время терминировать все входящие на music on hold, и устойчиво удерживать так. И сделать исходящий.

Т.е. при забитом канале на вход мы сделаем исходящий звонок именно в нерабочее время и у нас увеличится время ожидания ответа от станции???

Соглашусь только с тем что в гугле действительно такого не найти...

[ded]

Я считаю, что при полном занятии каналов входящими, при попытке исходящего будет выбираться первый свободный канал (которого нет!), и вы должны получить CONGESTION, Cause No. 34 - no circuit/channel available.
This cause indicates that there is no appropriate circuit/channel presently available to handle the call.

но так как его нет (якобы) происходит зависание. И это можно увидеть в pri debug.

[barkosa]

Ок дебаг включим сейчас и будем ждать зависания в рабочее время. Эмулировать что-то или вешать вход на холд пока нет возможности. А в теории, если при исходящем звонки мы получаем congestion, то звонок должен отваливаться без последствий для потока?

[ded]

Звонок должен даже не инициироваться, а при получении кода 34 в трубке просто ту-ту-ту - Congestion. В разных странах он по разному звучит. К примеру в РФ он не отличается по тонам от BUSY = 425Hz@350msec,350msec
А в других звучит тоже как BUSY, только более часто ту-тукает.

[olegek]

обновил prilib падать весь поток перестал.

но на АТС регят ошибки в пиковые моменты у них выскакивают по 1-2 ошибки на потоке, копаюсь в логах
может кто подскажет
дебаг выдает 33 тыс. строк за пиковый момент на 2 потоках

кусочек лога

[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: TEI: 0 State 8(Timer recovery)
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: V(A)=1, V(S)=8, V(R)=19
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: K=7, RC=3, l3_initiated=0, reject_except=0, ack_pend=0
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: T200_id=8192, N200=3, T203_id=0
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: TEI=0 MDL-ERROR (I): T200 expired N200 times sending RR/RNR in state 8(Timer recovery)
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: -- T203 requested to stop when not started
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: -- Restarting T200 timer
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: TEI=0 Sending SABME
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c:
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: > TEI: 0 State 8(Timer recovery)
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: > V(A)=1, V(S)=8, V(R)=19
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: > K=7, RC=0, l3_initiated=0, reject_except=0, ack_pend=0
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: > T200_id=8204, N200=3, T203_id=0
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: > [ 00 01 7f ]
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: > Unnumbered frame:
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: > SAPI: 00 C/R: 0 EA: 0
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: > TEI: 000 EA: 1
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: > M3: 3 P/F: 1 M2: 3 11: 3 [ SABME (set asynchronous balanced mode extended) ]
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: > 0 bytes of data
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: Changing from state 8(Timer recovery) to 5(Awaiting establishment)
[Dec 2 09:40:43] VERBOSE[10549] chan_dahdi.c: == Primary D-Channel on span 1 down
[Dec 2 09:40:43] WARNING[10549] chan_dahdi.c: No D-channels available! Using Primary channel 16 as D-channel anyway!

[ded]

No D-channels available! - потеря синхронизации. Порт перестаёт различать синхроимпульсы в 16-й слоте, сообщает об этом, и говорит, что по прежнему его считает синхро-слотом, несмотря на потери. Что тут сказать!
Причины могут быть как на коммутаторе провайдера, так и из-за длины последней мили до порта Е1, её надо терминировать, третья цифра в
span=1,1,0

TEI=0 MDL-ERROR (I): T200 expired N200 times sending RR/RNR in state 8(Timer recovery) - это про таймер, который в течение установленного времени не получили ответа по синхре видать, его текущее состояние
T200_id=8192, N200=3, T203_id=0

[ded]

Если чел, который сказал, что надо попробовать увеличить время ожидания ответа от станции когда подымается трубка для исходящего звонка, имел ввиду T200 Timer, то формулировка неверная. Его дефолтное значение 1000 мсек, этого вроде должно хватать. Можно увеличить количество попыток поднятия синхры при потере - N200 Counter: 3 попытки дефолт, но думаю, причина не в этом.
Посмотреть все значения -

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

*CLI> pri show span 1                      
Primary D-channel: 109                        
Status: Provisioned, Up, Active               
Switchtype: Q.SIG switch                      
Type: CPE                                     
Window Length: 0/7                            
Sentrej: 0                                    
SolicitFbit: 0                                
Retrans: 0                                    
Busy: 0                                       
Overlap Dial: 0                               
Logical Channel Mapping: 0                    
T200 Timer: 1000                              
T203 Timer: 10000                             
T305 Timer: 30000                             
T308 Timer: 4000                              
T309 Timer: -1                                
T313 Timer: 4000                              
N200 Counter: 3                               
Overlap Recv: No   

[Vlad1983]

скорей всего заваливается на транспорте у оператора.
некоторые железки TDMoIP при занятии почти всех ТС начинают заваливать сеть мелкими пакетами.
с этим потоком может не справиться транспортное железо, либо канал где-то медью организован.
из-за этого появляются потери пакетов, как следствие синхра плывет.

[olegek]

Нашел примеры решения в сети

1. Проблема на стороне провайдера. Если, например, используется 2-х портовая карта Digium TE212P, и оба потока принадлежат одному и тому же провайдеру, то нужно поменять местами потоки и посмотреть что будет. Если проблема была на втором потоке, и "переедет" на первой поток, явно разные настройки потоков у провайдера и надо пинать его. Если же по прежнему проблемы будут на том же потоке, дело в настройках на стороне астериска.

2. Проблема оборудования. Крайне редко попадаются бракованные карты, которые в таком случае надо заменить.

3. Аппаратное управление D-каналом. Попробовать в zaptel.conf вместо dchan=>16 указать hardhdlc=>16 для аппаратного управления D-каналом.

4. Ошибка конфигурации Line Build-Out (LBO). Попробовать другие значения.

5. Выключить периодический рестрат B-каналов. Для этого в zapata.conf под switchtype прописывается resetinterval=never.

Поставил настройки по 5 пункту ранее, не помогло.

Потом hardhdlc=>16 - это помогло, на стороне АТС ошибки не фиксируют, жду результатов лаборатории провайдера.

Всем спасибо. Хотя возможно лаборатория не пропустит, так как пересобрал libpri 1.4.12, старый комплект pridialplan=belorus - самопальный заменил
на pridialplan=national

[Tarzit]

ded, зачем засирать ветку конфигами, которые и так все знают. Все-равно из предложенных по дефолту pridialplan's нету того который устроил бы нашего провайдера. При исходящем звонке мы должны отдавать ton: 0, npi: 1.

Сорри за некропостинг.
Появилась ли возможность отдавать ton: 0, npi: 1 провайдеору ? ну и конечно pridialplan=minsk было бы офигенно . А то наш белтелеком очень это хочет.