BiTel

Форум BiTel
bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 29 мар 2024, 03:30

Часовой пояс: UTC + 5 часов [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 65 ]  На страницу 1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Хотелки для Voice
СообщениеДобавлено: 10 июл 2013, 07:41 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
А давайте сразу перечислим, что мы бы хотели видеть в новом модуле.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 10 июл 2013, 13:44 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Cromeshnic писал(а):
А давайте сразу перечислим, что мы бы хотели видеть в новом модуле.


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


А где мы его будем брать ? Может вы сами будите его на wiki заливать


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 10 июл 2013, 14:24 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
http://www.rossvyaz.ru/activity/num_resurs/registerNum/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 12 авг 2013, 19:43 
Не в сети
Клиент

Зарегистрирован: 09 фев 2011, 15:28
Сообщения: 1092
Карма: 135
Всякие там коды - это по желанию. Кому-то надо, кому-то нет, а вот периоды в картах зон, цен и тому подобное - крайне необходимо.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 07 ноя 2013, 18:07 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
В модуле phone номер привязан к конкретной АТС. Недавно сталкивались с ситуацией, что один номер может звонить с разных АТС (междугородний звонки с одной, местные с другой), пришлось объединять логи с 2-х АТС в одну . Видимо нужно предусмотреть привязку номера к нескольким АТС. Может быть сделать как в inet иерархию устройств и привязывать устройство к нижнему устройству. А искать звонки для поинта среди логов всех устройств в цепочки (среди всех родительских устройств). С этой проблемой мы вроде нечасто сталкивались.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 09 дек 2013, 15:03 
Не в сети
Клиент

Зарегистрирован: 09 фев 2011, 15:28
Сообщения: 1092
Карма: 135
Возражаю. Ситуация, достаточно классическая. Есть коммутатор потоков, к нему подключены корпоративные клиенты по Е1 и абонентская станция. Звонки абонентов станции будут дублироваться и с самой станции и с коммутатора. Ддя корпоративных логи берутся с коммутатора.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 15 янв 2014, 16:35 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
barguzin2 писал(а):
Возражаю. Ситуация, достаточно классическая. Есть коммутатор потоков, к нему подключены корпоративные клиенты по Е1 и абонентская станция. Звонки абонентов станции будут дублироваться и с самой станции и с коммутатора. Ддя корпоративных логи берутся с коммутатора.

Не совсем понял. против чего возражаете и почему ?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 26 янв 2014, 11:12 
Не в сети
Клиент

Зарегистрирован: 09 фев 2011, 15:28
Сообщения: 1092
Карма: 135
Цитата:
Может быть сделать как в inet иерархию устройств и привязывать устройство к нижнему устройству.

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

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

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

Также желательно иметь возможность настройки произвольных параметров для пойнта - для прописывания, например, физического порта станции, громполосы, прочего. Хотя порт - его можно сделать основным параметром для пойнта, только не как сейчас, а номер + порт, просто в типах пойнта тогда указывается по какому параметру тарифицируется - по номеру или порту.

Для VoIP пойнтов есть необходимость делать привязку по IP-адресам, с которых возможна регистрация.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 09 июн 2014, 15:05 
Не в сети
Клиент

Зарегистрирован: 15 мар 2009, 14:04
Сообщения: 1337
Карма: 12
Как уже начали обсуждать в теме Phone, сущность поинта сделать контенером, у него есть поля:
а) АТС (мультивыбор)
б) период действия
в) комментарий
г) тарифы
д) абонплаты

К поинту могут добавлятся сущности "телефонный номер" и "порт АТС". Логика совпадений "ИЛИ". Поля сущности:
а) Номер телефона/порт
б) Период действия
в) комментарий

Мне думается, что лучше в поинте сделать поле выбора АТС чекбоксом, а не рисовать "иерархию" АТС, потому что номер, действительно, может приходить с разных АТС, иерархически ни как не связанных, и "выдумывать" эту иерархию - наступить на потенциальные грабли в будущем.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 23 дек 2014, 15:38 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
У нас тут произошло слияние с компанией, у которой куча меди и АТС-ок и самописный биллинг на всё это (далее следует непереводимый итальянский фольклор).

Иерархия в виде дерева, как в Inet - неправильно. По факту АТС-ки - это облако. Один и тот же звонок проходит через несколько и попадает в несколько CDR. Связать их между собой явно обычно нельзя, т.к. нет сквозного id звонка. Есть самописные эвристические методы связки для дебага прохождения звонков, но это к биллингу не относится..
Есть 2 подхода:
1. Берём данные на входе, т.е. на той АТС, к которой подключен абонент (или заходит транк субоператора). Плюс - мы точно знаем, кого мы тарифицируем. Минус - мы точно не знаем, куда этот звонок уйдёт из облака, т.е. не можем надёжно определить цену (конечного оператора МГМН).
2. Берём данные на выходе из нашего облака. На выходе мы точно знаем, на какого вышестоящего оператора мы отправили звонок и можем точно определить цену. Но клиента, которому нужно этот звонок выставить, мы знаем только по номеру телефона. А этот номер может быть кривой, например. Но это уже будет проблема конфигурации сети - почему наши станции или абонентские АТС шлют плохие А-номера.

Очевидно, вариант 2 правильнее.
Отсюда следствие: транки субоператоров желательно присоединять к тому же узлу (транзитному), с которого они выходят вовне. Тогда можно идентифицировать их звонки просто по входящему/исходящему портам.
Но, во-первых, это не всегда физически возможно.
Во-вторых, в какой-то момент у вас рядом появляется, например, вторая транзитная Voip-АТС и вы часть трафика выводите через неё.
И опять приходится делать выбор, в какой точке снимать CDR.

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

По факту, у нас используется некая промежуточная база для сбора CDR:
- Импорт логов разных форматов в общую базу
- Аналитика и мониторинг по сырым данным станций
- Конфигурация сети (куда какие каналы ведут, присоединённые операторы)
- Отсев до тарификации (?)

Затем уже из этой базы генерируются готовые для тарификации CDR в едином формате.
Такие "подготовленные" CDR удобнее тем, что, например, port_to - это не канал на станции (на каждой - свой), а именно ID оператора (РТ, ТТК и т.п.). port_from можно аналогично использовать как ID "дочерних" операторов.

Было бы круто, если BGBilling имел готовый фреймворк для работы с сырыми данными, вёл топологию сети и т.п.

ps. Всё это со слов опытных товарищей. Вполне возможно, что у кого-то всё по другому.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 23 дек 2014, 15:42 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Cromeshnic писал(а):
У нас тут произошло слияние с компанией, у которой куча меди и АТС-ок и самописный биллинг на всё это (далее следует непереводимый итальянский фольклор).

Иерархия в виде дерева, как в Inet - неправильно. По факту АТС-ки - это облако. Один и тот же звонок проходит через несколько и попадает в несколько CDR. Связать их между собой явно обычно нельзя, т.к. нет сквозного id звонка. Есть самописные эвристические методы связки для дебага прохождения звонков, но это к биллингу не относится..
Есть 2 подхода:
1. Берём данные на входе, т.е. на той АТС, к которой подключен абонент (или заходит транк субоператора). Плюс - мы точно знаем, кого мы тарифицируем. Минус - мы точно не знаем, куда этот звонок уйдёт из облака, т.е. не можем надёжно определить цену (конечного оператора МГМН).
2. Берём данные на выходе из нашего облака. На выходе мы точно знаем, на какого вышестоящего оператора мы отправили звонок и можем точно определить цену. Но клиента, которому нужно этот звонок выставить, мы знаем только по номеру телефона. А этот номер может быть кривой, например. Но это уже будет проблема конфигурации сети - почему наши станции или абонентские АТС шлют плохие А-номера.

Очевидно, вариант 2 правильнее.
Отсюда следствие: транки субоператоров желательно присоединять к тому же узлу (транзитному), с которого они выходят вовне. Тогда можно идентифицировать их звонки просто по входящему/исходящему портам.
Но, во-первых, это не всегда физически возможно.
Во-вторых, в какой-то момент у вас рядом появляется, например, вторая транзитная Voip-АТС и вы часть трафика выводите через неё.
И опять приходится делать выбор, в какой точке снимать CDR.

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

По факту, у нас используется некая промежуточная база для сбора CDR:
- Импорт логов разных форматов в общую базу
- Аналитика и мониторинг по сырым данным станций
- Конфигурация сети (куда какие каналы ведут, присоединённые операторы)
- Отсев до тарификации (?)

Затем уже из этой базы генерируются готовые для тарификации CDR в едином формате.
Такие "подготовленные" CDR удобнее тем, что, например, port_to - это не канал на станции (на каждой - свой), а именно ID оператора (РТ, ТТК и т.п.). port_from можно аналогично использовать как ID "дочерних" операторов.

Было бы круто, если BGBilling имел готовый фреймворк для работы с сырыми данными, вёл топологию сети и т.п.

ps. Всё это со слов опытных товарищей. Вполне возможно, что у кого-то всё по другому.



Постараюсь разобрать это. Это все по поводу обработки cdr ? Пока radius тут не при чем?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 23 дек 2014, 15:51 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Да, без Radius-а.
Попробую призвать местных гуру Voip в этот подфорум.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 23 дек 2014, 15:52 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
И да, в случае с промежуточной базой звонков "источник" модуля Phone перестаёт быть АТС-кой. У нас вообще один источник для всего оператора.
Получается, в Phone имеет смысл разделять источники только если собирать данные с АТС, к которым непосредственно подключен абонент, а не на выходе.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 23 дек 2014, 16:11 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Cromeshnic писал(а):
У нас тут произошло слияние с компанией, у которой куча меди и АТС-ок и самописный биллинг на всё это (далее следует непереводимый итальянский фольклор).

Иерархия в виде дерева, как в Inet - неправильно. По факту АТС-ки - это облако. Один и тот же звонок проходит через несколько и попадает в несколько CDR. Связать их между собой явно обычно нельзя, т.к. нет сквозного id звонка. Есть самописные эвристические методы связки для дебага прохождения звонков, но это к биллингу не относится..


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 23 дек 2014, 20:12 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Можно, но мы достоверно не сможем сказать, на какого оператора межгорода ушел звонок в итоге.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 24 дек 2014, 12:52 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Cromeshnic писал(а):
Можно, но мы достоверно не сможем сказать, на какого оператора межгорода ушел звонок в итоге.

почему не можем сказать? Там маршрутизация динамическая? т.е какая-то из АТС в цепочке сама решает куда уйдет звонок и отправляет его на какой-то порт например и и только по логам этой АТС мы можем понять на какого оператора ушел звонок по порту. так ?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 24 дек 2014, 13:14 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Поговорил ещё раз со знатоками.

1. Да, в теории можно. В теории нужно тарифицировать абонента по CDR абонентских АТС, а свекри с операторами - на стыках с ними. Потом сверять данные внутри у себя и с оператором. Тогда если где-то поменялся маршрут трафика, а абоненту в тарифах это не отразили - такое будет найдено.

2. У нас было так сделано потому, что нельзя положиться на абонентские АТС: некоторые из них могут терять данные, криво выдавать АОН-ы в CDR и т.п. Поэтому было принято решение считать МГМН по более надёжным АТС на стыках с операторами.

3. А ещё есть замечательная услуга Voip-on-demand (хз, как оно называется): клиент набирает короткий номер, звонок уходит на специальную voip-АТС, затем донабирает номер и звонит через VoIP по более дешевым ценам. При этом происходит 2 звонка: местный на сервисный номер и следующий с voip-АТС наружу. Так вот, такие звонки тоже нужно собирать, а делать это можно только с voip-АТС.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 19 янв 2015, 08:58 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Обсудили наше будущее с коллегами.
Что нам ещё нужно от Voice:
1. Производительность. Сейчас в Phone даже пустые файлы загружаются и обрабатываются довольно долго (по-моему, он для каждого файла CDR инициализирует некий контекст, даже если он пустой). Нет парллельной обработки, хотя бы как в IPN (process.thread.count=6).
2. Топология. Для учёта операторского трафика (например, с РТ) по договору присоединения ведётся учёт инициации/завершения звонков в зависимости от топологии сети: "Завершение на присоединённого оператора", "завершение на оператора на узле связи", "завершение на оператора на смежном узле связи", "завершение на оператора с 1 транзитным узлом" и т.д. Для этого ведётся топология сети нашего оператора и, например, РТК. РТК сами каждый месяц присылают нам изменения в своей топологии для корректного учёта. Сейчас в Phone это можно сделать только через правила, где regexp-ом прописывать для каждой услуги списки диапазонов соответствующих узлов.
3. Нам пока не нужно, но вообще стоит подумать про протокол Diameter


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 19 янв 2015, 12:33 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Cromeshnic писал(а):
Обсудили наше будущее с коллегами.
Что нам ещё нужно от Voice:
1. Производительность. Сейчас в Phone даже пустые файлы загружаются и обрабатываются довольно долго (по-моему, он для каждого файла CDR инициализирует некий контекст, даже если он пустой). Нет парллельной обработки, хотя бы как в IPN (process.thread.count=6).


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 19 янв 2015, 12:33 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Cromeshnic писал(а):
Обсудили наше будущее с коллегами.
Что нам ещё нужно от Voice:
1. Производительность. Сейчас в Phone даже пустые файлы загружаются и обрабатываются довольно долго (по-моему, он для каждого файла CDR инициализирует некий контекст, даже если он пустой). Нет парллельной обработки, хотя бы как в IPN (process.thread.count=6).


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 19 янв 2015, 12:44 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Ну да, тут только по договорам или пойнтам параллелить.
Но загрузку CDR-ов в базу точно можно вести параллельно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 28 янв 2015, 08:14 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Ещё хотелки:
- Более лучшая работа с отсевом тарификации (журнал ошибок Phone). Сейчас ошибки - в текстовом виде, анализировать неудобно. Хотя бы группировать их по пойнтам (где определились). Детально показывать, что именно пошло не так - не определена цена/ направление и т.п. Возможно есть смысл реализовать вывод звонков из ошибок сразу в один клик (принудительно устанавливать пойнт звонка(ов), если не найден; тарифицировать в ноль на определённый "мусорный" договор и т.п.)
хотя для "мусорного" договора хватит и первой части - завести мусорный пойнт и стаифом "всё в ноль".
- Сверки с операторами. Ежемесячная головная боль. Т.к. в классической телефонии нет сквозных id звонков, то сопоставлять звонки в детализациях при расхождениях приходится эмпирически - либо ручками в Excel, либо писать специальный софт, который "примерно" ищет для каждого звонка в файле А звонок в файле Б. При этом длительность и время старта может немного отличаться. Пообная штука полезна не только для сверки с операторами, но и для отслеживания маршрута звонка по CDR с нескольких АТС.
- Обмен картотеками. По агентской схеме (на примере РТ), агент высылает оператору список изменений своих клиентов: когда кому подключили/отключили номер, физик/юрик, иногда требуют данные (название, адрес, инн/кпп). Но вообще минимум - физик/юрик для тарификации. Формат обмена зависит от договора: dbf, csv; по почте, по ftp и т.д. Если мы заключаем с нижестоящим оператором субагентский договор для того же РТ, то мы тоже обязаны получать от них такие данные и загружать себе. Планирую делать так: для субагента завдоить 2 субдоговора: для физиков и юриков, и перетаскивать номера с даты между ними скриптами. Некоторые субагенты не готовы автоматизированно выгружать картотеку нам - возможно им было бы удобнее самим управлять пойнтами на своём договоре в лк (либо дать им доступ в BGClient на свой договор, но это мне не нравится). Ещё мы (агент РТ) должны раз в месяц отправлять им книгу продаж: список конечных клиентов с реквизитами, наработкой по услугам РТ и номером счёта-фактуры на эти услуги. Причём для субагентов их конечные клиенты там тоже должны быть прописаны отдельными позициями, и счета-фактуры для них должны выставлять мы сами. Для МТТ то же самое.
Что из этого конкретно реализовывать в BG - нужно думать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 31 мар 2015, 07:35 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Ещё хотелки.
Есть субоператор, у которого 6100 номеров.
1. Считать их через правила неудобно:
- правилу можно сопоставить только 1 услугу
- номера не учитываются в ресурсах (в поиске и т.д.)
Завёл все 6100 номеров на договоре, открывается список номеров довольно долго.

2. Другой нюанс - параллельный учёт по портам и по номерам: viewtopic.php?f=10&t=10135

3. У нас есть прямые договоры на МГМН с некоторыми клиентами этого оператора. Т.е. на часть номеров нужно выставлять МГМН отдельными счетами. Через агентскую схему модуля Phone сделать не получится, т.к. на независимом субе будут считаться все 6100 номеров оператора. Как быть?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 31 мар 2015, 08:33 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
В картах зон и геогр кодах в Phone ужасный поиск - он ищет верхний узел дерева (самый короткий префикс), а не максимально совпадающий.
Т.е. я вбиваю 7912345, а он останавливается на 79


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 31 мар 2015, 13:02 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6055
Карма: 244
Вообще потенциально максимально совпадающие должны быть вверху, очевидно. Тогда всё логично будет, нашёл нужный и вышел?

_________________
I'm clever. I've got a computer.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 31 мар 2015, 13:11 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Там же дерево визуально. Вверху - корень ветки.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 31 мар 2015, 13:18 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6055
Карма: 244
а да точно, я не про это подумал

_________________
I'm clever. I've got a computer.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 07 апр 2015, 12:27 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Неплохо бы в CDR включить поле Call-ID.
Может быть полезно для сверок, отчётности и т.п.
Особенно когда CDR берутся из сторонней системы.

Вообще, мы сейчас думаем над реализацией услуги записи телефонных разговоров. Если мы технически её реализуем, то в личном кабинете нужно будет добавлять ссылки на скачивание файлов записей этих разговоров (по call-id), для чего нам в биллинге нужно собственно знать эти calll-ID в таблице сессий.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 14 апр 2015, 07:31 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Есть карты зон, есть карты цен, но нет карты "зона->цена".
Понятно, что можно задавать в самом дереве соответствие, но это дольше заводить и поддерживать, чем таблицу в mysql.
Обычно операторы МГМН присылают цены как раз в таком виде: одна карта зон и несколько карт "зона - цена".

Пример дерева для РТ, как я бы хотел его видеть:
Код:
-(используемая карта зон: Ростелеком)
-(Фильтр: физ лицо)
---(фильтр: рабочее время)
-----(взять цену по зоне из справочника "Ростелеком -физ лица - рабочее время")
---(фильтр: нерабочее время)
-----(взять цену по зоне из справочника "Ростелеком -физ лица - нерабочее время")
-(Фильтр: юр лицо)
---(фильтр: рабочее время)
-----(взять цену по зоне из справочника "Ростелеком -юр лица - рабочее время")
---(фильтр: нерабочее время)
-----(взять цену по зоне из справочника "Ростелеком -юр лица - нерабочее время")


Физ/юр можно рулить разными тарифами, но не в этом суть.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хотелки для Voice
СообщениеДобавлено: 16 апр 2015, 11:36 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 27 мар 2012, 11:59
Сообщения: 2676
Карма: 72
Операторские отчеты и Тарификация при работе по агентской схеме как в phone


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 65 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 5 часов [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
POWERED_BY
Русская поддержка phpBB
[ Time : 0.172s | 78 Queries | GZIP : On ]