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

[Den]

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

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

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

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

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

 

[Fray]

Вечер добрый.
Есть ли решение для данной проблемы? На версии MG100 B0De (voip на mpb) и TDE100 5.0203 тоже самое ((( кстати c LIK связка нормальная.
Кому интересно вот ответ PANASONIC по данной проблеме:
TDE шлёт сообщение TCS (terminal capability set, набор возможностей терминала), MG данное сообщение игнорирует, и TDE по истечении таймера сессию рвёт.
Или в оригинале:
We think that the problem will be the design of LG IPECS for the specific call-connection process. We can not understand why LG IPECS can not send the response to terminalCapabilitySet message even if it can respond to masterSlaveDetermination. I recommend you to ask the update of their software. It may be the known issue in some cases.

[harris]

Вечер добрый.
Есть ли решение для данной проблемы? На версии MG100 B0De (voip на mpb) и TDE100 5.0203 тоже самое ((( кстати c LIK связка нормальная.
Кому интересно вот ответ PANASONIC по данной проблеме:
TDE шлёт сообщение TCS (terminal capability set, набор возможностей терминала), MG данное сообщение игнорирует, и TDE по истечении таймера сессию рвёт.
Или в оригинале:
We think that the problem will be the design of LG IPECS for the specific call-connection process. We can not understand why LG IPECS can not send the response to terminalCapabilitySet message even if it can respond to masterSlaveDetermination. I recommend you to ask the update of their software. It may be the known issue in some cases.

Увы. Решения этой ситуации до сих пор нет, хотя корейцы пытались на нескольких версиях скорректировать эту ситуацию со своей стороны, в том числе и на версии B.0De. Но проблема исходно, ИМХО, вовсе не в MG, а в Панасе!! Не стоит считать Панас "безгрешным". Посмотрите внимательнее, Панас ведь работает кривовато!!
Мне присылали трассировку аналогичного вызова. Там видно, что:
- Панас инициирует вызов как с использованием Fast Start, так и с Early H.245.
- в станции MG корейцы отказались от поддержки Early H.245, поскольку Fast Start стал более распространенным методом, ИМХО.
- Вот MG и отвечает тоже с использованием Fast Start (открывает лог. канал OLC)
- Только далее оказывется, что почему-то Панас не хочет работать по FS и начинает запрашивать TCS. Почему, зачем?? Станции уже обменялись "возможностями терминала" в информ. полях FS.
- И зачем Панас присылает Status??? Что ему "не понравилось"?? Что его запросили об окончании набора номера (SetupAck)?? Так это согласно протоколу, Панас ведь не прислал Sending Complete.

Но пока корейцы еще продолжают заниматься этой задачей (запрос по этой проблеме еще не снят).
Кстати, а у Вас есть снифер входящего вызова на MG, снятый именно на версии B.0De?? Если есть, то, пожалуйста, пришлите его срочно мне.