подключение chan_h323 к Asterisk 13

[illujanka]

Хоть бы Вы поиском пользовались, чем спрашивать, что ли!
tracelevel=10 в ooh323.conf и перезагрузить канал. Читать не из CLI а из /var/log/asterisk/ooh323.log или что там указано в ooh323.conf

Все именно так и сделано. А размер /var/log/asterisk/ooh323.log - 0б.
Потому и спросила, может еще какие способы есть.

[ded]

tracelevel=10 в ooh323.conf и перезагрузить канал.

Выгрузить, загрузить, /var/log/asterisk/full - - - - - чудеса в другом месте, но не в логах.
Или Вы найдёте ту малость, что делаете неправильно, либо вернуться к редактированию текстов и написанию рефератов. Тоже, между прочим, деньги за работу платят!

[amateur]

core set verbose 10 ?

[illujanka]

Хм...

При осуществлении вызова в h323_log есть какое-нибудь из этих сообщений?
1) Tunneling and h245address provided. Giving preference to Tunneling...
2) Tunneling is disabled for call as H245 address is provided in connect message...

Добрый день!
Извините что долго (рефераты писала )
В логах есть только второй вариант.

[amateur]

Проверила, та же петрушка

Ну теперь кажется ясно. В первый раз все таки драйвер был старый. Что ж Вы сразу не сказали?
Теперь я вижу, что процесс пошел по-новому.

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

11:48:16:913  TerminalCapabilityExchange timeout. (outgoing, ooh323c_o_1)
11:48:16:913  Built TerminalCapabilitySetRelease (outgoing, ooh323c_o_1)
11:48:16:913  Sending H.245 Message = {
11:48:16:913     indication = {
11:48:16:913        terminalCapabilitySetRelease = {
11:48:16:913        }
11:48:16:913     }
11:48:16:913  }
11:48:16:913  Queued H245 messages 1. (outgoing, ooh323c_o_1)
11:48:16:913  msgCtxt Reset? Done (outgoing, ooh323c_o_1)
11:48:16:913  In ooEndCall call state is - OO_CALL_CLEAR (outgoing, ooh323c_o_1)

Кажется про какой-то таймер забыли...

[amateur]

Ладно... Давайте заплатку немного усложним...

[illujanka]

Пока что реакция та же.

[amateur]

Был занят, только сейчас смог посмотреть. Можете еще раз повторить вызов, но кроме h323_log прикрепить еще запись трафика?

[may]

>> 16:36:10:093 Not opening logical channels as Cap exchange remaining
Основная проблема вот здесь.

LG не отправляет никакой реакции на TCS. Ни Reject, ни Ack. Логично, что asterisk не начинает открытие LC без подтверждения capabiities.
То, что не начинался H.245 сеанс при наличии H245 адреса в CONNECT'е решается легко отключением H.245 tunneling'а в сторону LG, патчей для
этого не надо.

А вот почему LG ничего не шлет в ответ на TCS может быть несколько вариантов:

1. и не должен. Почитаю спеку.
2. В TCS asteriska:

16:36:09:993 capability = {
16:36:09:993 receiveAudioCapability = {
16:36:09:994 g711Ulaw64k = {
16:36:09:994 20
16:36:09:994 }
16:36:09:994 }

фрейм - 20мс

В TCS LG:

16:36:10:044 capability = {
16:36:10:044 receiveAndTransmitAudioCapability = {
16:36:10:045 g711Ulaw64k = {
16:36:10:045 60
16:36:10:045 }
16:36:10:045 }
16:36:10:045 }

фрейм - 60мс

возможно LG не нравится фрейм 20мс от опозитной стороны.
В этом случае должна помочь установка на пир LG:

allow=ulaw:60 (стоит скорее всего просто allow=ulaw, что по дефолту 20мс)

Кстати, советую переключиться на кодек alaw (G.711A), с ulaw бывают странности с конвертацией его в другие кодеки, как на астериске,
так и на других голосовых системах.

[amateur]

may, если разговор со мной, то я почти со всем написанным не согласен. Если интересно, раскрою тему. Однако автора темы уже давно не видно, и проверять мои догадки пока не на чем.