asterisk.ru

но ведь

GateKeeper connection state:
Gatekeeper: 88.21.255.160
GK state: Registered

# nmap 88.21.255.160 -p 1719-1720 -sU

ddkprog писал(а):и да, gatekeeper работает по udp а не tcp

ну да, видно там

ded, эту тему тоже "в фигурные скобочки" ? На мой взгляд она очень наглядно отражает уровень понимания технологии H.323 в т.ч. тобой Главное - она отражает популярный метод решения "технических задач", которые ставятся на данном и на прочих форумах.

GRQ/RRQ и т.д. - это H.225.0 RAS. В самом распространенном случае (я не знаю ни одного другого примера) транспортом для H.225.0 RAS служит протокол UDP. Стандартный порт - 1719. К Q.931 эти сообщения не имеют ровным счетом никакого отношения. Зачем человека посылать в неверном направлении? Он ведь может по наивности довериться авторитету "посылающего"...

davidjonson, в chan_ooh323 сообщение "Error:Gatekeeper could not be found" появляется по истечению времени ожидания ответа на сообщение GRQ. Однако непонятно каким образом у Вас получается "GK state: Registered", и зачем после регистрации повторно отсылается GRQ. Возможно мы имеем дело с ошибкой в программном коде. В вашем случае из конфигурации и отладочной информации в журнале Asterisk уже ничего больше не выудить. Необходим анализ содержания сообщений H.225.0 RAS. Вместо того, чтобы несколько раз констатировать факт наличия этих сообщений, запишите их в файл (tcpdump -s 0 -w <файл>.pcap) и предъявите их тем, к кому Вы обращаетесь за помощью.

В общем, перестаньте заниматься ерундой и включите голову, а не то окажетесь в тесных объятиях торгашей, "впаривающих Вам единственное верное решение".

За все методы не скажу, а за свои - да. nmap

ded писал(а): nmap 88.21.255.160 -p 1719-1720 -sU

& tcpdump host 88.21.255.160 дают первичное понимание - порты открыты в направлении Астериска? Трафик и обмен пакетами присутствует? Первое вхождение в проблему показало: нет, трафик бегал в никуда, потому что не с того интерфейса.
А потом по тому же методу - следующая ступень:

ded писал(а): Вам надо изучать Q.931 запросы к гейткиперу на регистрацию и ответы:
Gatekeeper request, reject and confirm messages (GRx)
Registration request, reject and confirm messages (RRx)

Ошибся, думал одно, писал другое. Правильно надо было так: Вам надо изучать Н.225 запросы к гейткиперу на регистрацию и ответы
Н.323 не ковырял уже скоро 8 лет как, всё осталось на уровне Aqua Gatekeeper & Infinet.
В остальном же по Н.323 и Н.225.0 RAS для ТС всё достаточно популярно описано по приведённой ссылке
http://en.wikipedia.org/wiki/H.323
На этом этапе видно, что раскуривание перетекло за 2 страницы топика, обучать ТС как снимать дампы и анализировать GRQ & GRR задача неподъёмная, поэтому мои рекомендации были - платный суппорт.
Ничего из этого метода мне не кажется неверным.

ded писал(а):Ничего из этого метода мне не кажется неверным.

Он верный, если есть потребность перевести техническую дискуссию в коммерческое поле. Однако есть тонкости, которые проявляются лишь при добросовестном изучении вопроса. С одной стороны автор действительно не проявил должной сообразительности после того, как раскуривание перетекло за 2 страницы топика, практически повторяя одно и то же в нескольких сообщениях. С другой стороны следует задать вопрос: "А было ли раскуривание направлено только на обучение или преследовало иные цели?". Очевидно, что одним из необходимых условий обучения является то, что обучающий должен обладать большим знанием относительно обучаемого в исследуемой теме. Однако для того, чтобы добиться цели, т.е. повысить знание обучаемого, эти знания должны также передаваться без искажений и в доступной обучаемому форме. Проще говоря, взялись обучать, хотя бы сами не "врите" и не усложняйте вопрос.

В результате имеем:

1. Совет выполнить nmap 88.21.255.160 -p 1719-1720 -sU появился только сегодня, а теме уже три дня. До этого был nmap 88.21.255.160, который нам ничем не поможет, т.к. по умолчанию проверяет TCP, а не нужный нам UDP. Кстати, указание диапазона 1719-1720 выдает тебя как тыкающегося наугад, т.к. порт TCP 1720 используется для H.225.0 CallSignalling

2. Фраза "Вы наверное не в курсе, что Н.323 не любит NAT", сказанная аж два раза, никак не служит целям познания истины. Во-первых, если весь H.323 не любит NAT, то каким же образом работает AddPac AP700? Получается, что либо H.323 "любит" NAT либо NAT там нет. Ну а во-вторых, это не "H.323 не любит NAT", а поддержка NAT не реализована в большинстве H.323-устройств (в т.ч. в канальных драйверах Asterisk) по причинам не связанным с самой технологией. Мода сменилась, толпа "ломанулась" за модой. Прежние наработки бросили.

Собственно говоря, так и создаются мифы. Один сказал не подумав, другой не критически отнесся к сказанному, а третий был вообще не в себе и стал бурно выражать свои эмоции по поводу услышанного. Поскольку критическое мышление требует умственных усилий, т.е. труда, а труд большинством представителей общества считается "божьим проклятьем", то по прошествии некоторого кол-ва времени при включенном "сарафанном радио" будем иметь устойчивое мнение большинства о том, что H.323 - это что-то отсталое (даже про NAT не знает).

3. Нет смысла выполнять netstat -nlp | grep 1720, т.к. без открытия порта на прослушивание модуль chan_ooh323 вообще бы не загрузился. Очевидно, что автор уже прошел дальше.

ded, не кажется ли тебе, что после всего этого топтания на месте предлагать "платный суппорт" неэтично?

Отвечаю: у меня нет желания переводить техническую дискуссию в коммерческое поле, я не предлагаю себя в качестве платного суппорта. Часто писал даже: "В платный суппорт (это не я)." Тут достаточно желающих оказать такие услуги. Могу сказать также, что я не всегда корректен, не всегда прав, и не считаю себя за гуру (есть ещё много пунктов самоуничижения, сейчас все не упомню), раздражителен по мелочам, болезненно реагирую на добрых уток, оверквотинг, и ещё многое чего. Стараюсь в себе эти недостатки изжить, борюсь, одним словом, не всегда эффективно.
по пунктам:
1. не брался и не имел цели обучать ТС. Общая цель обычно одна - помочь с одной-двух подач, при этом ТС проявляется самым простым способом: от уровня знаний по технологиям, в которые ввязался, до чисто человеческих качеств. Я при этом - тоже
2.

Ну а во-вторых, это не "H.323 не любит NAT", а поддержка NAT не реализована в большинстве H.323-устройств (в т.ч. в канальных драйверах Asterisk) по причинам не связанным с самой технологией.

Верно, корректный ответ "H.323 не любит NAT" подразумевает именно такую расширенную форму - поддержка NAT не реализована в большинстве H.323-устройств (в т.ч. в канальных драйверах Asterisk) по причинам не связанным с самой технологией. В краткой форме - скорее нет, чем да.

Могу выдохнуть?

3. Cмысл выполнять netstat -nlp | grep 1720 есть, если видно что bind 0.0.0.0 и два или более интерфейса - уже есть понимание, что запросы GRR могут пойти не с того интерфейса, и нужно в конфиге забиндить на правильный.

amateur писал(а):
davidjonson, в chan_ooh323 сообщение "Error:Gatekeeper could not be found" появляется по истечению времени ожидания ответа на сообщение GRQ. Однако непонятно каким образом у Вас получается "GK state: Registered", и зачем после регистрации повторно отсылается GRQ. Вместо того, чтобы несколько раз констатировать факт наличия этих сообщений, запишите их в файл (tcpdump -s 0 -w <файл>.pcap) и предъявите их тем, к кому Вы обращаетесь за помощью.

Спасибо за подсказку. Приступил к изучению.

ddkprog писал(а):опция tracelevel=7 не активирована, лога нет
и расширеный модуль ooh323 соберите, в папочку /ooh323c/ зайдите и наберите make opt && make install
только астериск перед этим остановите
и да, gatekeeper работает по udp а не tcp

спасибо, попробую.

этот модуль из аддонов. если я правильно понял ситуацию, то пересобрать не получится.