forum.technoforward.ru

Доброго времени суток! Прошу помощи в поиске причины периодического отсутствия соединения при исходящих вызовах по SIP транкам, транки настроены в соответствии с документацией. В отладчике это выглядит так:

===== << 08/31, 16:40 >> =====

multi_call_control_pro Before-Status:0

multi_call_control_pro After-Status:0

T305 TIMER CLEAR !!!
multi_call_control_pro Before-Status:0

multi_call_control_pro After-Status:0

TRK TARGET_DIAL=00000000
hunt_que_del_allstg des_w[dc09]
== Initialize rgt_port_data memory for port:dc09
== rgt_port_data_read(dc09) was 0000
TRK TARGET_DIAL=00000000
<<< cdetect.cpp(216) new cdetector::open() target port is 2d >>>
<<< cdetect.cpp(276) Enter cdetector::open(DT_DTMF,0,002DH) >>>
<<< cdetect.cpp(540) cdetect::open() Channel 1401H is opened for port 002DH >>>
<<< cdetect.cpp(1112) Enter cdetect::connect() >>>
<<< idetect.cpp(4062) iUnitDspCygnus::detectorReport() Resource#0 Assigned >>>
<<< cdetect.cpp(1533) cdetector::mail() Assigned resource#0 >>>
<<< idetect.cpp(1772) iUnitDsp::dtmfDetected() Resource#0, Digit[9] >>>
t_dt_dana(): dial_ana(002DH) returns FFFDH
t_dt_dana(): dial_ana(002DH) returns 6000H
Enter t_serv_access(Port=002DH,Access=6000H)
regId = 0
ITR_NULL_P_STA: DES_ANSWER_FLAG CLEAR!
ITR_NULL_P_STA: TM_DES_ANSWER_WAIT_L SET!
<<< idetect.cpp(1772) iUnitDsp::dtmfDetected() Resource#0, Digit[4] >>>
<<< idetect.cpp(1772) iUnitDsp::dtmfDetected() Resource#0, Digit[0] >>>
<<< idetect.cpp(1772) iUnitDsp::dtmfDetected() Resource#0, Digit[5] >>>
<<< idetect.cpp(1772) iUnitDsp::dtmfDetected() Resource#0, Digit[9] >>>
<<< idetect.cpp(1772) iUnitDsp::dtmfDetected() Resource#0, Digit[7] >>>
<<< idetect.cpp(1772) iUnitDsp::dtmfDetected() Resource#0, Digit[6] >>>
cevent_h323 : Alarm Received
<< RECOVER : No.=3CH : P1=0H : P2=0H : P3=0H : ID=3B0H : INDX=0H >>
<<< cdetect.cpp(216) new cdetector::open() target port is d >>>
<<< cdetect.cpp(276) Enter cdetector::open(DT_DTMF,0,000DH) >>>
<<< cdetect.cpp(540) cdetect::open() Channel 1402H is opened for port 000DH >>>
<<< cdetect.cpp(1112) Enter cdetect::connect() >>>
<<< idetect.cpp(4062) iUnitDspCygnus::detectorReport() Resource#1 Assigned >>>
<<< cdetect.cpp(1533) cdetector::mail() Assigned resource#1 >>>
<<< idetect.cpp(1772) iUnitDsp::dtmfDetected() Resource#1, Digit[6] >>>
t_dt_dana(): dial_ana(000DH) returns FFFDH
t_dt_dana(): dial_ana(000DH) returns FFFDH
<<< idetect.cpp(1772) iUnitDsp::dtmfDetected() Resource#1, Digit[5] >>>
<<< idetect.cpp(1772) iUnitDsp::dtmfDetected() Resource#1, Digit[9] >>>
t_dt_dana(): dial_ana(000DH) returns 203CH
Enter t_serv_access(Port=000DH,Access=203CH)
Enter station_access_2w(Port=000DH,Des=003CH)
station_access_2w(): sta_logic_port() returns 003CH
*** ring_tone_req (L:3C,P:3,T:0,D:D) ***
<<< css.cpp(446) css::ring_tone_req >>> Caller ID no setting
get_rgt_target_port_sub():rgt_dial_dw(93H),index_w(3bH)
** CLR_ISDN_FLAG IS CALLED **
** LPORT_W = dc0aH **
PK06E10162 PRT CPN num_type == 0, num_plan == 0
create_called_no: size_b 0040H
DIALING_ISDN_TRK: ISDN_DIAL_SENT REDEIVE
<<< cdetect.cpp(1041) Enter cdetector::close() >>>
<<< cdetect.cpp(1130) Enter cdetect::disconnect() >>>
itr_exp_voipu_err_ind():action=1,old_status=00d4
<<< idetect.cpp(4069) iUnitDspCygnus::detectorReport() Resource#0 Released >>>
<<< cdetect.cpp(1541) cdetector::mail() Released resource#0 >>>
cevent_h323 : Alarm Received
<< RECOVER : No.=3CH : P1=0H : P2=0H : P3=0H : ID=3B0H : INDX=0H >>
*** ring_tone_req (L:3C,P:0,T:0,D:0) ***
<<< css.cpp(427) css::ring_tone_req >>> Ringer stop!!
<<< cdetect.cpp(1041) Enter cdetector::close() >>>
<<< cdetect.cpp(1130) Enter cdetect::disconnect() >>>
<<< idetect.cpp(4069) iUnitDspCygnus::detectorReport() Resource#1 Released >>>
<<< cdetect.cpp(1541) cdetector::mail() Released resource#1 >>>
Illegal Selector Found !!!!!!! in GET_DISPLAY
TRK TARGET_DIAL=00000000
hunt_que_del_allstg des_w[dc0a]
== Initialize rgt_port_data memory for port:dc0a
== rgt_port_data_read(dc0a) was 0000
TRK TARGET_DIAL=00000000
cevent_h323 : Alarm Received
<< RECOVER : No.=3CH : P1=0H : P2=0H : P3=0H : ID=3B0H : INDX=0H >>
cevent_h323 : Alarm Received
<< RECOVER : No.=3CH : P1=0H : P2=0H : P3=0H : ID=3B0H : INDX=0H >>
cevent_h323 : Alarm Received
<< RECOVER : No.=3CH : P1=0H : P2=0H : P3=0H : ID=3B0H : INDX=0H >>

Лучше снять трассу программой Wireshark через зеркальный порт.

SIP-транки настроены с Asterisk, находящемся в одной сети с SV8100, смотрели пакеты используя Wireshark, когда такая ситуация возникает Nec вообще ничего не посылает на Asterisk, в случаях прохождения вызовов они видны и в CLI последнего.

В отладчике единственная строка которая указывает на ошибку

itr_exp_voipu_err_ind():action=1,old_status=00d4

Вопрос - что это значит?

.
На этот вопрос точно ответить, наверное, смогут только разработчики NEC.
А какая версия процессора у Вас. Случайно не 3-OT ли. Был грешок на 3 версии, когда в каких сетях по выходу блокировались DSP ресурсы.
А вообще, что при этом происходит: сразу короткие гудки при выходе на транк, или после набора номера, или после тишины, занимается ли клавиша транка или нет. И как потом восстанавливается связь? Может время регистрации (если с регистрацией) на Аsterisk установлено меньше, чем на SV8100 (3600 по умолчанию) и не проходит просто первый вызов после длительной паузы?

Столкнулись с аналогичной проблемой.
Абонент жалуется, что иногда бывает проблема с исходящей связью: набирают номер , но в трубке слышат сигнал занято.
Именно занято сразу при выходе на транк.
Делают еще раз набор через повтор, все срабатывает великолепно.
Смотрели на сети, получается данный вызов дальше АТС ни куда не уходит.
АТС NEC SV8100, по SIPу, с регистрацией.
Процессор EU

File Ver NEC SV8100 R6
Main Software 05.01
DBMS V5.0H
PCPro Server 1.03.0k.pipk
CP00 Revision 7
ME50 Installed
IPL A/32

и точно такая же ошибка:
itr_exp_voipu_err_ind():action=1,old_status=00d4

Точно такую же схему, собираю на SL1000, проблем нет. Все вызовы успешно проходят.

Помогите разобраться, что не так.

выяснили, что данная проблема появляется, когда очень быстро происходит набор.
если набирать медленно, то все великолепно работает.

Может какой то параметр есть, который отвечает за набор.

Схема организации связи следующая:
Выход в город 8-ххх-ххх... (без 9) по f-route

подскажите, что можно подкрутить.
заранее, спасибо