DG104SH
Рассыпается соединение через 10-12 секунд
В чем грабли?
А что вот это значит:
000095727 HSMU RX RTCP DATA ERROR: ?rtcp pkt type=0
000096090 HSMU RX RTCP DATA ERROR: ?rtcp pkt type=0
000096688 HSMU RX RTCP DATA ERROR: ?rtcp pkt type=53
???
Спасибо.

Версии прошивок, схема сети, настройки и т.д?

На эти ошибки не обращайте внимания, они не влияют на звонок.

_________________
С уважением,
Виктор Колосов

Версии прошивок последние (те, что написаны в форуме)
Схема:
104SH->AquaGatekeeper->Cisco (разные от 827-4V до 53XX)
В гейткипере игрался настройками connectoin validity (от 10-ти секунд до unlimited) - ничего не меняется.
Какие именно настройки еще надо?
Кодек - g723_53
104 настроена слэйвом
Фаст старт включен (без него вообще коннект не происходит)
Все, что набирается, отправляется на гейткипер
Вот, настройка tcid и coding
ggdbg>show tcid 0

Configuration for TCID 0:

Mode: Switched CAS
Pref Voice coding profile: 3
Pref Fax coding profile: 6
Pref Modem coding profile: 0
Pref Data coding profile: 0
Allowed Coding Prof Ids\Call Caps: (x - y means x to y both inclusive)
Coding prof: 0-127. Call cap: 0- 63.


Telephony Interface Configuration:
Companding = Mu-Law
Gain (RX,TX) = (-2,-4)
Idle noise level = -6500 x .01 dB
Call Progress Tone Detection Control = As per coding profile
Call Progress Tone Detection Configuration = Default

Signaling Protocol: FXS Loop Start

FXS Loop Start Parameters:
Offhook Debounce: 50 msec
Onhook Debounce: 50 msec
Seize Detect: 100 msec
Originator Clear Detect: 450 msec
Answering Party Clear Detect: 150 msec
CPC Wait: 200 msec
CPC Duration: 850 msec
Ring Id: Default (-1)
Caller Id Generation: ON

Dial Out Parameters:
Out Wait: 250 msec
Out Type: tone
Tone Out Off Time: 100 msec
Tone Out On Time: 100 msec
Tone Out Power: -130 x 0.1 dB (not configurable)

Dial In Parameters:
Plar addr: None

Call Timing Parameters:
Call Limit: forever
Answer Wait: forever
Hangup Wait: forever
Fax Holdover: 2000 msec

Echo Cancellation Parameters:
Mode: LINE
Output: HANDS FREE

V.18A Tone Detect Parameters:
Hangover: 0
Threshold: 0
Fraction: 0

SS7 COT Tone Detect Parameters:
Hangover: 0
Threshold: 0
Fraction: 0

Single Frequency Signaling Tone Detect Parameters:
Hangover: 0
Threshold: 0
Fraction: 0

Tone Table:
Default

Caller ID Parameters:
Caller ID Number: 70842171171
Caller ID Name: tcid0

Prefer Codec:
g723_53

CODING
ggdbg>show coding 3

Configuration for coding profile id 3:
Tx Coding = G723 5.3 kbps
Rx Coding = G723 5.3 kbps
Coding profile for voice

Tx VIF size = 192 (bits)
Rx VIF size = 192 (bits)
VAD = Disabled
VAD threshold = 0 (dB) (relative to ref level of -30dBm)
Playout nominal delay = 60 (msec)
Playout maximum delay = 120 (msec)
Playout minimum delay = 0 (msec)
Adaptive Playout = Adjust immediately
Rate = 14400
DTMF Relay = Disabled
Tone detect = Enabled
Call Progress Tone detect = Enabled
V.18 Tone detect = Enabled
SS7 COT Tone detect = Enabled
SF Sig Tone detect = Enabled
EC = Enabled
EC NL = Enabled
EC NL Sens = 327
EC Tail = 8 (msec)
EC Refresh = Update
EC Coeffs = Normal
EC Auto Update = Disabled
EC Auto Search = Disabled
EC Search Freeze = Disabled
Modem TX level = 0 (dB)
Modem CD threshold = 0
Modem no activity timeout = 0 (sec)

Caller ID Support = Enabled

Resampling = Enabled
EC Config = NLP_FIXED
NLP Confort Noise = 65486

SID Retx Rate = 0

Encapsulation = RTP
Tx ssrc = 0
Tx start timestamp = 0
Rx ssrc = 0
Rx start timestamp = 0
Tx digit payload = 0
Rx digit payload = 0
Digit repetitions = 3
Secondary Decoder = Disabled

Попробуйте на циске выполнить команду:

h245 tunnel disable

_________________
С уважением,
Виктор Колосов

К сожалению, не помогает.
Ну, точнее, h245 tunneling я отключаю на AquaGatekepere именно для данного абонента. Он, насколько я знаю, делает это корректно.
Может быть есть еще какие-то мысли?

Циска в колл-хистори рисует - (recovery on timer expiry (102)
Эт значит что она чегой-то не получает от удаленной стороны. Я так понимаю.
А вот что ей надо - пока понять не могу....
Может еще у кого мысли есть???

А если без использования кипера? отключите на самой циске.

_________________
С уважением,
Виктор Колосов

Ну вот попробовал без кипера.
Уж и не знаю насколько это все прально, но вот что получил:
000040339 HSMU: Enter call_profile->capabilities
000040339 HSMU: t.38 codec found at profile 6
000040339 HSMU: Exit call_profile->capabilities.
000040339 HSMU 6: Process outgoing H.323 Fast Start call.
000040339 Dialing DEST = TA:10.10.10.10:1720,TEL:001
000040339 SOURCE = NAME:70842171171,TEL:70842171171
000040339 USER_TO_USER = CID_NAME:tcid0, CID_NUM:70842171171 SETUP
000040339 hsmup_open_rtp_sockets: nw_open(RTP1), port=1731, call_num=6
000040339 hsmup_open_rtp_sockets: nw_open(RTCP2), call_num=6, port=1732
000040351 HSMU 6: set timer for 50000 in state hsmup_state_h225_wait_alerting
000040359 HSMU 6: abort timer in state hsmup_state_h225_wait_alerting
000040359 HSMU 6: H.323 release (IF)
000040411 HSMU 6: voice rtp open=1, rtcp open=1, nw_close(voice socked RTP1, RTCP2)
000040411 HSMU 6: nw_close(inchan local RTCP65535, RTP65535)
000040411 HSMU 6: nw_close(inchan local RTCP65535, RTP65535)
000040411 HSMU 6: nw_close(inchan local RTCP65535, RTP65535)
000040411 HSMU 6: nw_close(inchan local RTCP65535, RTP65535)
000040411 HSMU 6: nw_close(outchan local RTCP65535)
000040411 HSMU 6: nw_close(outchan local RTCP65535)
000040411 HSMU 6: nw_close(outchan local RTCP65535)
000040411 HSMU 6: nw_close(outchan local RTCP65535)

Уж не знаю что это все значит...
А что до кипера - так в его логах по-честному пишется:
05/05/2004 19:03:10 Q.931, 0x08417700, got message from callee: OO at 195.112.98.123:1720
05/05/2004 19:03:10 Type: ReleaseComplete(0x5a)
05/05/2004 19:03:10 ProtocolDiscriminator : 8
05/05/2004 19:03:10 Call Reference: length (in octets): 2, value (in hex): 73 3F , flag: 1 - destination side
05/05/2004 19:03:10 Contains 2 elements
05/05/2004 19:03:10 [Cause] (0x8)
05/05/2004 19:03:10 Coding Standard: CCITT standardized coding, as described below (0)
05/05/2004 19:03:10 Location: user (0)
05/05/2004 19:03:10 Recommendation: Q.931 (0)
05/05/2004 19:03:10 Value: Recovery on timer expiry (102)
05/05/2004 19:03:10 [UserUser] (0x7e)
05/05/2004 19:03:10 Protocol Discriminator: 5
05/05/2004 19:03:10 User-User {
05/05/2004 19:03:10 H323_uu_pdu {
05/05/2004 19:03:10 H323_message_body ReleaseComplete {
05/05/2004 19:03:10 ProtocolIdentifier: { 0, 0, 8, 2250, 0, 4 }
05/05/2004 19:03:10 CallIdentifier {
05/05/2004 19:03:10 Guid: 16 octets [02 B2 1E 12 33 15 31 32 3A 99 56 34 34 34 34 EF]
05/05/2004 19:03:10 }
05/05/2004 19:03:10 }
05/05/2004 19:03:10 H245Tunneling: false
05/05/2004 19:03:10 }
05/05/2004 19:03:10 }

Т.е. туннелинг отключен. Это лог вчера вечером делал. Когда через кипер звонил.

Посмотри логи по билингу...если разрыв на 15 секунде то я для себя лечение нашел только в одном...
factory reset полная настройка за исключением настройки tcid (присвоение им номеров)
Все работает , правда пришлось отказаться от входящих звонков... но мне это и не критично....
Если тебе это нужно то другого решения я не знаю

Пасиб! На самом деле рассыпание было по причине того, что циска-таки слала h245 запросы на д-линк. А он, собака женского рода, ну совершенно ничего на них не отвечал. Ну нет бы ответить типа не знаю ничего - отвали. Он молчит. Циска после этого запроса взводит таймер и по истечение его отваливает.
Когда наглухо завалил h245 на циске - все стало нормально.
А вот с входящей связью так и не разобрался. Уж сколько фактори ресетов не делал - ничего не помогает...
Сейчас добился максимум того, что звонок входящий на аппарат проходит, но тут же отваливается. При чем отвал приходит от д-линка и дисконнект-текст почему-то нормал колл клиринг... Т.е. д-линк почему-то считает что вызов этот надо завалить. И считает это нормальным.
Ежели кто знает в чем дело (может таймер какой подправить в д-линке надо) - напишите что ли...

У меня хуже - валит именно на 15 секунде, причём не по всем направлениям.
Кратко: DG-104SH подключен через гейткипер (GnuGK) к оператору IP-телефонии. Так вот на некоторых направлениях всегда рубит на 15 секунде, на других - замечательно работает. У оператора софтсвитч, так что вызов отрабатывают разные шлюзы.

В логах GnuGK наблюдается вот что:
2004/05/20 18:48:42.410 5 ProxyThread.cxx(354) H245s Reading from 195.42.150.2:59103
2004/05/20 18:48:42.418 4 ProxyChannel.cxx(1473) H245 Received: request terminalCapabilitySet {
... много параметров поскипано ...
}
... много записей поскипано, разговор идёт нормальный ...
2004/05/20 18:48:57.247 5 ProxyThread.cxx(354) H245s Reading from 195.42.150.2:59103
2004/05/20 18:48:57.247 4 ProxyChannel.cxx(1473) H245 Received: indication terminalCapabilitySetRelease {
}
2004/05/20 18:48:57.247 4 ProxyChannel.cxx(1534) H245 Indication: terminalCapabilitySetRelease
...
2004/05/20 18:48:57.282 4 ProxyThread.cxx(659) ProxyH(0) 1 sockets selected from 4, total 4/0
2004/05/20 18:48:57.282 5 ProxyThread.cxx(354) Q931d Reading from 195.42.150.2:1720
2004/05/20 18:48:57.282 3 ProxyChannel.cxx(417) Q931d Received: ReleaseComplete CRV=515 from 195.42.150.2:1720

После чего наступает отключение.
h245Tunneling всегда FALSE.

Значит у тя нет выхода, кроме как просить оператора на всех шлюзах закрывать h245... Создают отдельный префиск для тебя и на диал-пиры с таки префиксом привязывают войс-класс...

Но есть куча операторов у которых обсолютно разные циски... на всех настраивать замучаешся...
Так что у меня тоже самое...причем действительно на одних операторов все ок ...на других 15 сек и все...
Если оператор откажется(найдется кто и откажется) то сделай как я сказал и звонки точно пойдут (проверенно на 8 шлюзах)