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

[may]

Ну пожалуйста, выслушать соображения всегда интересно.
Автор отпишется наверное как появится.

[amateur]

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

LG не отправляет никакой реакции на TCS. Ни Reject, ни Ack. Логично, что asterisk не начинает открытие LC без подтверждения capabiities.

Начнем с того, что проблемы как минимум две (а может и больше):
1) chan_ooh323 не переключается из режима туннелирования на отдельный канал H.245;
2) в LG, судя по всему ошибка, т.к. нет ответа на TCS.

Предложенные мной изменения пока ориентированы на исправление проблемы 1). Не знаю насколько они верны. По крайней мере после них отдельный канал H.245 открывается и TCS в сторону LG отправляется.

То, что не начинался H.245 сеанс при наличии H245 адреса в CONNECT'е решается легко отключением H.245 tunneling'а в сторону LG, патчей для
этого не надо.

т.е. Вы это ошибкой chan_ooh323 не считаете?
Мое мнение - если проблема (ошибка) есть, ее надо устранять. Если хотите замалчивать наличие проблемы, то дело Ваше. Мне такой подход видится неправильным.

1. и не должен. Почитаю спеку.

Ну так если уже уверены в том, что "Логично, что asterisk не начинает открытие LC без подтверждения capabiities.", тогда зачем "читать спеку" ?

В общем предположение верное, т.к. в рекомендации H.323 в главе "8.2 Phase B – Initial communication and capability exchange" так и написано:

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

An endpoint which receives a terminalCapabilitySet message from a peer prior to initiating capabilities exchange shall respond as required by 6.2.8.1 and should initiate and successfully complete capabilities exchange with that peer prior to initiating any other procedure.

Имеется в виду, что перед открытием логических каналов должна завершиться процедура обмена возможностями, а завершенной она считается только после ответа на TCS, и ответ должен быть в виде TCSAck или TCSReject. Иначе будет таймаут T101 и отправка TCSRelease.

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

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

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

Это уже чистые измышления, т.к. автор темы привела нам пример успешного вызова, где как раз используется G.711U с размером кадра 20 мс.

В LG однозначно ошибка - нет ответа на TCS. Однако вызвана она на мой взгляд еще одной ошибкой в chan_ooh323 - отсутствием multiplexCapability в TCS. Согласно H.245 "B.2.2 Terminal Capability Set" эта структура должна присутствовать по крайней мере в первом передаваемом TCS:

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

multiplexCapability indicates capabilities relating to multiplexing and network adaptation. A
terminal shall include multiplexCapability in the first TerminalCapabilitySet sent.

Программное обеспечении LG, скорее всего, не анализирует ее наличие перед использованием, считая, что эта структура всегда присутствует в TCS, что и приводит к ошибке и, как следствие, отсутствию ответа на TCS.

[may]

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

LG не отправляет никакой реакции на TCS. Ни Reject, ни Ack. Логично, что asterisk не начинает открытие LC без подтверждения capabiities.

Начнем с того, что проблемы как минимум две (а может и больше):
1) chan_ooh323 не переключается из режима туннелирования на отдельный канал H.245;
2) в LG, судя по всему ошибка, т.к. нет ответа на TCS.

Предложенные мной изменения пока ориентированы на исправление проблемы 1). Не знаю насколько они верны. По крайней мере после них отдельный канал H.245 открывается и TCS в сторону LG отправляется.

То, что не начинался H.245 сеанс при наличии H245 адреса в CONNECT'е решается легко отключением H.245 tunneling'а в сторону LG, патчей для
этого не надо.

т.е. Вы это ошибкой chan_ooh323 не считаете?
Мое мнение - если проблема (ошибка) есть, ее надо устранять. Если хотите замалчивать наличие проблемы, то дело Ваше. Мне такой подход видится неправильным.

Ошибка и устранить надо. Но для решения текущей проблемы достаточно было выключить тунелинг.
Замалчивать проблемы неправильно, соглашусь, и я этого и не предлагал.

1. и не должен. Почитаю спеку.

Ну так если уже уверены в том, что "Логично, что asterisk не начинает открытие LC без подтверждения capabiities.", тогда зачем "читать спеку" ?

Затем, что я мог ошибаться в своём предположении.

В общем предположение верное, т.к. в рекомендации H.323 в главе "8.2 Phase B – Initial communication and capability exchange" так и написано:

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

An endpoint which receives a terminalCapabilitySet message from a peer prior to initiating capabilities exchange shall respond as required by 6.2.8.1 and should initiate and successfully complete capabilities exchange with that peer prior to initiating any other procedure.

Имеется в виду, что перед открытием логических каналов должна завершиться процедура обмена возможностями, а завершенной она считается только после ответа на TCS, и ответ должен быть в виде TCSAck или TCSReject. Иначе будет таймаут T101 и отправка TCSRelease.

Вот именно. В последнем примере и был таймаут, после которого asterisk отправил свой TCS release.

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

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

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

Это уже чистые измышления, т.к. автор темы привела нам пример успешного вызова, где как раз используется G.711U с размером кадра 20 мс.

А где вы увидели успешный вызов? мне кажется если бы он был, автор сообщения уже бы закрыла эту тему.

В LG однозначно ошибка - нет ответа на TCS. Однако вызвана она на мой взгляд еще одной ошибкой в chan_ooh323 - отсутствием multiplexCapability в TCS. Согласно H.245 "B.2.2 Terminal Capability Set" эта структура должна присутствовать по крайней мере в первом передаваемом TCS:

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

multiplexCapability indicates capabilities relating to multiplexing and network adaptation. A
terminal shall include multiplexCapability in the first TerminalCapabilitySet sent.

Программное обеспечении LG, скорее всего, не анализирует ее наличие перед использованием, считая, что эта структура всегда присутствует в TCS, что и приводит к ошибке и, как следствие, отсутствию ответа на TCS.

То, что в LG ошибка, сомнений нет. Возникает вопрос как эту ошибку обойти.
отсутствие multiplexCapability может вызывать ошибку, согласен, но за всё время активной эксплуатации chan_ooh323 (уже почти 7 лет), именно в этом проблемы ни разу не было. А вот с типом capabilities'ов, включая размеры фреймов - были.

[amateur]

Но для решения текущей проблемы достаточно было выключить тунелинг.

Вот типичный подход, способствующий рождению мифов о запредельной сложности и даже о "лампово-транзисторном" происхождении H.323. И как вы думаете с чьей подачи они плодятся? С подачи H.323 разработчиков, отягощенных рыночным подходом при разработке программных продуктов!

Вам не кажется, что Вы поступаете недальновидно и даже нечестно, меняя исходные условия задачи? В том, что оборудование автора темы изначально настроено на использование туннелирования, нет ничего неправомерного. Осознанно автор это сделал или нет - не имеет значения. Это один из возможных способов организации канала H.245, хорошо описанный в рекомендации. Кроме того, в рекомендации не менее хорошо описан способ переключения на отдельный канал H.245, на что я указывал ранее. Мало того, это одна из сильных сторон технологии H.323, позволяющая гибко использовать имеющиеся вычислительные ресурсы и пропускную способность каналов связи. К сожалению, она мало где реализована со всей строгостью и полнотой. Поэтому, осознавая создавшееся положение, я бы использовал данный инцидент для извлечения максимальной общей пользы, а не только для удовлетворения индивидуального запроса.

На что Вы рассчитываете, поступая так? На то, что автор темы, добившись для себя ощутимого результата, не остановится на достигнутом и бросит все силы на поиски истины? Если он следует рыночным принципам, то его и след простынет, если вызовы начнут устанавливаться. Да и Вы, в чем я почти уверен, не будете решать проблему, не имея под рукой испытательного стенда (в данном случае - LG), и главное - не имея руководящего рыночного мотива в виде неудовлетворенного пользователя сопровождаемого Вами продукта.

Проблема останется и дальше все повторится в другое время и в другом месте. Только теперь этому будет дано какое-нибудь другое объяснение. Достаточно зайти на asterisk-support.ru и какой-нибудь горлопан типа meral'а будет вам с пеной у рта доказывать, что H.323 непостижим и т.д., а потому его надо побыстрее выкинуть (раз, два, три).

Замалчивать проблемы неправильно, соглашусь, и я этого и не предлагал.

Да, прямо не предлагали. Но в данном случае Ваш подход косвенно ведет к таком результату.

А где вы увидели успешный вызов? мне кажется если бы он был, автор сообщения уже бы закрыла эту тему.

Чуть раньше я просил автора темы предоставить запись успешного вызова с использованием chan_h323. Файл .pcap был предоставлен. Сейчас файл наверное уже удален, но у меня он остался (прикрепляю).

отсутствие multiplexCapability может вызывать ошибку, согласен, но за всё время активной эксплуатации chan_ooh323 (уже почти 7 лет), именно в этом проблемы ни разу не было. А вот с типом capabilities'ов, включая размеры фреймов - были.

В данном случае какие основания считать, что проблема в capabilityTable, кроме того, что "где-то когда было что-то" ? Еще раз хочу привести контраргумент, что вызов с использованием G.711U:20 был успешно осуществлен. Подтверждение там же - в вышеупомянутом файле с записью обмена между chan_h323 и LG. И то, что отсутствие multiplexCapability - явное нарушение рекомендации.

[ded]

[amateur]

offtopic!!! Модератор, примите меры!

[ded]

Я просто иллюстрирую! Без картинок это очень сухо и академично! А так - даже очинно брутально и эпично! Прямо слышу звуки ударов оружия о латы, топот коней, крики Меркулова с трибуны - "убить обоих нафиг!" и Zavr2008 - "Заменить на Е1 с нашими Alvis!"

[amateur]

Без картинок это очень сухо и академично!

Картинка не в тему. Идет нормальное обсуждения подхода к решению проблем, а не попытка кого-то словесно зарубить насмерть. Стоит ли устраивать спектакль?

[vlego]

amateur, как Вы думаете... если подлючить посредством h323 две одинаковые станции LG (как у этой барышни), они будут работать ? У Вас есть уверенность, что это кто-то в LG дотошно тестировал ? Не появится ли ещё что-то очивидное и невероятное...?

[may]

Но для решения текущей проблемы достаточно было выключить тунелинг.

Вот типичный подход, способствующий рождению мифов о запредельной сложности и даже о "лампово-транзисторном" происхождении H.323. И как вы думаете с чьей подачи они плодятся? С подачи H.323 разработчиков, отягощенных рыночным подходом при разработке программных продуктов!

Не моя тема, я от этого далек, поскольку инженер, а не маркетолог.

Вам не кажется, что Вы поступаете недальновидно и даже нечестно, меняя исходные условия задачи? В том, что оборудование автора темы изначально настроено на использование туннелирования, нет ничего неправомерного. Осознанно автор это сделал или нет - не имеет значения. Это один из возможных способов организации канала H.245, хорошо описанный в рекомендации. Кроме того, в рекомендации не менее хорошо описан способ переключения на отдельный канал H.245, на что я указывал ранее. Мало того, это одна из сильных сторон технологии H.323, позволяющая гибко использовать имеющиеся вычислительные ресурсы и пропускную способность каналов связи. К сожалению, она мало где реализована со всей строгостью и полнотой. Поэтому, осознавая создавшееся положение, я бы использовал данный инцидент для извлечения максимальной общей пользы, а не только для удовлетворения индивидуального запроса.

Ну и пожалуйста, используйте для макс общей пользы. issues.asterisk.org свободно доступен.

На что Вы рассчитываете, поступая так? На то, что автор темы, добившись для себя ощутимого результата, не остановится на достигнутом и бросит все силы на поиски истины? Если он следует рыночным принципам, то его и след простынет, если вызовы начнут устанавливаться. Да и Вы, в чем я почти уверен, не будете решать проблему, не имея под рукой испытательного стенда (в данном случае - LG), и главное - не имея руководящего рыночного мотива в виде неудовлетворенного пользователя сопровождаемого Вами продукта.

Я повторюсь, в рыночных принципах разбираюсь слабовато. не то образование

Проблема останется и дальше все повторится в другое время и в другом месте. Только теперь этому будет дано какое-нибудь другое объяснение. Достаточно зайти на asterisk-support.ru и какой-нибудь горлопан типа meral'а будет вам с пеной у рта доказывать, что H.323 непостижим и т.д., а потому его надо побыстрее выкинуть (раз, два, три).

Всё это тоже неинтересно. Я не участвовал никогда ни в доказательствах сложности H.323, ни в доказательствах обратного.

Замалчивать проблемы неправильно, соглашусь, и я этого и не предлагал.

Да, прямо не предлагали. Но в данном случае Ваш подход косвенно ведет к таком результату.

А где вы увидели успешный вызов? мне кажется если бы он был, автор сообщения уже бы закрыла эту тему.

Чуть раньше я просил автора темы предоставить запись успешного вызова с использованием chan_h323. Файл .pcap был предоставлен. Сейчас файл наверное уже удален, но у меня он остался (прикрепляю).

отсутствие multiplexCapability может вызывать ошибку, согласен, но за всё время активной эксплуатации chan_ooh323 (уже почти 7 лет), именно в этом проблемы ни разу не было. А вот с типом capabilities'ов, включая размеры фреймов - были.

В данном случае какие основания считать, что проблема в capabilityTable, кроме того, что "где-то когда было что-то" ? Еще раз хочу привести контраргумент, что вызов с использованием G.711U:20 был успешно осуществлен. Подтверждение там же - в вышеупомянутом файле с записью обмена между chan_h323 и LG. И то, что отсутствие multiplexCapability - явное нарушение рекомендации.

Да, успешный вызов вижу. Очень вероятно, что вы правы на счет multiplexcapability, но в успешном вызове был еще один нюанс. Там первый TCS со стороны asterisk шел
в parallelH245control, хотя LG скорее всего никак на него не реагировал.
В целом я планирую сделать следующие шаги:

решить минимальными движениями проблему пользователя (если она конечно тут еще появится)
сделать патч на тему h245address и открытия канала, а также по части multiplexCapability
имеется в виду патч, который будет отправлен в master бранч астериска.
вы мне вполне можете в этом помочь.