приколы AudioCodes MP118 FXO

[SVoy]

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

Ситуация следующая:
- приходит входящий с ТфОП
- шлюз добросовестно звонит на заданный IP номер
- но, уже через 5 сек присылает Cancel
- АТС перестает вызывать абонента, а звонящий продолжает слушать КПВ
- через 20 с шлюз, замученный совестью опять шлет инвайт, но уже через 5 сек отменяет его..
- так продолжается пока звонящий не положит трубочку

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

Кто, что может подсказать по данному вопиющему случаю..

[ded]

Такое бывает при включении оператором
- переполюсовки (как средство доп. тарификации)
- CallerID (FSK)

И то и другое дебажится на шлюзе и устраняется (теоретически).

[SVoy]

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

услуга CallerID включена давно.

пока склоняюсь к версии сбоя в прошивке, но хотелось бы знать это наверняка

вот лог в момент отсылки Cancel, причин для этого не вижу

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

1d:0h:47m:23s ( lgr_flow)(2935 ) ---- Incoming SIP Message from 192.168.1.100:5060 ----
1d:0h:47m:23s SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.90.22;branch=z9hG4bKac708086177;received=192.168.90.22
From: <sip:443238888@192.168.101.22>;tag=1c708081760
To: <sip:0005@192.168.1.100;user=phone>;tag=as3eab5223
Call-ID: 70807768011200004723@192.168.90.22
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact: <sip:0005@192.168.1.100>
Content-Length: 0

1d:0h:47m:23s ( lgr_flow)(2937 ) | |(SIPTU#12)180 State:Proceeding(70807768011200004723@192.168.90.22)
1d:0h:47m:23s ( lgr_flow)(2938 ) | | | #0:SIP_ALERT_EV(70807768011200004723@192.168.90.22)
1d:0h:47m:23s ( lgr_stk_ses)(2939 ) <SESSION #0> SendToCall - event: PROGRESS_INDICATOR_EV m_Call = 31518712
1d:0h:47m:23s ( lgr_flow)(2940 ) | | #0:PROGRESS_INDICATOR_EV(PI=-1)(PC=-1):(70807768011200004723@192.168.90.22)
1d:0h:47m:23s ( lgr_stk_ses)(2941 ) <SESSION #0> SendToCall - event: ALERT m_Call = 31518712
1d:0h:47m:23s ( lgr_flow)(2942 ) | | #0:ALERT:(70807768011200004723@192.168.90.22)
1d:0h:47m:23s ( lgr_flow)(2943 ) | | #0:Call changing states from:InitiatedState_Tel2IP to:AlertingState_Tel2IP
1d:0h:47m:23s ( lgr_flow)(2944 ) | #3:ALERT : (70807768011200004723@192.168.90.22)
1d:0h:47m:23s ( lgr_flow)(2945 ) | |(SIPTU#12)PRACK_REQ State:Proceeding(70807768011200004723@192.168.90.22)
1d:0h:47m:23s ( lgr_psbrdex)(2946 ) recv <-- ANALOG_IF_RING_START Ch:3 type(0)

[SVoy]

"эврика"(с:) - увеличил Ring Detection Timeout с 5 до 10 секунд, правда теперь задержка перед началом вызова и отбоем выросла..

похоже ded частично прав с возможным изменением Caller ID

Ring Detection Timeout [seconds]: Ring Detection Timeout is used in conjunction with inbound caller ID detection. If Caller ID is enabled, then the FXO gateway seizes the line after detection of the second ring signal (allowing detection of caller ID, sent between the first and the second rings). If the second ring signal doesn't arrive for Ring Detection Timeout, the gateway doesn't initiate a call to IP. The default setting is 8 seconds.

правда по этому описанию звонка вообще бы не было, в моем же случае он был, но отбивался спустя время подозрительно равное длине таймаута.. Хотя в данной железке настолько много тонких подстроек, что разобраться на 100% мне не по силам.. тем более перед праздниками:)