Определение оператора стационарной связи: интерпретация результатов для городских номеров

Практическое руководство по интерпретации данных об исходном операторе и географии распределения для стационарных телефонных номеров.

Определение оператора стационарной связи позволяет получить контекст о диапазоне номеров, к которому изначально был отнесен городской номер. Сервис Определение исходного оператора от CarrierLookup в режиме реального времени может возвращать данные об исходном операторе, базовом операторе, типе номера, коде страны, а также регионе или городе распределения, если эти значения доступны. Эти поля описывают контекст нумерации, а не текущего обслуживающего провайдера или местоположение человека или устройства. Начинайте работу с корректно отформатированным международным номером, считывайте возвращенные поля как факты, специфичные для источника, и оставляйте пустые поля как недоступные. Для больших списков, состоящих преимущественно из номеров одной страны, можно использовать отдельную асинхронную файловую задачу для получения CSV-файла.

Что означает запрос определения оператора стационарной связи

Термин «городской номер» (landline) часто используется для обозначения фиксированных или географических телефонных номеров, однако категории нумерации различаются в зависимости от страны. Планы национальных регуляторов являются отправной точкой для утверждений, специфичных для конкретной страны. Например, британский регулятор Ofcom поясняет, что его коды 01 и 02 определяют географические зоны нумерации; он также предупреждает, что эти коды не указывают на местоположение мобильного телефона. Этот пример иллюстрирует, почему общее международное правило, например «все городские номера начинаются с одного префикса», было бы ненадежным.

CarrierLookup отвечает на более узкий, операционный вопрос: какой контекст исходного распределения доступен для конкретного номера? Его Определение исходного оператора работает синхронно для одного номера и поддерживает маршрут для нескольких номеров. Возвращаемый тип номера может помочь команде отличить классификацию фиксированной линии от мобильной, когда это применимо. Поля оператора и базового оператора описывают исходное распределение диапазона, а не активное соединение. Результат не является тестом вызова, абонентским справочником или способом определить, находится ли линия в данный момент в эксплуатации.

Начните анализ с определения решения, для которого требуется поиск. Команде CRM может потребоваться разделить записи контактов по возвращенному типу номера. Команде маршрутизации может потребоваться контекст исходного оператора как один из входных данных для последующих тестов. Эти цели требуют различных подтверждающих данных. Фиксация точного вопроса предотвращает превращение результата определения оператора в необоснованное утверждение о доставке или личности клиента.

Подготовка городского номера для маршрута в реальном времени

Документированный формат ввода в реальном времени — E.164: знак «плюс», код страны и номер абонента без пробелов и разделителей. Не предполагайте, что внутренний формат набора номера можно отправить без изменений. Национальные префиксы и правила использования кодов зон различаются, поэтому правило нормализации для конкретной страны следует сверять с соответствующим планом нумерации, прежде чем изменять исходную запись. Сохраняйте исходную строку в том виде, в котором она была получена, и нормализованный вариант в отдельных полях. Это делает случайное удаление или дублирование кода страны заметным при проверке.

POST /api/v1/check — это документированный маршрут для одного номера. Синхронный маршрут POST /api/v1/batch-check принимает группу номеров и сохраняет порядок ввода. На панели управления также есть рабочий процесс для нескольких номеров в реальном времени. Это проверки, возвращаемые в потоке запросов; они отличаются от файловой задачи, которая завершается позже. Используйте документацию API CarrierLookup для получения актуального контракта запроса и деталей интеграции. Ключ API должен находиться на защищенном сервере, а не в коде браузера или опубликованном примере.

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

Отдельное считывание типа номера, оператора и географии

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

Поля региона и города, если они присутствуют, относятся к географии распределения диапазона номеров. Они не являются местом проживания человека, текущим местоположением устройства или доказательством того, что стационарная линия физически установлена в этом городе сегодня. Данные о нумерации Ofcom показывают, как регулятор может публиковать информацию о распределении диапазонов; это не превращает метку распределения в трекер местоположения. Код страны аналогичным образом описывает контекст нумерации и не должен представляться как национальность человека.

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

Отделение городских номеров от мобильных в смешанном списке

Смешанный экспорт из CRM часто содержит номера в локальном формате, международные номера, дубликаты и записи без четкого типа. Составьте рабочий список перед проверкой. Нормализуйте каждого кандидата, используя правило для конкретной страны, сохраните исходное значение и пометьте неоднозначные строки для ручной проверки. Запустите небольшую проверку в реальном времени, когда команда изучает новые записи или нуждается в синхронном результате. При импорте объедините результат с нормализованным вводом и сохраните возвращенный тип номера в отдельном поле. Не используйте таблицу префиксов в качестве окончательной классификации для записей с возвращенным значением продукта.

Для большого списка, состоящего преимущественно из номеров одной выбранной страны, отдельный Глобальный поиск оператора принимает одностолбцовый TXT или CSV-файл с одним номером с кодом страны в строке. Он выполняется асинхронно. Документированные маршруты API: POST /api/v1/bulk-tasks для отправки и GET /api/v1/bulk-tasks/{id} для получения статуса; делайте запросы не чаще, чем раз в 30 секунд. Успешная задача выдает один CSV-файл с полями оператора и распределения, документированными для этого продукта. Текущие условия принятия данных указаны в документации к продукту и API. Не отправляйте рабочие книги и не предполагайте, что файловый маршрут принимает файл с номерами разных стран только потому, что это делает маршрут в реальном времени.

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

Превращение результата в действие по тщательной проверке

Полезная запись контакта хранит исходный ввод, нормализованный номер, продукт поиска, дату поиска, возвращенный тип номера, исходного оператора и любую географию распределения как отдельные поля. Это предлагаемые варианты внутреннего учета, а не обещание, что каждое поле будет заполнено. Команда может создать очередь проверки для записей, тип которых конфликтует с исходной базой данных, поля оператора которых пусты или нормализация которых требует исправления. Избегайте интерпретации каждого пропуска как недействительного номера; обычный завершенный поиск может иметь недоступные необязательные поля.

Перед использованием результата для маршрутизации или связи подтвердите другие факты, которые требуют эти задачи. CarrierLookup не устанавливает доступность, согласие, личность абонента или текущее местоположение. Решение о соответствии требованиям или разрешениях принадлежит собственным записям организации и применимому процессу. При понимании этих границ поиск может поддержать более четкое разделение записей контактов на городские и мобильные, а также более прозрачное объяснение того, что на самом деле показывают данные.

Часто задаваемые вопросы

Могут ли команды узнать текущего провайдера стационарной связи с помощью этого поиска?

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

Показывает ли возвращенный город, где сейчас находится пользователь городского номера?

Нет. Поля города и региона описывают географию распределения для диапазона номеров, когда она доступна. Это не текущее местоположение или адрес человека. Если поле пустое, оставьте его как недоступное. Если команде нужен адрес для разрешенного бизнес-процесса, следует использовать независимо собранную адресную запись.

Следует ли помечать городской номер с пустыми полями оператора как недействительный?

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

Узнать больше

Выберите информацию о продукте, которая соответствует следующему шагу в вашем рабочем процессе.

• Просмотреть документацию по продукту →
• Связаться с командой →