Элтекс

Подскажите, пожалуйста, как работает ДВО с динамической регистрацией Radius, а также как происходит тарификация (radius) переадресованных вызовов?

С динамическими абонентами пока все не просто,
ДВО назначаются на абонентскую ячейку в SMG, но эту ячейку может занять любой динамический абонент,
пока закрепить абонентскую ячейку за динамическим абонентом можно только при помощи SIP-домена, т.е. каждый абонент должен иметь свой домен, но это наверное не просто.
В дальнейшем предусмотрим передачу подключенных абоненту ДВО в ответах от радиус-сервера.

Переадресованный вызов в RADIUS тарифицируется как обычный звонок.

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


По тарификации ДВО:
Получается, дут такие два параллельно:

call leg1: Номер А - Номер Б (Acc Start-Stop)
call leg2: Номер Б - Номер С (Access Request (?), Acc Start-Stop)

Где номер Б - Абонент SMG.
Правильно?

up

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

По тарификации ДВО, немного по-другому сделано,
отправляется только Номер Б - Номер С (Access Request, Acc Start-Stop)

vpr писал(а):С ДВО все понятно.
Получение через Radius - это хорошо, но я не уверен, что у всех это будет поддерживать биллинг. Может предусмотреть альтернативные варианты?
Например, внутреннюю таблицу с привязкой к номеру телефона абонента? Тем более, что абонент может быть разрегистрирован (SMG перезагрузили, а у абонента телефон не подключен неделю, т.к. он в отпуск уехал), а ДВО должно работать. С возможностью ручной чистки, конечно.

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

Женя писал(а):А можно как-то у произодителей билинга поинтерисоваться этим моментом? может уже есть определенные решения?

По тарификации ДВО, немного по-другому сделано,
отправляется только Номер Б - Номер С (Access Request, Acc Start-Stop)

Могу сразу сказать по NetUp UTM5. Никаким ДВО там не пахнет, и в этой жизни не будет. Про другие не могу сказать, но не думаю, что там что-то сильно иное.

Bokrenok писал(а):

vpr писал(а):С ДВО все понятно.
Получение через Radius - это хорошо, но я не уверен, что у всех это будет поддерживать биллинг. Может предусмотреть альтернативные варианты?
Например, внутреннюю таблицу с привязкой к номеру телефона абонента? Тем более, что абонент может быть разрегистрирован (SMG перезагрузили, а у абонента телефон не подключен неделю, т.к. он в отпуск уехал), а ДВО должно работать. С возможностью ручной чистки, конечно.

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

Предполагается - это хорошо, но с чем это будет работать? Только с самописными биллингами или freeradius надстройками?

Женя писал(а):А можно как-то у произодителей билинга поинтерисоваться этим моментом? может уже есть определенные решения?

По тарификации ДВО, немного по-другому сделано,
отправляется только Номер Б - Номер С (Access Request, Acc Start-Stop)

То есть входящий вызов вообще на радиус не поступает? Это как? А как потом тарифицировать межоператорский обмен, например?

Может сделать возможность задать дополнительный радиус сервер для ДВО?
И есть ли возможность выдачи сообщения при определенном event'е (абонент недоступен, занят)?

Предлагаю связаться со мной по почте и описать все что Вы хотите видеть.
Это возможно?