Тема: 500 + 500 по Pri

По хорошему, такой прект нужно делать на более развитом обрудовании Алкотель, Сименс, Ерикссон или NEC с применением их фирменных сетевых протоколов. Тогда вся сеть будет администриться с одного места как единая система.

Или LG LDK например, без всяких фирменных протоколов, но QSIG работает, правда если 6 PRI это уже нужна CS-1000 и главное все значительно дешевле и функциональнее

А как насчёт администрирования и SMDR сети с одного терминала по QSigу?

Вообще обычно между офисами есть внутренняя сетка, вот по ней все это и возможно и администрирование и SMDR

Я думаю у Andews есть сеть между удаленными офисами, надо только железяку которая раскидывала потоки Е1, а то человека путаем только. У него есть то что есть, я говорю про 500_ки, других нет. Andews вам нужно по одной PRI в каждую атску, а в остальном обратитесь к сисадмину, пущай спец. думает какой железякой он будет раскидывать потоки. Наверняка у него уже есть и маршрутизатор, и мултиплексор и т.д.

Это всё понятно, я руководству изначально предлогал поставить HICOM , но у нас на связи привыкли экономить, связь, когда она есть её никто не замечает, а вот как пропадёт......,в орбщем я не о том, мне не понятно одно, если под объединение двух станций выделяется не весь поток, а только половина, почему бы вторую половину не использовать под соединение с третей, зачем ещё одна плата PRI

Если вы строите сеть по принципу “звезды”, то потоки у вас физически расходятся в разные стороны и не важно сколько каналов (тайм-слотов) в нем открыто.
Если по принципу “кольцо”, то теоретически можно: половина потока остается на одной станции, вторая транзитом уходит на следующую, а еще проще весь поток задействовать и обеспечить транзит. НО! я сомневаюсь, что 500-ка сможет правильно организовать этот транзит.
Еще один вариант: как я понимаю, потоки на все ваши станции вам вместе с городскими телефонами дает один провайдер. Если это так, то проще договориться с провом об обеспечении маршрутизации между всеми филиалами у него. В этом случае в каждом филиале внутренняя нумерация устанавливается на отдельную цифру (1 - на 1ххх, 2 - на 2ххх и т.д.), а оператору для определения маршрутизации посылается префикс, задействуя ARS.
Ну а если потоки вы сами организуете, то тоже возможны варианты с установкой железа, которое будет делить поток и одну половину посылать на станцию, а другую дальше транзитом в другой поток.
С уважением, COMik.

А как “лыжи” будут отслеживать загруженность маршрутов в сети и перенаправлять потоки? Тоже по Ethernet?

Предидущая реплика - вопрос к pbx, в связи с замечанием:”Вообще обычно между офисами есть внутренняя сетка, вот по ней все это и возможно и администрирование и SMDR”

Теперь о 500-ом. Если поставить 6 станций кольцом - транзит внутрикорпоративных звонков возможен, но нельзя сделать альтернативную маршрутизацию по длинному пути. Т.е. если  короткий путь между двумя станциями окажется перегружен, абонент получит “занято”. Альтернативка сработает только если перегружен будет ближайший межстанционный линк. Это произойдёт потому, что Панас как и Лыжи и Самсунги не имеет фирменного сетевого протокола, с помощью которого отслеживаются перегрузки на маршрутах.

Входящие звонки по DDI будут попадать с любой станции на любую, а вот исходящие звонки возможны транзитом только через соседние станции.

Делить потоки при этом не нужно.

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

Создано dmsl
А как “лыжи” будут отслеживать загруженность маршрутов в сети и перенаправлять потоки? Тоже по Ethernet?

Нет, отслеживать загруженность не получится. Можно задать лишь жесткий приоритет маршрутов, хотя здесь можно и как-нибудь схитрить, например разбить все маршруты на несколько частей, занимать на выход сначала первые части по кругу, потом вторые и т.д., будет какая-то равномерность. Вообще такими глобальными сетями мне заниматься не приходилось. Обычно все это работает для связи между 2-3 офисами, вполне практично и есть много разных функций, которыми можно умело выкрутиться из разных ситуаций. Если задумано что-то более масштабное, может быть тогда актуально Siemens и т.п.
По Ethernet также помимо вышеописанного станции сообщают о состоянии всех своих портов.

Поразмыслив на досуге над тем что написал вчера, я нашел в своих рассуждениях логический прокол:  “если короткий путь между двумя станциями окажется перегружен, абонент получит “занято”“.

Получится ещё хуже.
Рассмотрим ситуацию подробней.
6 станций кольцом, у каждой свой индекс - 1, 2, 3, 4, 5, 6.
Маршрутизация прописана через коды Other PBX и TIE-таблицу.
В кольце для каждого межстанционного вызова есть два пути: короткий  (меньшее число транзитов), и длинный - альтернативный (большее число транзитов). Соответственно в TIE-таблице короткий путь прописан в первой колонке  транкгрупп  (использовать в первую очередь), а длинный во второй колонке (использовать если в коротком маршруте все линии заняты).

Предположим нам нужно сделать вызов с 4-ой PВX на 2-ю. Короткий путь - транзит через 3-ю РВХ. Вызов передаётся на неё, но между 3-й и 2-й все каналы заняты.
Вчера я предположил, что абонент в этом случае получит “занято”, но не тут-то было. 3-я РВХ тоже маршрутизит вызов по TIE-таблице, и в ней тоже прописан альтернативный длинный путь. Не найдя в коротком маршруте свободных каналов она отправит вызов по длинному, т.е. обратно на 4-ю РВХ.  Та снова вернёт его на 3-ю и этот пинг-понг будет продолжаться пока все каналы между 3-й и 4-й не будут заняты. Если к этому моменту вызов окажется на 3-й РВХ то произойдёт отбой, а если на 4-й, сработает альтернативка по длинному пути с некоторым петлянием на коротком.

Подобные ситуации могут возникать в сложных сетях, имеющих кольцевую структуру, каждый узел которой осуществляет маршрутизацию на основе  анализа получаемых цифр без анализа общего состояния сети.
Решение этой проблемы только в отказе от альтернативной маршрутизации по длинному пути.
В топологии “звезда” таких проблем не усматривается.
Главное что бы коммутатор потоков был совместим с Панасом, а то есть такое подазрение, что не всякая уважающая себя железка захочет корректно с ним работаь.

На форуме по LG Wehrwolf сообщил, что удачно соединял 500-ки через  Hicom 150.

Конечно, еще бы HICOM гибкая станция, поддерживает честный ISDN