asterisk.ru

Maloi001 писал(а):Всем привет. А можно узнать в чем же ошибка? Бывает такое и часто.

Честно говоря, я пока не знаю. Я вижу, что не открывается канал H.245, но почему - пока объяснить не могу.

Также, в записи я вижу всякие странности и не понимаю их причину. Например, если судить по по времени записи пакета, H.225.0 Alerting в сторону вызывающей стороны передается даже раньше, чем отправлен SIP INVITE в сторону вызываемой. Проверил в разных версиях Wireshark - так и есть. Тут либо с записью что-то не так, либо... на этом мысль останавливается.

Потом, похоже предложенный разработчиком patch не приложен к драйверу, и мы теперь пытаемся диагностировать его работу, добавляя ко всему прочему уже известную ошибку. Зачем такое счастье?

Кроме того, я вижу, что в сообщение H.225.0 Connect не включен параметр h245Address, хотя канал H.245 на момент его отправки еще не установлен. Судя по спецификации, на ошибку не похоже, но поскольку в большинстве реализаций H.323 куча недоделок, некоторые устройства могут реагировать на h245Address только в конкретных сообщениях. Например, в Alerting - игнорировать, а в Progress, Facility и Connect - использовать. Ну или как -то иначе. Есть пример - CUCM. Если передадите ему в фазе CALL PROCEEDING сообщение Facility, содержащее reason=startH245 и h245Address, то он не отреагирует. С оборудованием Alcatel OXO может быть что-то аналогичное.

Пока моя основная версия такова:
1. Alcatel OXO понимает h245Address только в Alerting, Progress и/или в Connect.
2. В случае с включенным ooh323 set debug сначала отправляется Alerting, а затем Progress.
3. В Alerting h245Address не включен.
4. В ISDN после получения ALERTING сообщение PROGRESS уже не ожидается, и возможно в этом случае игнорируется.
5. В сообщении Connect параметра h245Address нет.
6. Следовательно, у Alcatel OXO нет оснований для открытия канала H.245.

Для проверки надо опять исправлять chan_ooh323, а я уже пытался объяснить, что если ставить своей целью реализацию полноценной поддержки H.323 в Asterisk, то смысла продолжать поддерживать chan_ooh323 нет. Разработчик chan_ooh323 со мной не согласился. Если кому-то интересно, почитайте - https://forum.asterisk.ru/viewtopic.php?p=69043#p69043. Там вся аргументация обеих сторон

Чтобы не изобретать велосипед нужно создавать канальный драйвер на основе "живой" библиотеке. Это может быть модифицированный chan_h323 (можно взять хотя бы мою старую сборку) или принципиально новый драйвер. Может быть chan_h323 - это не образец того, как нужно писать программы, но по крайней мере библиотека H323Plus, на которой он основан, развивается, и позволяет реализовать поддержку H.323 на уровне последней версии спецификации. Библиотека OO H.323 давно не развивается и не может и близко сравниться с H323Plus по своим возможностям.

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

Maloi001 писал(а):Я только увидел в дампе, когда звонок не проходит астериск не видит поднятия трубки и ждёт этот сигнал

Здесь такого нет.

Alcatel не понимает несколько Q.931 пакетов, собранных в один IP пакет.
Вероятно при включенном дебаге проходит больший интервал времени между генераций пакета Progress и Facility Start H.245, поэтому они успевают отправиться в виде двух отдельных IP пакетов.
я посмотрю что можно сделать. В идеале такие проблемы надо писать на issues.asterisk.org, тогда они сразу попадают к разработчику, который "молчит".

Комментируя высказывания уважаемого Amateur, скажу, что chan_h323+любой дериватив open h323, падают под нагрузкой или по uptime.
с моей точки зрения система падающая от 80 одновременных соединений или через 2 дня работы неработоспособна.

А можно в Asterisk указать где то про распределение Progress и Facility в разных сигналах? Или это уже только разработчики канала OOH323 Делают.

попробуйте на системе с астериском сказать:

sysctl net.ipv4.tcp_autocorking=0

и проверить звонок с Avaya.

В Астериске в файле sysctl.conf все закомменчено, а команду которую вы написали, Астериск не выполняет.

эту команду надо выполнить в рутовом шеле на указанной системе, а не в cli asterisk'а

Xenium, я рекомендую пробивать каждый ответ свой через Goggle, чтобы избежать тумаков за некомпетентность.
Вы явно не своим делом занимаетесь, а до этого прокладывали телефонную "лапшу" и меняли картриджи в принтерах? Это не значит, что я не уважаю такой труд, просто то что Вы пишете вызывает порицание.

Xenium просто ошибся и он прав, не астерис ему написал а centos и про который файл вы пишете относится как раз к sysctl.conf и ему написало ошибку что такого файла не существует!

Я конечно изменяюсь за свою некомпетентность но я согласен на платный суппорт по этому вопросу если вы самые гениальные его быстро решите!

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

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

Если серьезно, то я так и не понял какая у Вас проблема. Абсолютная такая же, как у Xenium? Или Вам так кажется?