[cmhungry]

Можно сколько угодно убеждать меня, что РТУ - это г....но, но, простите, я придерживаюсь другого мнения. Да, не мерседес, но продукт рабочий и позволяет предоставлять качественный сервис. И денег мы за него просим не как за мерседес.

Это 5! :)) Представитель компании поставил точку в обсуждении качества РТУ, на этот пост можно смело давать ссылки всем желающим узнать, как оно работает.

РТУ = жигули. Как автомобиль - г..но, но 4 колеса есть и иногда даже крутятся. С горки и попутным ветром может разогнаться до 40 000 абонентов 120км\ч, его даже тестировали в лаборатории Intel аэродинамической трубе.

Хотите нормальный софтсвитч автомобиль - покупайте мерседес, можно в кредит. :)

Марки хороших софтсвитчей 5го класса в студию =) Очень важный вопрос, на самом деле.

[Mikler]

Можно сколько угодно убеждать меня, что РТУ - это г....но, но, простите, я придерживаюсь другого мнения. Да, не мерседес, но продукт рабочий и позволяет предоставлять качественный сервис. И денег мы за него просим не как за мерседес.

Это 5! :)) Представитель компании поставил точку в обсуждении качества РТУ, на этот пост можно смело давать ссылки всем желающим узнать, как оно работает.

РТУ = жигули. Как автомобиль - г..но, но 4 колеса есть и иногда даже крутятся. С горки и попутным ветром может разогнаться до 40 000 абонентов 120км\ч, его даже тестировали в лаборатории Intel аэродинамической трубе.

Хотите нормальный софтсвитч автомобиль - покупайте мерседес, можно в кредит. :)

Марки хороших софтсвитчей 5го класса в студию =) Очень важный вопрос, на самом деле.

У меня есть небольшие обзоры. kukumander.lj.ru

Ценики их вас не обрадуют.

Изменено 25 октября, 2011 пользователем Mikler

[Aleck_K]

Вот тут коллега telematic обещал рассказать про хороший софтсвитч. Может, дружно попросим его поделиться опытом?

Изменено 25 октября, 2011 пользователем Aleck_K

[telematic]

Вот тут коллега telematic обещал рассказать про хороший софтсвитч. Может, дружно попросим его поделиться опытом?

 

Why not?

 

Правда, полноценного рассказа не получится, т.к. решение ещё в процессе внедрения. И ещё - цены никакие озвучивать не буду, по просьбе интегратора, который мне это решение продал.

 

В общем, Broadworks - разработка компании Broadsoft, версия софта 17.

Я долго мурыжил с покупкой, потому что мне предлагали поставить всё это хозяйство на 8 серверов (с учётом резервирования). Меня давила жаба, потому что аппаратная часть получалась с ценником от авианосца. Интегратор запустил это всё на виртуальной машине, обошлось двумя серверами, и моя жаба угомонилась. Меня предупредили, правда, что максимальное число обслуживаемых абонентов уменьшается в разы, но для моих масштабов этого достаточно.

Что сказать? Концепция свитча мне нравится, удобная иерархичная структура, позволяющая создавать всякие виртуальные сущности - виртуальную PBX, например или вообще выделить часть ресурсов свитча для сдачи в аутсорсинг виртуальному оператору. Всё управление - через веб интерфейс. Для абонентов предусмотрено также управление ДВО через веб интерфейс и специальная приблуда - CommPilot, которая позволяет управлять вызовами, просматривать списки вызовов, создавать и пльзоваться корпоративным и персональным телефонным справочником.

Здесь кто-то писал о чудо-софтсвитче, с которым его абоненты влёт используют любые CPE, даже наспех изготовленные индусско-китайским совместным предприятием. Так вот, всё это враки. С Бродворксом в комплекте был вручен компатибилити лист, примерно на 50% состоящий из брендов, о которых в России никто никогда не слышал. То, чего нет в этой охранной грамоте, в принципе, использовать можно. Но приходится дорабатывать, иногда с привлечением вендоров - изготовителей CPE и самого Бродсофта. Доходит до того, что на сайтах производителей публикуются бравурные отчёты об успешном тестировании шлюза ХХХ и софтсвитча Бродворкс, а включаешь - лезут баги. Но это скорее общая проблема самой технологии, чем конкретного вендора.

Внедрение.

Внедряли ( и до сих пор внедряем) долго и упорно, с чувством, с толком, с расстановкой. Изрядное количество фич сходу или не заработало или заработало криво. Но радует то, что если что-то поправили, то оно уже работает стабильно.

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

В системе есть развитый и документированный API, позволяющий "делать всё, что угодно" (цитирую интеграторов).

До конца года постараемся совокупить свитч с биллингом.

Очень богатый выбор ДВО. Такой богатый, что некоторые и применить-то не знаешь как.

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

В целом на сегодня о выборе не жалею. Но окончательные выводы можно сделать через год.

Если что ещё интересует, спрашивайте.

[Deac]

Прямо лубочная картинка. :)

 

Несколько вопросов:

1. Управление через WEB-морду, с одной стороны - это хорошо, с другой стороны - как борются с оставлением приватных данных браузерами в своих кэшах?

Отключать кэш совсем - не слишком удачная идея, да и не все браузеры умеет это ПОЛНОСТЬЮ. М.б. java или ещё что-нибудь? Или не задумывались о подобном?

В MVTS, не в последнюю очередь, из-за этого отказалась от WEB-морды, оставив её чисто для мониторинга.

2. Как указанный софтсвитч реагирует на проблему "407"?

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

Разные системы в этих условиях ведут себя по разному, например SIP-HIT из состава MVTS и kamailio(к сожалению) выпадают в корку, YATE и AlterPSS - виснут, и т.п. В случае с kamailio, этот момент решается отправкой кода "404"(есть шлюзы, кот. ни на какой другой код не реагируют), но kamailio - opensource и позволяет самостоятельно формировать сообщения прямо из конфига.

3. Как обстоят дела с поддержкой RADIUS/DIAMETR?

4. Нельзя ли ознакомиться со списком рекомендованного оборудования?

5. Существует ли список рекомендованных биллинговых систем и если да, нельзя ли с ним ознакомиться?

Напомню, обычно каждая биллинговая система имеет собственный язык для общения с софтсвитчём. Например, тот же PortaBill.

 

P.S. Уточню, в п.1 речь идёт не о "паролях/явках" доступа к самой странице, а о заполняемых формах, содержащих информацию о добавляемых абонентах и сервисах, т.е. информации являющейся приватной не для браузера, а для оператора.

Изменено 25 октября, 2011 пользователем Deac

[telematic]

Прямо лубочная картинка. :)

 

 

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

 

По вашим вопросам.

 

1. Не задумывался. Спрошу у инженеров. Да, общение с веб-мордой осуществляется по https.

2. Мы не сталкивались с такой проблемой. Да и свитч за 4 месяца ни разу не завис.

3. В списке лицензий есть лицензия поддержки Radius. Покупается отдельно.

4. Спрошу у интегратора. Если не секрет, поделюсь.

5. Списка нет и языка тоже нет. Видимо, вызовы собираются через CDR, а управление через API. По крайней мере, мы так собираемся делать.

[Deac]

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

 

Старая дилемма: "UID vs RealNUM, к чему привязать идентификацию пользователя?"

В случае привязки идентификации к RealNUM, что очевидно для VoIP - поведение вполне логичное, иначе новый обладатель номера смог бы получить доступ к информации о звонках предыдущего владельца, удалять которые нельзя.

UID удобнее, но будучи искусственным решением, требует либо СУБД(как часть свитча), либо RADIUS, а по хорошему - и того и другого.

Для себя, в связке kamailio + mysql + RADIUS, решил привязкой к UID, с разрешением иметь одинаковый RealNUM нескольким абонентам, но активным при этом может быть только один. Т.е. при попытке разблокировать другого следует предупреждение об автоматической блокировке всех остальных.

 

1. Не задумывался. Спрошу у инженеров. Да, общение с веб-мордой осуществляется по https.

А напрасно, я надеялся на нотации "PRAGMA" и "NO-CACHE", но как показала практика - браузеры их игнорируют, либо частично, либо полностью.

HTTPS предписывает браузеру вести диалог с сервером в зашифрованном виде и не сказывается на факте ныкания страниц в кэш.

 

2. Мы не сталкивались с такой проблемой. Да и свитч за 4 месяца ни разу не завис.

Рад за Вас, мне пришлось немало попотеть с разного рода рукоделием, типа Planet серии "ATA-1xx".

 

3. В списке лицензий есть лицензия поддержки Radius. Покупается отдельно.

Сам факт поддержки RADIUS-а в общем то сомнению не подлежал, то что она ПЛАТНАЯ - довольно необычно, по сравнению с тем же MVTS.

Имелась ввиду поддержка разного рода VSA и самое главное - возможность внешней маршрутизация через RADIUS.

[telematic]

А напрасно, я надеялся на нотации "PRAGMA" и "NO-CACHE", но как показала практика - браузеры их игнорируют, либо частично, либо полностью.

HTTPS предписывает браузеру вести диалог с сервером в зашифрованном виде и не сказывается на факте ныкания страниц в кэш.

 

Я это понимаю, но уже поздно, покупка сделана :-)

 

Рад за Вас, мне пришлось немало попотеть с разного рода рукоделием, типа Planet серии "ATA-1xx".

 

С Планетом опыта не было, в основном используем Audiocodes. Тем паче, что вендор недавно произвёл грандиозное снижение цен. А телефоны Audiocodes 310-320 - вообще лялька :-) Очень удобные, надёжные и качество звука отличное.

 

У меня другая проблема - кулибины с астерисками. Это товарищи, которые рисуют своему руководству грандиозные планы телефонизации забесплатно, а потом ноют нам в трубку - "Настройте нам Астериск".

 

Старая дилемма: "UID vs RealNUM, к чему привязать идентификацию пользователя?"

В случае привязки идентификации к RealNUM, что очевидно для VoIP - поведение вполне логичное, иначе новый обладатель номера смог бы получить доступ к информации о звонках предыдущего владельца, удалять которые нельзя.

 

Мне кажется, проблема не в этом. Пользователя старого удалить - понятно, но нафига всю группу?

 

Сам факт поддержки RADIUS-а в общем то сомнению не подлежал, то что она ПЛАТНАЯ - довольно необычно, по сравнению с тем же MVTS.

Имелась ввиду поддержка разного рода VSA и самое главное - возможность внешней маршрутизация через RADIUS.

 

Ну у меня все внешние вызовы идут через ОКС-7, поэтому мне маршрутизация через RADIUS фиолетова :-)

[Deac]

Я это понимаю, но уже поздно, покупка сделана :-)

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

 

С Планетом опыта не было, в основном используем Audiocodes. Тем паче, что вендор недавно произвёл грандиозное снижение цен. А телефоны Audiocodes 310-320 - вообще лялька :-) Очень удобные, надёжные и качество звука отличное.

Ну, AudioCodes в рекламе не нуждается, на сегодня для себя определил круг в виде CISCO, AudioCodes, AddPac и LinkSys(ныне тоже CISCO) - подешевле.

 

У меня другая проблема - кулибины с астерисками. Это товарищи, которые рисуют своему руководству грандиозные планы телефонизации забесплатно, а потом ноют нам в трубку - "Настройте нам Астериск".

"В сад! Все в сад!" ©

В крайнем случае - отдавать им номера транком, без регистрации.

 

Мне кажется, проблема не в этом. Пользователя старого удалить - понятно, но нафига всю группу?

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

 

Ну у меня все внешние вызовы идут через ОКС-7, поэтому мне маршрутизация через RADIUS фиолетова :-)

Эээ... В данном случае "внутренняя маршрутизация" - маршрутизация присущая внутренней логике работы свитча, соответственно, "внешняя маршрутизация" - маршрутизация инициированная внешним источником, например RADIUS-ом, изменяющая внутреннюю логику свитча. Используется, например, для LCR или для создания номерных групп, да применений масса. Оч. полезная вещь.

Т.е. это не маршрутизация внутренних и внешних вызовов.

Изменено 26 октября, 2011 пользователем Deac

[telematic]

Ну, AudioCodes в рекламе не нуждается, на сегодня для себя определил круг в виде CISCO, AudioCodes, AddPac и LinkSys(ныне тоже CISCO) - подешевле.

 

Ну и Элтексовские шлюзы 72-х портовые. Которые по цене за порт вообще вне конкуренции. Их, правда, еще не пробовали подключать.

 

Эээ... В данном случае "внутренняя маршрутизация" - маршрутизация присущая внутренней логике работы свитча, соответственно, "внешняя маршрутизация" - маршрутизация инициированная внешним источником, например RADIUS-ом, изменяющая внутреннюю логику свитча. Используется, например, для LCR или для создания номерных групп, да применений масса. Оч. полезная вещь.

Т.е. это не маршрутизация внутренних и внешних вызовов.

 

Не совсем понял мысль. У меня нет никакого LCR, т.к. направление вызова жёстко определяется законодательством, волей абонента в выборе МГМН оператора и B-номером.

Функция Least Cost Routing, кстати, в свитче есть по дефолту.

[worker]

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

 

Ой йооооо....

Не не так...

Совсем не так....

 

Освободился номер, назначьте другому абоненту хоть в этой группе хоть в какой любой...

Делается легко и просто...

Странно что существует такое мнение что нужно удалять пользователей?!?!?

Направьте инженера своего в супорт интегратора, ему там подробно всё расскажут...

Более того уверен что уже рассказывали;)

[telematic]

Направьте инженера своего в супорт интегратора, ему там подробно всё расскажут...

Ну именно так суппорт и рассказал :-)

Если у вас есть какой-то способ поступить иначе, поделитесь, буду благодарен.

[Deac]

Не совсем понял мысль. У меня нет никакого LCR, т.к. направление вызова жёстко определяется законодательством, волей абонента в выборе МГМН оператора и B-номером.

Функция Least Cost Routing, кстати, в свитче есть по дефолту.

Это всё понятно и регулируется законодательством, но ведь иногда так и тянет отправить часть вызовов в VoIP. Например при занятости всех внешних линий. Т.е. указал, через RADIUS, перебрать все внешние и в конце - VoIP, которых тоже может быть несколько, с разными ценами и качеством. А для своих нужд - наоборот, сначала - VoIP, а потом - внешние, чтобы не мешать абонентам. Замутить такое в свитче - весьма непросто, а через RADIUS - не проблема.

Ещё пример, требуется организовать номерную группу или как её ещё называют - "горячий телефон", т.е. звонок на определённый номер(которого физически может и не существовать) должен равномерно распределяться между несколькими реальными номерами. И тут выясняется, что указанные номера находятся в разных группах или даже в разных ентерпрайзах, есть у внутренней логики свитча решение подобной задачи? С помощью внешней маршрутизации - без проблем.

[telematic]

Это всё понятно и регулируется законодательством, но ведь иногда так и тянет отправить часть вызовов в VoIP.

 

Меня не тянет :-)

 

Например при занятости всех внешних линий.

 

У меня все межоператорские стыки только по ОКСу. Тем более, зачем отправлять в VoIP, к примеру, МГМН вызов, если доход от него получит соответствующий оператор? А я в случае отправки его в VoIP получу только затраты.

Ну да ладно, это непринципиально, у каждого своя схема :-)

 

Ещё пример, требуется организовать номерную группу или как её ещё называют - "горячий телефон",

 

"Серийный номер" её называют :-)

т.е. звонок на определённый номер(которого физически может и не существовать) должен равномерно распределяться между несколькими реальными номерами. И тут выясняется, что указанные номера находятся в разных группах или даже в разных ентерпрайзах,

 

С такими требованиями я пока не сталкивался.

 

 

есть у внутренней логики свитча решение подобной задачи?

 

Есть. Называется Sequential Ring. Но эта фича вроде действует только в пределах одного абонента. Точно не знаю.

[Deac]

"Серийный номер" её называют :-)

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

[Gimli_r]

Коллеги, приветствую!

Простите, не удержался от своих пяти копеек :)

 

Ну именно так суппорт и рассказал :-)

Если у вас есть какой-то способ поступить иначе, поделитесь, буду благодарен.

 

Полагаю, суппорт рассказал несколько иначе, все же. Потому как способ такой есть и он действительно прост. Как и вся логика BroadWorks, логика распределения номеров скачет от модели, на которой система основана и емко именуется английским multi-tenancy:

 

1. Снимаем номер у пользователя или удаляем самого пользователя - номер свободен на уровне группы.

2. Исключаем этот номер из списка выделенных группе - номер свободен на уровне энтерпрайза.

3. На уровне интерпрайза отдаем его другой группе, хоть один, хоть пачкой - воля ваша.

4. В другой группе он теперь доступен для использования любым пользователем реальным или виртуальным (в смысле всяким IVR и хантгруппам)

 

Это всё понятно и регулируется законодательством, но ведь иногда так и тянет отправить часть вызовов в VoIP. Например при занятости всех внешних линий. Т.е. указал, через RADIUS, перебрать все внешние и в конце - VoIP, которых тоже может быть несколько, с разными ценами и качеством. А для своих нужд - наоборот, сначала - VoIP, а потом - внешние, чтобы не мешать абонентам. Замутить такое в свитче - весьма непросто, а через RADIUS - не проблема.

 

На BroadWorks достаточно просто, в составе системы есть свой отдельный компонент, отвечающий исключительно за роутинг звонков и его функционала и для LCR и для раздельного роутинга для разных групп пользователей хватает "за глаза".

Изменено 26 октября, 2011 пользователем Gimli_r

[Gimli_r]

1. Управление через WEB-морду, с одной стороны - это хорошо, с другой стороны - как борются с оставлением приватных данных браузерами в своих кэшах?

Отключать кэш совсем - не слишком удачная идея, да и не все браузеры умеет это ПОЛНОСТЬЮ. М.б. java или ещё что-нибудь? Или не задумывались о подобном?

 

[cut]

 

P.S. Уточню, в п.1 речь идёт не о "паролях/явках" доступа к самой странице, а о заполняемых формах, содержащих информацию о добавляемых абонентах и сервисах, т.е. информации являющейся приватной не для браузера, а для оператора.

 

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

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

[Aleck_K]

Если что ещё интересует, спрашивайте.

У меня много вопросов. Если не лень, напишите что-нибудь про это:

1. Схема лицензирования фич - вы планируете использовать схему "пакетов", которую предлагает Броадсофт или сделаете собственные пакеты услуг? Может, уже есть публичное предложение для клиентов? Было бы интересно почитать.

2. Абонентам будете отдавать управление фичами через веб? В частности, настройки параметров услуг виртуальной атс будут доступны для абонента? Веб-морду сами пишите или планируете отдавать "родную" броадсофтовую?

3. CPE-шки, как я понял, планируете Audiocodes. Будет что-то еще? Планируете ставить ATA-шки или, в основном, телефоны? Если АТА-ки, как будете объяснять абонентам как пользоваться ДВО (трансферами, переадресациями, парковой и т.п.) с аналогового телефона?

4. Виртуальные машины вместо IBM blade - это "рацуха" интегратора? Броадсофт сам санкционировал такую установку?

5. Абонентов планируете пускать напрямую на платформу или перед ней будет стоять SBC? Как планируете решать вопрос с безопасностью, особенно учитывая то, что производительность заметно снижена за счет виртуализации?

6. Вы тестировали "In call activation service"? Насколько стабильно работает?

7. Скажите пару слов про вашего интегратора, довольны им?

8. Если не коммерческая тайна, сколько абонентских лицензий купили?

Изменено 26 октября, 2011 пользователем Aleck_K

[worker]

Направьте инженера своего в супорт интегратора, ему там подробно всё расскажут...

Ну именно так суппорт и рассказал :-)

Если у вас есть какой-то способ поступить иначе, поделитесь, буду благодарен.

 

Если так сказал суппорт, то скажите номер ТТ, и супорт будет расстрелян с особой циничностью и жестокостью.

Хотя я очень сильно сомневаюсь что супорт так сказал, скорее всего произошло недопонимание...

 

 

 

Напишу с использованием английской терминологии, ибо общение происходит на публичном форуме, и мне так удобнее.

 

1. Забираете номер у абонента

2. Переходите на уровень группы, "Resources" в меню "assign numbers" и делаете для номера unassign

3. Теперь номер можно назначить любой другой группе в рамках "service provider".

4. Если номер нужно использовать в другом "service provider" то переходите на уровень "service provider" "Resources" в меню "assign numbers" и делаете для номера unassign

5. Делаете assign numbers для нового "service provider"

6. Делаете assign numbers для новой группы

7. Делаете assign numbers для новой абонента

 

НИЧЕГО УДАЛЯТЬ НЕ НУЖНО!

 

 

С Уважением Роман Р.

[telematic]

Потому как способ такой есть и он действительно прост.

 

Спасибо за наколку, попробуем. По результатам отпишусь.

 

С Уважением Роман Р.

 

Роман, рад вас видеть здесь! :-)

Я не исключаю, что у меня кто-то что-то не понял. Завтра подниму этот вопрос.

[worker]

4. Виртуальные машины вместо IBM blade - это "рацуха" интегратора? Броадсофт сам санкционировал такую установку?

 

 

Официальное решение от Броадсофт, либо XEN либо VMWARE ESXi

Официальные цифры по производительности:

до 15K Enterprise или 30K Residential, тут всё специфично нужно считать по месту.

Для развертывания в полностью отказоустойчивой конфигурации нужно два сервера, что то вроде

IBM x3550 M2: 1x QC L5520 CPU, 16 GB RAM, and 2x 300 GB HDD deployed in RAID1

 

Можно ужаться по RAM, но тогда просядет производительность, но имхо озвученные мною цифры по производительности это очень прилично для пары серверов.

И это Броадсофт, они если сказали значит оно работает так как написано.

Изменено 26 октября, 2011 пользователем worker

[telematic]

1. Схема лицензирования фич - вы планируете использовать схему "пакетов", которую предлагает Броадсофт или сделаете собственные пакеты услуг? Может, уже есть публичное предложение для клиентов? Было бы интересно почитать.

2. Абонентам будете отдавать управление фичами через веб? В частности, настройки параметров услуг виртуальной атс будут доступны для абонента? Веб-морду сами пишите или планируете отдавать "родную" броадсофтовую?

3. CPE-шки, как я понял, планируете Audiocodes. Будет что-то еще? Планируете ставить ATA-шки или, в основном, телефоны? Если АТА-ки, как будете объяснять абонентам как пользоваться ДВО (трансферами, переадресациями, парковой и т.п.) с аналогового телефона?

4. Виртуальные машины вместо IBM blade - это "рацуха" интегратора? Броадсофт сам санкционировал такую установку?

5. Абонентов планируете пускать напрямую на платформу или перед ней будет стоять SBC? Как планируете решать вопрос с безопасностью, особенно учитывая то, что производительность заметно снижена за счет виртуализации?

6. Вы тестировали "In call activation service"? Насколько стабильно работает?

7. Скажите пару слов про вашего интегратора, довольны им?

8. Если не коммерческая тайна, сколько абонентских лицензий купили?

 

1. Пока не знаю. До "раскручивания" суперДВО от Бродворкс пока не дошли, решаем более тривиальные проблемы, как то стыковка с биллингом, настройка транков и т.д.

2. Отдавать будем. Веб-морду будем использовать штатную.

3. CPE в основном Audiocodes. Ну и Астериск, простигосподи :-) В ближайшее время протестируем Элтекс, ибо как я уже говорил, у 72-х портового шлюза фантастически низкая цена в расчете на порт. Плюс есть планы по внедрению PON, там есть CPE с FXS. Сейчас заказал оборудование на тест, посмотрим, как оно будет с Бродворксом жить.

По поводу ДВО на аналоговых телефонах - базовые работают через флэш. Это, кстати, было одним из мотивов остановиться на решении Бродворкс.

4. Понятия не имею. Но серверы именно IBM.

5. SBC уже стоит. Не совсем понял связь между безопасностью и производительностью.

6. Не тестировали. Я название помню, но в чём суть фичи, запамятовал.

7. Про интегратора, как в том анекдоте - "Что такое смешанные чувства? Это когда ваша тёща летит в пропасть на вашем новом "Мерседесе"" На самом деле, у интегратора есть сильные инженеры, один из них уже отметился здесь под ником worker. Есть ряд вопросов к работе компании, которые я озвучивать здесь не буду, но я их связываю с тем, что я всё-таки довольно мелкий для них клиент. Короче, на краткий вопрос - "Можно ли с ними работать по решению Broadworks?", я бы кратко ответил "Да".

8. Не секрет. 1500. Вообще минимальный стандартный объём лицензий у них 1000. И на уменьшение они идут крайне неохотно. Я имею в виду вендора. В перспективе планирую довести ёмкость тысяч до 10.

[Гoсть]

Во Телематик дает просратся!

А как же любимая Си2000, пошто бабушку обидел? :)

СиТиАй нормальная контора, и Рома Воркер прикольный чувак. Все встают в очередь за телематиком!

[catalist]

SBC уже стоит. Не совсем понял связь между безопасностью и производительностью.

Скажите если не секрет какой SBC вы используете и по чём взяли? (можно в личку если секрет)

[Deac]

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

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

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

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

Остаётся только надеяться, что ни сам telematic, ни кто-либо из лиц допущенных к WEB-морде, не станет показывать "хорошим знакомым" как у них всё "замечательно и здорово".

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