Доброго времени суток.

Дана команда на расчет стоимости проекта поэтому пока без бюджета.

1. В текущем состоянии на предприятии (ЦКБ) существует 3 сети связи. Плюс есть отдельно вынесенная производственная база. Тема про нее была тут http://bbs.radiolink.ru/forum/showthread.php?s=&threadid=27884.

а) Первая сеть городская. На предприятии есть порядка 100 медных пар, из которых 60 сейчас используются как прямые городские.
б) Вторая подсеть - сеть завода соседа с которой подаются внутренние номера, используемые для связи внутри ЦКБ и для связи с сотрудниками завода. До этого момента там стояло какое то барахло координатное, сейчас вводят MD110
в)"Правительственная связь" на какой то мини-АТС для связи генерального с директорами и начальниками отделов.

Текущее состояние и качество заставляет связи заставляет заниматься процессом прокладки оптики для получение потока PRI с городской АТС и Ethernet для доступа в Internet.

Т.е. грубо на предприятии имеем один поток PRI для выхода в городскую сеть связи. Один порт Ethernet для доступа в Internet. Поток или кучу медных пар (пока в решении) со станции завода с MD110 и ISDN BRI интерфейс на удаленной базе.

Как я вижу идеальное решение вопроса:
Закупается оборудование, способное принять в себя и смаршрутизировать как телефонный так и сетевой трафик.
По одному потоку подключаемся к городу, по второму потоку подключаемся в заводу. На базе ставим вынос удовлетворяющий требованиям в теме указанной выше. Вынос подключен с ТФоП через ISDN BRI. Устанавливаем постоянное соединение между базой и ЦКБ в два канала 2х64 кбит для передачи данных, по нему гоняем VoIP для телефонной связи между базой и ЦКБ и сетефой трафик необходимый для обновления некоторых данных на удаленной базе. Теперь вопрос, сколько это будет стоить. Кол-во абонентов в ЦКБ порядка 250. Возможно потребуется построение на базе коммутатора сети Dect для замены "правительственной" связи.

Постораюсь подвести итог.
Нужен средний коммутатор в ЦКБ в котором будет осуществляться коммутация телефонного и сетевого трафика. Он должен суметь подключить вынос на базе, и работать с ним в режиме данных или переменном, данные - телефония. В первом случае вынос общается с коммутатором по VoIP и является шлюзом объединяющим две компьютерные сети, во втором можно видоизменить конструкцию...

Жду Ваших предложений. Если что то не написал или непонятно объяснил прошу простить, голова от других проблемм пухнет.

Тут пойдет любая более менее продвинутая УПАТС.
Всю медь что идет из города заворачиавете в поток.
Медь что идет от соседей так же в поток (уж MD110 с этим как нибудь справиться:)
BRI есть практически на всех станциях.
Так что на выходе у вас получается 250 внутренних, 2 потока PRI, необходимое кол-во BRI, наверное останеться часть двухпроводок под резерв и прямые номера, в перспективе DECT.
С таким объемом кто угодно справиться может, главное чтобы станция обладала нормальными возможностями по маршрутизации вызововпо разным направлениям и все собственно. Так что выбирайте по деньгам и своим предпочтениям.

Товарищу нужно ещё данные коммутировать. Думается, технологию NGN следует внедрять:rolleyes: . "Небольшой, но нафаршированный проект... " Я бы назвал это приятными фантазиями с головой, которая пухнет:) . Мне кажется, скромней надо: связь отдельно, тут уже посоветовали, данные отдельно. А может всё (телефонию) взять от заводского Меридиана? Из-за 250 №№ зачем что-то затевать? А вот LAN организовать.

Bvlad
Тут пойдет любая более менее продвинутая УПАТС.

Не согласен... Разве любая УПАЦ сможет организовать в одном из своих PRI потоков прямое постоянное соединение с абонентом BRI на другом конце города? При этом соединение будет использоваться для передачи данных, часть из которых эта УПАЦ должна отправить в сеть и наоборот из сети отправить нужные данные в это соединение на удаленную базу, так же вычленить из этих данных VoIP с выноса на базе?

valeryk NGN близок по смыслу, но далек от идеи ценой. Да и смысла в нем пока не вижу... Когда сплошь и радом вижу подобные решения в банковской сфере... Ребята гоняют и данные и голос, работают на цисках...

Если постоянное соединение, нафига коммутатор-АТС? Зачем такие сложные соединения? Делайте отдельно.

К сожалению от завода не получиться т.к. это альтернативное решение тому, которое предложил завод... С заводом большие терки и можно в итоге остаться без связи...
Тут больше политики...

Связь отдельно данные отдельно, это второй этап если первый превратится в огромную сумму...

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

В вашем проекте перемешана и перепутана коммутация каналов с коммутацией пакетов imho.
А это две большие разницы.

Задача УПАТС - правильно коммутировать каналы. Вызовы могут приходить с BRI и коммутироваться на PRI, и уходить дальше хоть на другой конец города, хоть в америку.
Но УПАТС, скоммутировав в В-каналы, но никогда не будет анализировать их содержимое, разбираться что там за байты, какие внутри протоколы и адреса и проч. Это принципиально.

Вы можете построить канал передачи данных поверх BRI, но разбираться с этими данными всё равно должены свичи и маршрутизаторы.

PhoneMan
Одно другому мешать не должно :)

В общем описываю приблизительную схему реализованную нашим сбербанком. Есть куча банкоматов с ISDN номерами, часть из них работают в офисах тогда, BRI дробится на части, один канал жестко отдается банкомату, второй отдается под данные и под голос с офиса. На другом конце стоит Cisco в который, приходит PRI банкомат поддерживает полупостоянное соединение с коммутатором, по одному каналу, по второму при необходимости поднимаются то данные (стевой трафик/VoIP для внутренней связи по всей России) или голос, для в зависимости от того, что пришло циска отправляет остатки от PRI либо на УПАЦ, либо в сеть. Решение живое работающее... В принципе почти устраивающее, за исключением некоторых моментов... Один из которых цена.
Как мне известно, не одна Cisco занимается производством подобных решений, тот же Alcatel' предлагает весьма развернутые в плане функционала решения. Начиная от банального свича для коммутации пакетов, кончая УПАЦ с возможностью построения нормальной сети Dect и VoIP.

Anton_Mukhin пишет
Одно другому мешать не должно :)
И не мешает, потому что это разные уровни.
Попробуйте нарисовать то, что описали вначале.

PhoneMan пишет
И не мешает, потому что это разные уровни.
Попробуйте нарисовать то, что описали вначале.

Уже отрисовал, просто отсканировать нет возможности, а рисовать на компе пока нет времени...

Причин по которым работать не должно не вижу, если приводить с схеме как в банках, на входе из города ставиться циска, которая дробит PRI на части,
1. Городские звонки, отправляются в УПАЦ транзитом через тот же PRI,
2. Звонки по VoIP c BRI интерфейса на удаленной базе, тойже циской преобразуются в голос и отправляются в общем потоке на УПАЦ...
3. Данные с BRI интерфейса с базы, отправляются прямиком в сеть ЦКБ. Обратная схема немного сложнее, тк придется анализировать трафик с УПАЦ и нумерацию с базы запихивать в VoIP после чего она уйдет общим потоком на город.

Просто очень не хочется заниматься нагромаждением, если бы была возможность получить красивое моноблочное решение был бы идеал!

Так какое же оно моноблочное, если вы описываете связку из маршрутизатора трафика данных (циско) и телефонной станции (коммутатора телефонных каналов) ?

Почему хочется использовать именно ISDN BRI? А не построить канал xDSL ?

PhoneMan пишет
Так какое же оно моноблочное, если вы описываете связку из маршрутизатора трафика данных (циско) и телефонной станции (коммутатора телефонных каналов) ?

А таких связок разве не существует?
Я просто не в курсе
рынка Мини-АТС.
Собственно я и ищу альтернативы описанному варианту...

Почему хочется использовать именно ISDN BRI? А не построить канал xDSL ?

ADSL по городу за большие деньги и очень паршивого качества т.к. линк не прямой, а BRI паршивая абонентка и очень высокая стабильность. (В банках тоже не дураки сидят, не зря подобный вариант активно используют.)
В общем вариант рассматривали, решили, что пока не нужен.
Т.к. данных пара десятков метров, а звонки в принципе и по двум линиям справятся, но очень хочется объединения офисов.

В каком Вы городе?

valeryk
Недалеко от Москвы, точнее назову в личке если будет объективный интерес :)

Задача УПАТС - правильно коммутировать каналы. Вызовы могут приходить с BRI и коммутироваться на PRI, и уходить дальше хоть на другой конец города, хоть в америку.
Но УПАТС, скоммутировав в В-каналы, но никогда не будет анализировать их содержимое, разбираться что там за байты, какие внутри протоколы и адреса и проч. Это принципиально.

Вы можете построить канал передачи данных поверх BRI, но разбираться с этими данными всё равно должены свичи и маршрутизаторы. [/i][/QUOTE]

Полностью согласен. Более того УПАТС установит так называемое полупостоянное соединение. Т.е. при обрыве связи раутеры которые будут стоять на концах должны в автоматическом режиме его воостановить. Не помню какя модель циски это умеет но умеет точно. Вообще похожее решение работает в ГТК Узбекистана, и народ вроде как не жалуется на устойчивость связи. Там собственно сеть связи таможенных пунктов на этой схеме по этому принципу построена. Из оборудования стоят станции Телрад и маршрутизаторы Циска