_max

Благодарю за конструктивные пояснения. :)

А почему SoftSwitch class 4 должен выполнять функцию SBC? Он успешно выполняет функции SSW class 4, в этом и есть его назначение. И вообще, от куда вы взяли SBC, в текущих версиях MKD этой функциональности не заявляется. Как же это "не заявляется"? А вот это, помилуйте, что такое? Пунктик 5.1.8http://www.imak.ru/documents/?page=17 А если, SBC функциональности нет, в таком случае вообще никакого смысла в этом продукте не просматривается. Покупать, знаете ли, сервак с коробочным RHL только для того, чтобы он SIP-в-SIP маршрутизировал... Любая цыска, начиная с 2801, с голосовым IOS с этой задачей гораздо лучше справиться. И по цене гораздо привлекательней выглядит. Я уже не говорю про энергопотребление сервера, про наращиваемость и те пе Опять же, резервирование... Насколько мне поведали знакомые, на этом форуме, Вы на сервера ключики HASP ставите. Само по себе - ничего страшного, все понятно, защита интеллектуальной собственности, все дела... но, для того чтобы зарезервировать такой сервер - недостаточно иметь такой же на складе. Я так понимаю, речь опять же про МКД. Смотрите какая штука... В общем случае media-трафик не замыкается на SSW, а проходит напрямую между абонентскими устройствами. В этом случае при аварии никакого разрыва соединений не будет.То есть, Вы хотите сказать, что ram_scan нагло лжет?... :-) Поделитесь секретом, а зачем? Поделюсь, цена. CentOS распространяется бесплатно, а RHL Вы предлагете вешать на покупателя. Хоть бы выбор предлагали, так ведь не предлагаете.

Отлично! Не хватает сущего пустяка - сертификата.

Да как сказать "хорошо"...Можеш сам посмотреть: http://www.bgbilling.ru/v4.4/doc/ch03.html Стыковать можно как минимум двумя способами, либо посылая HTTP запрос в ядро биллинга, как описано в документации, либо "по старинке" - выгрузка в файл (текст, DBF, XML) с последующей загрузкой. Лично мне - с файлом как-то привычнее.

Эка Вы рубанули с плеча... :) 2bairt: Смотря что Вы собираетесь считать этим биллингом. NetUP, например, хорошо справляется с подсчетом netflow, dialup, voip. При правильной настройке может обсчитывать по netflow просто гигантские объемы. Опять же прост в первоначальной настройке для новичков. Слаб в части, касающейся выставления счетов, сч-ф, актов и в плане отслеживания оплаты. Достаточно нетребователен к аппаратной части. Может работать с СУБД MySQL, Postgres. Покупая его, покупаете законченный, закрытый продукт, т.е. модифицировать "под себя" не получиться. BG-Billing достаточно гибкая штука, написанный на Java, но чтобы разобраться с его первоначальной настройкой (тарифные планы, документы для бухгалтерии, стыковка с 1С) прийдеться потратить вполне себе времени. Имхо, стыковка с 1С - вообще атас. Работает с СУБД MySQL. Для редактирования форм документов требуется понимание работы XSL-translation и Apache FOP. Может отслеживать оплату счетов, но аналитики нет, т.е. для полной автоматизации бухгалтерии ISP все равно требуется стык с 1С или другой бухгалтерской системой. Написание собственных отчетов - дохлый номер.

Ух ты, какую темку-то интересную подняли... Действительно реальных отзывов о работе протеевской системы и нету как таковых. Вопросики к сотрудникам Протей (я смотрю, тут чуть ли не все инженеры проекта iMAK собрались): Поясните назначение МКД-4? Как SBC, он прямо скажем "не очень". Не рассматривали возможность использования CentOS вместо Red Hat Linux? Опять же так называемый "горячий резерв" (как заметил ram_scan сессии рвуться), что-то планируется в этом направлении менять? Иначе смысл ставить второй сервак с коробочным RHL...

"Вот оно че Михалыч..." А я ведь тоже хотел у них сварочник покупать, уже договор подписывать собрались...

Пересекала! Могу ссылочку в личку, если есть желание.А вот сертификат на него (правда просроченный): http://www.rubytech.ru/upload/iblock/7ae/s...t_ruby_tech.jpg http://www.rubytech.ru/upload/iblock/3db/p...e_ruby_tech.jpg

Связка М-200 + Cisco 28xx + софтсвитч работает нормально. Как при местных звонках, так и при внитризоновых/МГ/МН вызовах. Категория абонента корректно отдается в ОКС7. Категорию можно формировать как по схеме PRE-SELECT, выделяя из номера вызывающего абонента, так и по схеме HOT-CHOICE, отдавая номер на междугородку, которая сама устанавливает категорию.

Нда... "на зону" говорите... :) В М-200 есть одна непроверенная функция - "Извлекать категорию из первой цифры АОН (callIn_categoryFromAON)". Если она работает так, как я думаю, то категорию можно передавать куда угодно: 2ВСК, ОКС7. Даже "на зону", век воли не видать... :) С помощью этой функции (callIn_categoryFromAON), насколько я понимаю, можно отдавать категорию только в ОКС7 (тип канала МТР). В более свежий версиях прошивки для MP-хх есть еще одна фича - callIn_categoryFromNUMBER, т.е. извлечение категории из вызываемого номера. callIn_categoryFromAON - работает нормально, проверено с разными АТС, в том числе AXE-10. Если использовать МР-хх в качестве транзитного коммутатора ОКС7 в DSS1, то там есть еще одна заморочка - некоторые АТС используют разные настройки тайм-слотов для местных и внутризоновых/МГ/МН вызовов. МР-хх не умеет применять различные настройки тайм-слотов для разных вызовов. Приходится разделять все тайм-слоты на местные и внутризоновые/МГ/МН и рулить между ними таблицами маршрутизации.

Согласен - бред. Происходит банальная подмена понятий - путают учет (подсчет) и измерения (сравнение физической величины с данной, принятой за эталон).

А клиент и не обязан объем своего потребления доказывать, т.к. в соответствии с Постановлением Пленума Верховного Суда РФ от 29 сентября 1994 г. N 7 Таким образом, именно на операторе лежит бремя доказывания, что он "все правильно посчитал". А в соответствии с руководящим документом отрасли: РД 45.002-96 "Руководcтво по установлению номенклатуры средств измерений, подлежащих поверке" http://www.minsvyaz.ru/ministry/documents/959/964.shtml В приложении к данному руководящему документу сказано: Как верно заметил Антон Георгиевич, объем трафика не измеряется, а учитывается. Но тем не менее, такой руководящий документ существует и может являться аргументом для суда не в пользу оператора.Следовательно, оператор всячески заинтересован решать подобные споры в досудебном порядке, а для этого требуется не загонять пользователя в угол счетами по 63тыр.

Неверно. Подразумевается только один протокол. А из этого протокола достаются по желанию порты FXS, мультикаст ит.п....Ведь TVINGO имеет ввиду тоже самое - в многоквартирных домах в квартиру к абоненту затаскивается один кабель UTP cat.5 в котором идет все тоже самое (передача данных + 1 или 2 аналоговых тел. линии). Разница только в оборудовании на чердаке... И раз уж пошли с кодировками параллели проводить, то логичнее было бы с CP866 сравнивать... ;-) Поясни, что тут имел ввиду? Причем тут веб вообще? Самое дорогое в телекоме, это люди. ФОТ - основной источник расходов. :) А превосходство эзернета просто лишний раз утверждет примат экономики над технологией. "Эпоху дерьма" несет не производитель, а потребитель. +1 :)

Сергей, вы еще не устали доказывать TVINGO преимущества езернета? ;-)Ему ведь это не нужно... Ну посудите сами: человек старался, выбирал технологию, доказывал преимущества инвесторам, потом строил все это (сеть на 16 ПОН-овских деревьев, источники multicast-потоков). Вломили туда кучу бабла, надеются ее хоть как-то отбить.... и тут вы заявляете, что все тоже самое можно было сделать гораздо дешевле... Очень тяжело признавать собственные ошибки, тем более неочевидные. Кстати, в ваших региональных компаниях тоже полно адептов PONа... не желаете с ними подискутировать...? :-)

А какие проблемы у езернета с мультикастом? В чем конкретно преимущество Пон по данному вопросу? Тема не раскрыта. ;-) Павел, у езернет нет проблем с мультикастом. Преимущество ПОНа в работе с мультикаст-потоком в том, что идет один поток на дерево в котором стоит (например) 32 оконечных устройства, каждое из которых копирует этот поток по своим портам. В случае езернета (топология звезда) приходится этот поток копировать на каждое волокно отдельно.Но это опять же очень условно, т.к если коммутаторы корректно реализуют IGMP и каждый IPTV канал выделен в отдельную мультикаст-рассылку, то копироваться будет только то, что запрашивают клиенты, а не то, что попросили из соседнего дома...