2 PCadach: уже написал test.c echo="Hello world!"?
:) Шутка!
Не делай поддержку Аваевских IP-телефонов. Нет в H.323 многой нужно и полезной чухни типа трансферов, пикапов, и др. Надо бы ему со временем умереть, да побыстрей.
Но гейткипер в * тема интересная, пока ещё наверное актуальная. Мы уже скоро три года как используем связку Аква+chan_h.323, грех жаловаться. Нужно ли от Аквы будет отказываться? Там мониторинг человечный, дебаггинг удобный. Сможешь подобный монитор к своей разработке под линух написать?

2ded: Что есть монитор для гейткипера? Дебагинг и в OpenH323 прекрасный - h.323 trace 5, и устанешь читать... ;-)
Между прочим, трансферы, пикапы и проч. в H.323 есть.

H.323 не умрет по той простой причине, что он практически 1-в-1 ложится поверх ISDN, чего не сказать про другие протоколы. Поэтому если есть желание более-менее корректно передать сигналы ISDN - тут только H.323 справится. Я не беру в расчет различного рода прозрачный тунелинг и проч., которые навешали на SIP и H.323, и которые однозначно не пройдут ни через одну маломальски "интеллектуальную" мини-АТСку.

ded, я с гейткиперами сильно не баловался, посему не мог бы описать требования к функциональности гейткипера, встроенного в Астериск. На данный момент у меня взгляд на эту проблему такой:
1) все звонки идут на Астериск и рутятся Астериском (независимо от того, есть ли зарегистрированный endpoint или нет) - gatekeeper routed модель звонков;
2) пользователи авторизуются по соответствующим им user/peer разделам конфигурационного файла (оттуда берется пароль и проч);
3) gatekeeper обслуживает только пользователей, у которых стоит опция host=dynamic (в противном случае - как обычно).

Вот, в принципе, и всё, что требуется от gatekeeper'а. Или я чего-то пропустил?


WBR,
Paul.

PS: А какие проблемы с Аваевскими телефонами? Тот же skinny, только сбоку H.323. ;-)


WBR,
Paul.

2 PCadach: уточню - конечно же монитор для Астериска (вкупе с Н.323 каналом). Поскольку пока что человеческого монитора нету. Из известных, по возрастающей - astman, gastman, FOP, HUDlite. Каждый имеет свои недостатки, сравнивать-перечислять не буду.

По поводу "корректно передать сигналы ISDN" я поспорю. На сегодняшний день два конкурирующих проекта: mISDN / visdn наилучшим образом передают сигнализацию ISDN в Астериск и назад, без всякой связи с Н.323.

1) + 2) + 3) agree. Но авторизация, надеюсь, не всё? По полной программе - RAS?

По поводу трансферов, пикапов и прочей чухни: ты про Н.450? Так ведь без MCU никуда! А зачем нам лишнее звено в цепочке? Глобально недостатки H.323 по сравнению с SIP:

* Технология H.323 расходует больше времени на установку соединения.
* Технология H.323 требует около 12 пакетов для установки соединения (тогда как для SIP требуется около 4 пакетов).
* Технология H.323 требует и TCP, и UDP во время установки соединения.
* Реализация H.323 намного сложнее реализации SIP.

ded, не надо путать mISDN/vISDN (chan_zap, только вид с боку) и VoIP. При необходимости обеспечить максимально прозрачное прохождение сигналов при схеме
PRI -> Asterisk -> VoIP -> Asterisk -> PRI
только H.323 сможет более-менее адекватно себя повести.

Какая связь между Multipoint Conference Unit (MCU) и H.450 (Supplementary Services)? Никогда не слышал чтобы SS'ки были завязаны на MCU... То, что в Астериске нет ПРАВИЛЬНОЙ поддержки услуг - это факт (правильно услуги работают через RPC, Remote Procedure Call, а у Астериска - через одно место в дайлплане), посему никто ни ISDN'овские SS'ки, ни H.323'и не реализовывает по уму.

Насчет сравнения H.323 и SIP:
1) спорный вопрос. При правильно написанном ASN.1-сериализаторе/десериализаторе H.323 будет даже быстрее раза в 3 чем SIP;
2) это было еще ДО SIP'а. SIP зародился в пору, когда уже во всю был fastStart и H.245 tunneling (а это - как минимум с 1998 года). Установление соединения выглядит как:
H.225:
->Setup(fastStart,H.245 tunneling)
<-Connect(fastStartAck,H.245 tunneling)
<->RTP
->Disconnect
<-Disconnect
Итого - ровно 4 сообщения на соединение (пакетов, наверное, штук 12 и получится);
3) Есть H.323 Annex E (если мне склероз не изменяет), где они UDP предлагают использовать. На самом деле принципиальной разницы между TCP/UDP нет окромя лишнего геммороя с проверкой валидности пакетов, packet aggregation, retransmission, etc. в случае использования UDP (в TCP это делает сам протокольный стек);
4) Это только так кажется. Посмотрите на тот же chan_ooh323 - простой как 3 копейки, если знаешь структуру сообщений (по ASN.1) и как с ASN.1-библиотекой работать.


WBR,
Paul.

"1) + 2) + 3) agree. Но авторизация, надеюсь, не всё? По полной программе - RAS?"

Авторизация на RAS'е то и делается. На H.225 авторизации, скорее всего (или по крайней мере пока) не будет, но H.225 в принципе можно сгонять на гейткипер дабы найти звонок там и заассоциировать их между собой.

Что есть RAS по ПОЛНОЙ программе? Пока что я вижу GRQ/GRJ/GCF (gatekeeper discovery), RRQ/RRJ/RCF (registration), ARQ/ARJ/ACF (call admission), DRQ/DRJ/DCF (disengage). Asterisk никогда bandwidth management'ом не занимался, посему BRQ/BRJ/BCF (bandwidth) - обойдутся.

С LRQ/LRJ/LCF (location) пока не придумал чего делать. Не понятно, нужны ли они вообще.


WBR,
Paul.

PCadach: Вот ты спросил - и сам же ответил, с комментариями:
GRQ/GRJ/GCF
RRQ/RRJ/RCF
ARQ/ARJ/ACF
DRQ/DRJ/DCF
BRQ/BRJ/BCF ; как ни крути, но это и относится к ПОЛНОЙ программе :)
LRQ/LRJ/LCF ; как ни крути, но это тоже относится к ПОЛНОЙ программе :)
Далее ты поступишь как Микеланджело: возьмешь эту глыбу ITU и отсечешь всё лишнее?
А куда относится IRR RAS:InfoRequestResponse?

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

Ув. Zont.
Насколько я понимаю Вы активно используете (как и я) h323в астериск.
Скажите, появляются ли у Вас deadlock-и каналов?
У меня - по несколько штук за час накапливаются "залоченные" каналы.
в результате получаем

*CLI> show channels

0 active channels

16 active calls

WARNING[16515] channel.c: Avoided initial deadlock for '0x83a3940', 10 retries! 

Повторюсь из другого поста - для пользователей, у которых квоты на кол-во звонков установлены астериском это означает невозможность звонить/принимать звонки до рестарта астрериска (который, к слову, из за дедлока делается только через "killall -9 asterisk")
До сих пор никто не может дать вразумительного ответа.
Такое ощущение, что я один с этим мучаюсь.

mthawk, похоже на то. Для прояснения ситуации необходимо как минимум знать версию Астериска и тип используемого H.323-дайвера (chan_h323, chan_oh323, chan_ooh323). Я смогу ответить только по chan_h323.


WBR,
Paul.

ded, в OpenH323 есть встроенная поддержка Gatekeeper'а, ее то я и использую. Соотв., вся функциональность, реализованная там, будет поддерживаться и Астериском. Встает вопрос только в том, что необходимо поддерживать в обязательном порядке, а на что можно и глаза закрыть, оставив обработку всего этого на OpenH323.

IRR - это keep-alive для соединений (звонков).

В любом случае вопрос остается - что в GK-функциональности жизненно необходимо, а что может и подождать до лучших времен. Я описал свою точку зрения на GK для Астериска, теперь жду предложений, поскольку может оказаться, что некоторые сообщения всё-таки придется обрабатывать (меня гложут некоторые сомнения относительно LRQ).


WBR,
Paul.