asterisk.ru

Да один в один! Уже что только не делали перебрали все новые версии, осталось только по старым пройтись, и Yate попробовать поставить, но с Yate сложнее что то одни проблемы при установке на centos 7 а все что кто то делал это очень давно)

amateur писал(а):

Maloi001 писал(а):если вы самые гениальные его быстро решите

Тут еще два варианта есть:
1) самые гениальные, но решим не быстро.
2) не самые гениальные и быстро решим;
3) не самые гениальные и решим не быстро;

Не два, ещё три! Прекрасно сформулировано!
А если серьёзно, Xenium и Maloi001 - один и тот же стрим из Ульяновска, видимо Xenium сильно обидился, и сказал - "я больше там ничего писать не буду!"

Мы здесь вроде не по этому поводу собрались географию обсуждать! И кто где живёт.

Ded вы бы лучше подсказали в какую сторону дальше смотреть и что можно ещё попробовать для решения этой проблемы. У Вас то опыта в решении таких вопросов на всех здесь хватит.

А вы рекомендацию с отключением autocorking'а попробовали?

Да пробовали он и не включён был.

Maloi001 писал(а): в какую сторону дальше смотреть и что можно ещё попробовать для решения этой проблемы. .

Опыт уже истёрся, из всех щелей, как песок просыпается. Иногда читаю свои реплики на форумах 12-14-ти летней давности - как будто другой человек писал. Уже многого не помню. Да и разработчики - may & amateur, гораздо глубже меня зрят в корень.

may писал(а):А вы рекомендацию с отключением autocorking'а попробовали?

Мне думается вас не туда понесло.

TCP в принципе передает "поток" данных сегментами, размер которых влияет лишь на долю служебной информации в общем объеме передаваемых по каналу данных. Регулировать кол-во TPKT, передаваемых в одном сегменте конечно можно, но любой H.323-стэк является ПОЛЬЗОВАТЕЛЕМ TCP, т.е. работает НАД уровнем TCP, и всей этой нижележащей кухни не знает. Одной из первичных задач H.323-стэка является последовательно выделение TPKT из передаваемого потока(!), и без разницы сколько TCP-сегментов было задействовано для его передачи.

У вас иное представление?

Я бы предложил исследовать мою идею о том, что здесь играет роль порядок/состав сообщений H.225.0:
1. Не нужно отправлять Q.931 PROGRESS после отправки Q.931 ALERTING.
2. Нужно включить h245Address в H.225.0 Connect.

на счет количества TPKT в одном IP пакете и поведения H.323 стека в Avaya ничего сказать не могу, кода не видел, поэтому могу предполагать всё, что угодно.

не отправлять Progress после Alerting'а возможно, многие стеки неверно реагируют на Progress, но большинство таких его просто игнорируют.
включение h245Address в CONNECT не объяснит, почему работают звонки с выключенным debug'ом, там тоже h245Address в CONNECT пакете нет.

добавил создание h245 сессии при генерации пакета Alerting и включение в него h245Address. патч приложен, asterisk надо пересобрать

may писал(а): включение h245Address в CONNECT не объяснит, почему работают звонки с выключенным debug'ом, там тоже h245Address в CONNECT пакете нет.

Ну так сами же пишете:

may писал(а):многие стеки неверно реагируют на Progress, но большинство таких его просто игнорируют.

Когда отладка включена, то
1) Alerting есть, но h245Address в нем НЕТ;
2) в Progress есть h245Address, но он предположительно после Alerting НЕ ВОСПРИНИМАЕТСЯ;
3) в Connect h245Address НЕТ.
Что остается? Facility. Но не все устройства реагируют на Facility с h245Address. Например, CUCM не реагирует.
Поэтому, надо иметь h245Address хотя бы в Connect. Возможно ваш патч для Alerting поможет, но я все-равно не понимаю почему h245Address драйвером chan_ooh323 в Connect не включен.