СИСТЕМЫ БИЗНЕС КОММУНИКАЦИЙ - интересные топики

Call-центр Oktell 2.0 Freeware - бесплатная, открытая для редактирования коммуникационная платформа с неограниченным голосовым меню (IVR), системой операторских диалоговых сценариев, входящих и исходящих задач, развитой системой оперативной и хронологической отчетности, записью разговоров, возможностью работы с email, sms, icq, web контактами и взаимодействия со сторонними БД и CRM системами. Данная версия включает в себя: * Внешние каналы голосовой связи: SIP (2 транка); * Внутренние каналы голосовой связи: Oktell (6 транков); * Рабочее место сотрудников офиса: до 5 одновременных подключений; * Рабочее место сотрудников call-центра: 1 подключение. Достаточно установить программу, и можно начинать изучать систему, тестировать ее функциональные возможности, примерять их к вашему бизнес-процессу. Для изучения процесса установки системы можно посмотреть видео-уроки или задать вопросы на нашем форуме. Call-центр Oktell 2.0 Freeware также подойдет для организации IP АТС в небольшом офисе. Попробуйте построить систему автоматизации обслуживания клиентов, создайте рабочее место оператора call-центра. На практике гораздо легче будет определить, что реально Вам нужно. СКАЧАТЬ

Опытным путем было установлено, что алгоритм работы гейтвеев Mera MVTS следующий: гейтвей запрашивает роутинг с помощью запроса с аттрибутом xpgk-request-type = 'routing'; после получения роутинга от RADIUS-сервера / биллинговой системы, для каждого отдельно взятого маршрута генерируется запрос с xpgk-request-type = 'number' - по всей видимости, чтобы узнать в каком формате следует слать CLD по данному маршруту. Разумеется, по каждому запросу типа number высылаются соответствующие стопы (только вот *иногда* они дублированы - получается две пары Stop/originate VoIP и Stop/answer Telephony с разными h323-disconnect-cause). Кроме того, похоже, что из полученного из биллинга роутинга, MVTS пробует только первые N маршрутов и, если попытка терминации не была удачной, - повторяет routing-запрос со следующим User-Name. Условно говоря, это выглядит как LCR-алгоритм - получить роутинг для User-Name = 'A', затем с 'B' и 'C'. A, B и C можно представить как классы сервиса - cheap, standard, premium. Дело же в том, что биллинговая система реализует LCR-алгоритм сама, а изложенная выше специфика работы MVTS лишь создает избыточную нагрузку на нее. Интересует следующее: 1) Конфигурируется ли где-то N - количество машрутов, попытки терминации по которым мы предпринимаем? 2) Настраивается ли количество классов сервиса в LCR? Я ознакомился с руководством по конфигурированию MVTS, но не нашел ничего на этот счет. Неужели это жестко зашитые параметры? 3) Наконец, что можно поделать с непредсказуемо дублирующимся stop-аккаунтингом? Буду благодарен за любые хоть сколько-нибудь полезные замечания.

Всем Добрый день! Кто работает с Voipescrow? Кто может рассказать об этой системе??? Спасибо.

Наша компания занимается продажей воип оборудования, дабы увеличить сферу услуг, хотим подключать клиентов к операторам, и иметь с этого некий доход. Есть ли такие сервисы которые предоставляют диллерские аккаунты с хорошой биллинговой системой. Кто что может посоветовать? Заранее благодарствую.

Здравствуйте! Создаем сеть переговорных пунктов на АТА-186 цисках, интересует вопрос биллинга будующей сети, т.е. рабочее место оператора ПП. Как посоветуете поступить...в настоящий момент не готов платить килобаксами за биллинг, но боюсь придется выбирать между ОСС-2000 и IPSoft...какие еще есть известные системы? Вопрос к ОСС: в каком виде представляются отчеты партнерам, и помогут ли они в моем случае?