Нужен узел "Диапазон трафика" как в Inet.
В phone такой узел привязан к зоне. А мне нужно несколько зон включить в него.
Причём хотелка маркетологов такая: есть бесплатный пакет минут на 3 зоны: местные внутри сети, местные вне сети, и мобильные по области. А сверх пакета ценники на них разные.
В phone буду выкручиваться двумя разными картами зон: сначала берём общую зону "пакет", а внутри диапазона превышения заново определяем зону из другой карты зон.
Надеюсь, получится.

Вам нужно отвязать диапазон зоны - это правильно?

Это же сделано в принципе( не реализована как раз пока наоборот связка с зоной для совместимости с phone).

А еще в phone у нас каждый диапазон привязан к поинту - это пока убрали тоже(но для совмести с phone нужно добавить).

Сделано в Voice на 6.2?

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

Неплохо бы в CDR включить поле Call-ID.
Может быть полезно для сверок, отчётности и т.п.
Особенно когда CDR берутся из сторонней системы.

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

Вот это сделано в Voice, кстати?
Сейчас я например собираюсь в phone писать внешний id звонка в CDR в поле "категория" (неиспользуемое).
Но выдёргивать автоматизированно неудобно получается: log_session->data_log<yymmdd>
Т.е. просто join не сделаешь, т.к. data_log дневные, а "категория" из CDR будет только там.

Предложение в качестве бреда
Может быть нам вообще сделать "универсальный" лог и к нему универсальный тарифный узел?
Например:
cdr_format=1:Caller-ID:A-Номер;2:Calling-ID:Б-Номер;3:Session-Time:Время сессии;4:Custom:Порт исходящий
смысл этой записи: при парсинге лога 1е поле системное CallerID, 2е поле системное CallingID, 3 системное SessionTime, 4 - пользовательское

Таким образом мы сами сможем описывать формат лога для парсера, и использовать это в тарифных узлах. Я понимаю, что форматов логов для каждой АТС может быть уйма, и, соответственно брать все описания для тарифного дерева может быть неудобным. Тогда можно сделать оговорку, например вы даете нам всего 64 пользовательских переменных
USR_VAR1 ... USR_VAR64. В общем файле мы делаем их описание для наглядного представления в ТП:
USR_VAR1=Порт исходящий
USR_VAR2=Порт входящий

ну и описание формата получается примерно таким:
cdr_format=1:Caller-ID:A-Номер;2:Calling-ID:Б-Номер;3:Session-Time:Время сессии;4:USR_VAR1:Порт исходящий

"Пусть бредовая идея, вы не решайте сгоряча,
Вызывайте нас скорее через гада главврача" (с) Высоцкий

То что можно парсить самим это замечательно. Насчет узла: я имею в виду, что было бы неплохо кроме стандартных полей позволить использовать в узлах тарифного плана еще и пользовательские поля.

Ещё хотелка - визуальное отображение количества звонков по источнику.
В виде столбцов по дням, например + подсвечивать выходные (обычно меньше звонков).
Можно отдельно выводить количество CDR и количество протарифицированных из них.

Почитал доку. Пока там ещё не всё описано.
Есть вопросы:
- Как для радиус-звонков реализована тарификация по нескольким МГМН-операторам ("порты" в Phone)? (абонентская, не операторская)

- Как реализовано управление не-радиус номерами ("шлюзы" в Phone)?

- Будет ли в дальнейшем поддержка доп. опций радиуса при авторизации - аналог "опций" модуля Inet? Динамическая маршрутизация, всякие переадресации, вот это всё.

- И да, аккаунты на договоре можно переносить с даты?

Не совсем понял, опишите как это было в phone. Сейчас так же можно добавлять порты на аккаунт.

Если надо добавим, только мне это надо кому-то внедрить на тестовом стенде для конкретной задачи чтобы не делать сферического коня в вакууме.

Пока нет, но можно сделать. Я предлагаю начать внедрять и сделать все это в процессе.

можете сделать, чтобы на независимом субе оседали не только звонки телефонов супера, но и звонки телефонов с зависимых субов супердоговора?
У нас на супердоговоре нет услуг - всё висит на зависимых субах.

У нас МГМН идёт через нескольких операторов: агентские и VoIP.
Агентская схема с независимыми субами не используется (хотя нас к ней склоняют теперь).
В CDR port_to пишется id оператора, затем в общем тарифе на МГМН в зависимости от port_to применяется соответствующая тарифная ветка (карта цен или карта зон - где как).

Перечитал 2 раза и не понял. При чем тут независимый суб и звонки зависимых субов ?

Мне интересно именно, как будет определяться порт (оператор МГМН) в случае Radius.
Будет использоваться VoiceNas.OPERATOR_ACCOUNT или другой подобный атрибут?