Pull to refresh

Comments 13

имхо, если решил упрощать dialplan, то надо всю логику по определению направления выносить в скрипт и на выходе только направление получать

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

Например, в приведенной выше статье мне не нравится использование odbc-функций, т.к. получается, что астериск «знает» БД. Дальше там в комментариях приводятся скрипты. А скрипты сегодня работают, а завтра что-то поменял и «все сломалось».

То ли дело отдельный сервис по определению направления, покрытый тестами, который имеет очень простой интерфейс взаимодействия. Диалплан «ведет» звонок, а agi-сервис в нужный момент просто подставляет переменную.
А это актуально? На долго ли? Всё чаще люди пользуются переносом номера от провайдера к провайдеру, то есть какой-то процент будет ошибочным.
Перенос номера возможен только в пределах региона, т.е. смена провайдера не меняет регион.
За исключением йоты.
1. в России порядка 240 млн.абонентов сотовых операторов (пруф)
2. еще есть стационарные телефонные сети порядка 40 млн.абонентов (пруф)
3. услугой по смене сотового оператора с сохранением номера воспользовались чуть более 1 млн.абонентов (данные на сайте ФАС в правой колонке)
4. не изменяется регион (возьмем, например, правила МТС)

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

Вот с определением оператора мобильного номера, вероятность ошибки уже 1/240 — тут да, надо проверять на np.zniis.ru
Вот с определением оператора мобильного номера, вероятность ошибки уже 1/240 — тут да, надо проверять на np.zniis.ru
А вот это вы делаете как-то в автоматическом режиме?
У них есть API или всё на самописных скриптах?
Я это не делаю. У ЦНИИС нет API. Раньше можно было дергать запросом, сейчас там повешали капчу. Есть ли еще у кого-то API? Не знаю.
Сотовые операторы периодически перекидывают диапазоны номеров из региона в регион, раз в месяц надо бы обновлять данные, чтобы поддерживать актуальность
Да, данные периодически меняются. При чем не только мобильные операторы, но и Федеральное агентство связи регулярно проводит работу по изменению диапазонов, смены операторов и т.д.
В репозитории numcap если посмотреть коммиты, то можно увидеть что меняется из месяца в месяц, также есть команды для актуализации данных.

По поводу данных, интересно как Вы преобразовали регионы (там где указана только область и там где указана и область и город). Как отрабатывается в базе поиск регионального офиса, если в выбранном регионе нет выхода? Например звонок из Омска, имеет смысл послать входящий в Новосибирск.
1. Определение региона при преобразовании БД numcap как раз и идет по наличию признака региона: 'область', 'край' и т.д., т.е. если указано «Новосибирск | Новосибирская область» будет установлен код Новосибирской области.

2. Логику маршрутизации можно построить в астериске по-разному: перечислить коды нужных регионов и отправить их по одному маршруту или воспользоваться номером федерального округа (Омская и Новосибирская области относятся к Сибирскому ФО) и для него указать свой маршрут.
То бишь автоматической таблетки не придумано? Я просто мыслил что-то по аналогии с GeoIP только с учетом стоимости звонка на направление в целом или по ближайшему региону к звонящему.
Опять же вариант с роумингом — звонок на 8-800, попадаем в Нск, а надо в Мск, так как я тут в коммандировке. А так как роуминг, то и ценник выше будет для таких звонков. Хотя вряд ли мобильный оператор поделится регионом откуда пришел звонок.
Если бы в роуминге ваш номер подменялся на какой-то номер из зоны присутствия, тогда можно было бы сделать по аналогии с GeoIP. А так да, возможны накладки.
Sign up to leave a comment.

Articles