ipecs-100 voip panasonic tde-200 Опции

[Den]

Добрый день нужна помощь в разборе проблемы - 2 станции ipecs-mg и tde-200.

соединены по h.323, связь со стороны ipecsа на тде есть, звонок проходит, все в порядке,
звонок со стороны тде на ипекс, такж е проходит но рвется через 6-7 секунд.

подскажите где искать проблему? трейс снимался с тде, на картинках странности:

Прикрепленные файлы

 ipecs_tde.rar ( 2,08 килобайт ) Кол-во скачиваний: 29
 1.jpg ( 101,52 килобайт ) Кол-во скачиваний: 95
 2.jpg ( 111,84 килобайт ) Кол-во скачиваний: 74

 

[exzerodivide]

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

Код

When H.245 encapsulation or Fast Connect is being used, either endpoint may choose to switch to using the separate H.245 connection at any time. In order to facilitate initiation of the separate H.245 connection by either endpoint, each endpoint may include h245Address in any Q.931 message it sends during the call. If, at the time an endpoint deems it necessary to initiate the separate H.245 connection, it finds that it has not yet received the h245Address of the other endpoint, the endpoint shall transmit a Facility message with a FacilityReason of startH245 and provide its H.245 address in the h245Address element. An endpoint receiving a Facility message with a facilityReason of startH245 which has not already independently initiated the separate H.245 channel shall open the H.245 channel using the h245Address specified. Use of the separate H.245 connection is initiated by opening the H.245 TCP connection and accepted by acknowledgement of the H.245 TCP connection.

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

Код

An endpoint receiving a Facility message with a facilityReason of startH245 which has not already independently initiated the separate H.245 channel shall open the H.245 channel using the h245Address specified. Use of the separate H.245 connection is initiated by opening the H.245 TCP connection and accepted by acknowledgement of the H.245 TCP connection.

отправляет 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 игнорирует, что и приводит к обрыву звонка.

[harris]

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

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