Объединение OS7100 с KX-TDA30 по H.323?

[LionB]

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

Меняй не глядя на OS7070 http://www.samsung.com/ru/business/communications/switches/office-serv/os7070/index.html не пожалеешь

[eva]

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

Меняй не глядя на OS7070 http://www.samsung.com/ru/business/communications/switches/office-serv/os7070/index.html не пожалеешь

)) +1

[d@vinchi]

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

хотя если копать дальше то в тех скринах которые я выкладывал (на которых пакеты от самсунга в сторону панаса где видно что самунг ставит свой приватный адрес 192.168.1.16) видно что самсунг и порт ставит 10015, т.е. порт не 1720 на котором самсунг должен ждать сигналку... получается самсунг как-бы готов принять дополнительное ТСР соединение на 10015 порту, только адрес не тот шлет...

[LionB]

Батенька - это и есть нетунелированный-прямой H245 порт на это соединение, но только для локалки ... Я ж говорю, чтоб оно на Public пошло, надо с RAD Vison разговаривать и разговор будет... Даже не сомневайся.. А вот каков будет ответ (Ну правда же нет резона работать через публичную сеть с необходимостью открывать целую кучу нестандартных TCP портов.. Да по дороге может быть 5 файерволов и каждый придется уговаривать открывать этот диапазон портов)

[d@vinchi]

Тогда мысли кончаются... Акву вроде тоже невозможно настроить чтобы она с проксировала тунелированный трафик в нетунелированый...

[LionB]

1) Ставить VPN
2) Все-таки выносить Самсунг в Инет (но оператор/ы может у себя на файерах эти порты держать закрытыми)
3) Ждать решения от RAD Vision (но оператор/ы может у себя на файерах эти порты держать закрытыми)
4) Менять TDA30 на OS7070 и вкушать все прелести SPNet

[d@vinchi]

Ну правда же нет резона работать через публичную сеть с необходимостью открывать целую кучу нестандартных TCP портов.. Да по дороге может быть 5 файерволов и каждый придется уговаривать открывать этот диапазон портов

нда, целиком и полностью согласен...
тогда надо думать в сторону средства с возможностью проксирования Н.323 из тунелированного соединения в нетунелированое и обратно...
я сейчас немного переконфигурирую свою тестувую песочницу и попробую поиграться с встроенным фильтром Н.323 в MS ISA Server 2006, который у меня стоит с обоих сторон - есть надежда что этот фильтр делает нужное проксирование... ну или варианты выше...

[LionB]

Всецело мысленно с вами, так как, как сказал, самому интересно найти решение в данном случае..

[d@vinchi]

Результаты ковыряния встроенного фильтра Н.323 на ISA Server 2006:
Сам по себе фильтр проксирования из локальной сети во внешнюю не делает, зато если в нем выключить все сети для прослушивания и настроить акву на проксирование Н.323, то фильтр производит контроль исходящего ТСР соединения на удаленный порт 1720 и анализирует процесс обмена сигнальными сообщениями, динимачески открывая нужные ТСР и UDP порты для дополнительного нетунелированного сигнального ТСР соединения и RTP-медиа каналов. Это решает основной геморой с прохождением Н.323 трафика через ISA...

Таким образом получилось достаточно приемлимо спроксировать Н.323 через ISA Server, НО получилось это только со стороны самсунга , на стороне панаса этот вариант непрокал при идентичных настройках - при звонке с самсунга тишина в обе стороны, хотя по логам на ISA все соединения создались (2 TCP и 2 UDP)... будет время еще поразбираюсь с трассировками... вообще подозрение на то что фильтр Н.323 в исе не просто гонит через себя трафик, анализируя какие порты надо открыть, а еще что-то правит в пакетах и из-за чего панас не может с ним работать...

[d@vinchi]

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