Выложите пож. одинаковые(одна и та же станция при неизменных настройках) с Avaya, Cisco и LIK/ipLDK.
А то разные станции (а их видно по версиям и фирмварям) немного смущают.

Предыдущие трассировки с MG и с Avaya были сняты на одной станции, по крайней мере мы получили их от одного нашего партнера. Во вложении в данном посте снифер трасcировки с LIK, полученный от того же партнера.

Вердикт в двух словах: партнеру незамедлительно выправить руки, особенно сетевикам-затейникам.
Теперь развернуто:
1.Мы видим классический состоявшийся FS между панасом и ликом.
2. По завершению процедуры FS, исходя из того, что у обоих сторон стоит h225.h245Tunnelling = FALSE, панас в соответствии с требованиями стандарта, параграф 8.2.3 Switching to a separate H.245 connection

отправляет facility (пакет номер 81 в дампе) с reason:startH245, при этом поле ipAddress = 192.168.0.103, но адрес, с которого на самом деле шлет панас - 80.69.147.250.
Далее LIK, в соответствии с вышеуказанным параграфом:

отправляет TCP SYN с адреса 61.41.111.85 на адрес 192.168.0.103 порт 10109 (пакет номер 83 в дампе).
Разумеется, это ни к чему не приводит, что подтверждается отсутствием ACKов.
С учетом того, что стандарт не содержит указаний, что делать в таких случаях, панас замирает в таком состоянии и не реагирует на запросы LIK об открытии H.245 (см Connect LIKа).

Так что вывод простой: панас ПЫТАЕТСЯ вести себя, как и в предыдущих снифах, но кривые настройки сети (NAT и т.д.) мешают ему это сделать.

UPD: Если возвращаться к началу разговора то видно, что между панасом и МГ H.245 нормально открывается (startH245->SYN->SYN,ACK->ACK), панас отправляет TCS и MSD, но МГ отвечает только на MSD, TCS игнорирует, что и приводит к обрыву звонка.

ОК. Спасибо.
Запрос по поводу TCS я давным-давно отправил в Корею. Сделали несколько тестовых версий с попытками скорректировать софт, но пока что так и не устранили проблему. Напишем еше раз.

Так все-таки, можно ли для проверки сделать так, чтобы Панас присылал Sending Complete??

Я бы для начала убедился что в настройках у порнослоника действительно стоит en bloc.
Все гайды пишут что у него по дефолту overlap, а при включенном наборе en bloc ом нужно добавлять #.

ИМХО это особо на ситуацию не влияет, но потренироваться можно.

Port No. Settings
H.225 Port No. 1720
H.245 Port No. 1721
RAS Port No. 1719
RTP/RTCP Port No. 5004
Voice CODEC Settings
Voice CODEC Priority
1st G711
2nd none
3rd none
4th none
Gatekeeper Settings
Gatekeeper - Use / Don't use
Primary Gatekeeper IP Address
Primary Gatekeeper Port No.
Secondary Gatekeeper IP Address
Secondary Gatekeeper Port No.
Gatekeeper Connection Checking Interval (min) 0-1440min
Call Signaling Model Direct / Routed (via Gatekeeper)
Others
Fast Connect Use / Don't use
Возможные настройки на панасоник.

Ты прям для сабжевого панаса написал ?

Нашел кстати в закромах родины дамп.
172.16.18.1 - Cisco 2821, инициатор
172.16.18.250 - транслятор имен Display IE <-> H.450
172.16.20.100 - MG 100
Делал год назад примерно.
Что примечательно:
1. Цыска шлет SETUP без SENDING COMPLETE, но с h225.canOverlapSend = FALSE
2. MG присылает SetupAck, но цыска не ругается Status'ом.
3. Цыска инициирует H.245 до коннекта, при этом процедура корректно отрабатывается MG.
4. Единственный баг - на факсе MG переключается с G.729 на G.711 вместо T.38

Так что early h.245 раньше прекрасно работал, сломали где-то по пути.

А какая версия прошивки была на MG?? 1.7 ??

[GS55H17Ai.rom] Html V File Extract Success![745]
[HtmlExtractProcess]extract end
Thu Jun 30 14:45:00 UTC 2011
[SYSLOG ][11/06/30 14:45:38]

[SYSLOG ][11/06/30 14:45:38] ===== START iPECS-MG_SYSTEM =====
[SYSLOG ][11/06/30 14:45:38] Version : iPECS-MG 55M-1.7Ai
[SYSLOG ][11/06/30 14:45:38] Release Date : MAR/11
[SYSLOG ][11/06/30 14:45:38] Working Dir : /
[SYSLOG ][11/06/30 14:45:38] Process ID : (PID 81)
[SYSLOG ][11/06/30 14:45:38] First Main Act2 Init-Complete Ver(1.1)

ОК. Спасибо!

Сейчас скажу оффтопом:
НИКОГДА, НИКОГДА не используйте H.323 протокол для связки LG с обордованием отличным от LG, иначе будут прекрасные танцы с бубном проще всего использовать протокол SIP, и еще лучше связать данные станции через промежуточный Asterisk учстановленный гденибудь на виртуалке. Кстати панас с Астером по H.323 вроде живет нормально, LG вроде тоже работает, но есть проблемы, результат - перевели все на SIP.

Так вроде? Или живёт?

Вместо офтопа специалист излагает конкретные факты, того что не так.
Если не может сам то обращается к специалистам, вам насколько мне известно, предлагалась помощь, однако вы скомпрометировали того кто пытался вам помочь, а теперь делаете тоже самое с производителем станций.

Согласен на все 100! К сожалению, неквалифицированная установка, зачастую, создает негативное отношение к оборудованию в целом! Легче всего свалить все на оборудование, чем признаваться(особенно перед заказчиком), что не знаешь каких то тонкостей настройки данного оборудования.
А совсем уж идеальных железок нет...

Ничего подобного. У меня в связке через 2821 работали: CUCM 6, ipLDK-300 и MG-100 по h.323 с сетевым планом. Единственное, что потребовало доработки - имена абонентов между лыжей и не-лыжей.
Так что - дорогу осилит идущий, все проблемы решаемы, тем более - при наличии опенсорсного астера.

Я и не говорил что работать не будет, работать будет, но пляски с бубном обеспечены H.323 очень специфический протокол и разные вендоры его реализуют хрен пойми как в отличии от SIP, с которым тоже проблемы есть но гораздо меньшие.

Для любой задачи каждый сам решает какое количество услий необходимо потратить, в нашем случае было проще изучить Asterisk и сменить протокол на SIP. От себя добавлю, что лучше связки чем iPECS--Asterisk я еще не видел, они прекрасно дополняют друг друга, и следующая станция которую я буду брать именно iPECS.
А (ИМХО) H.323 прекарсный протокол, но он в действительности отлично работает между оборудованием одного вендора, тем не менее все настраивается и с Panasonic возможно работать будет и с Avaya работает, но он устарел этот протокол и крупные вендоры врядли будут дорабатывать реализацию.
LG с Asterisk по H.323 работает ужасно и хотя были найдены некоторые пути решения, они также не дали в конечном итоге жалаемого результата.

Дополню. НИКОГДА, НИКОГДА не связывайтесь с Астериском . Иначе вся ваша дальнейшая деятельность будет сводится к тому, чтоб только поддерживать его работоспособность. А если еще он и в открытом доступе в интернете, то защита от злоумышленников будет съедать львиную долю вашего времени.

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