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

 

[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?? Если есть, то, пожалуйста, пришлите его срочно мне.

[exzerodivide]

Категорически приветствую!

Увы. Решения этой ситуации до сих пор нет, хотя корейцы пытались на нескольких версиях скорректировать эту ситуацию со своей стороны, в том числе и на версии B.0De. Но проблема исходно, ИМХО, вовсе не в MG, а в Панасе!! Не стоит считать Панас "безгрешным". Посмотрите внимательнее, Панас ведь работает кривовато!!

Ну если сравнивать "радиус кривизны" то лыжа панас явно обогнала.

Мне присылали трассировку аналогичного вызова. Там видно, что:
- Панас инициирует вызов как с использованием Fast Start, так и с Early H.245.

И правильно делает. Early H.245 к слову - изобретение корейцев. В стандарте это называется "Initiating H.245 tunneling in parallel with fast connect"

- в станции MG корейцы отказались от поддержки Early H.245, поскольку Fast Start стал более распространенным методом, ИМХО

За окном шел дождь и рота красноармейцев. Early H.245 и FastStart взаимодополняют друг друга. Читай h.323 v.4 параграф 8.2.4 Лучше бы стандарт соблюдали, а не самодеятельностью занимались.

- Вот MG и отвечает тоже с использованием Fast Start (открывает лог. канал OLC)
- Только далее оказывется, что почему-то Панас не хочет работать по FS и начинает запрашивать TCS. Почему, зачем??

Патамучта панас хочет знать UserInputIndication и RTP payload types например, а так же умеет ли шерстяной друг факс по t.38.

Станции уже обменялись "возможностями терминала" в информ. полях FS.

Вот только не надо придумывать. "возможностями терминала" в информ. полях FS. они на FS не обменивались.

- И зачем Панас присылает Status??? Что ему "не понравилось"?? Что его запросили об окончании набора номера (SetupAck)?? Так это согласно протоколу, Панас ведь не прислал Sending Complete.

Выложи дамп, посмотрим вместе.

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

Лучше бы стандарт реализовывали как описано, чесслово. Или взяли тот-же openh323 если сами не могут.