Настройка и понимание погружения LRN и переносимости  номеров

 

Обзор

Понижение номера локальной маршрутизации (LRN)  — последовательность маршрутизации для завершения вызовов на телефонный номер клиента, включая сервер точки управления услугами, для обеспечения переносимости номера. 

Переносимость номера  — дает владельцу номера право переназначить существующий номер телефона другому оператору связи, местоположению, услуге или провайдеру.

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

Настройка погружения LRN и переносимости номера

Поставщик LRN предоставит вам необходимые учетные данные для настройки процесса LRN Dipping для ваших вызовов, включения LRN и, как следствие, маршрутизации переносимости номера.

1. Добавьте данные сервера LRN в меню раздела « Системные параметры/SIP, Медиа, LRN»  (см. поиск в шаге 4). Адрес сервера LRN указан как IP-адрес/имя хоста внешнего сервера LRN.    

1.1 Поддерживается пользовательский порт (начиная с Flysip 2020) . Во всех более ранних версиях жестко запрограммировано отправлять INVITE на сервер LRN на его порт 5060, поэтому там не ожидается только IP-адрес/имя хоста ни для одного порта. 

1.2 Начиная с Flysip 2021 , более одного сервера LRN можно настроить в виде списка, разделенного запятыми. 

2. Для LRN можно настроить набор таймаутов: Адрес сервера  указан как IP-адрес  внешнего  сервера LRN.

2.1 Тайм-аут LRN-сервера — время, которое система должна ждать, чтобы получить ответ от LRN-сервера, прежде чем попробовать следующий LRN-сервер в списке. Обратите внимание, что этот тайм-аут заменяется тайм-аутом LRN Request(Total) Timeout , который ограничивает общее количество времени, отведенное на выполнение поиска LRN для вызова. Доступно начиная с версии 2021 года.    

2.2 Тайм-аут запроса LRN (общий)   (секунды): глобальный тайм-аут для всех серверов LRN. Это время, которое система выделяет для поиска LRN перед маршрутизацией вызова с использованием CLD. Доступно начиная с версии 5.2. 

3. Если необходимо кэширование прошлых запросов к провайдеру LRN, установите флажок Включено кэширование LRN и выберите необходимое значение для LRN Cache Expires в . Flysip сохраняет результаты LRN в течение заданного периода времени: от 1 дня до 3 месяцев.   

Пожалуйста, перейдите в соответствующий раздел:

4. Если Продавцу требуется получить номер, полученный от сервера LRN, в RURI, начиная с Flysip 2021 , его можно добавить, включив опцию «Добавить LRN в RURI» .    

5. Включите LRN  в указанной вами группе маршрутизации. При настройке сервера LRN поиск LRN будет выполняться для любого исходящего вызова, который завершается через эту группу маршрутизации, либо в кэше, либо путем дополнительного поиска у провайдера LRN. ЕСЛИ флажок «Включено кэширование LRN» не установлен, каждый вызов через такую ​​​​маршрутизацию Группа инициирует поиск поставщика LRN.  

6. При необходимости укажите правило преобразования LRN в соответствии с нашим Пониманием о преобразовании номеров. Например, указанное правило «s/^/1/» добавит префикс «1» к каждому запросу LRN, направленному вашему провайдеру LRN, и приведет к тому, что вызов будет тарифицироваться в соответствии с вашим префиксом «1*».   

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

Результирующие CDR для маршрутизированных вызовов в соответствии с наклоном LRN и переносимостью номера будут показаны в отчете с LRN_CLD.

Примечание : начиная с версии 5.2, когда настроен локальный вызов , Flysip может выполнять дополнительный поиск CLI — в этом случае LRN_CLI будет добавлен в отчет CDR.  

-------------------------------------------------- -------------------------------------------------- ---------------

Последовательность вызовов с включенным понижением LRN выглядит следующим образом:

1. Поступает звонок. 

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

3. Flysip отправляет запрос INVITE на сервер LRN с CLD. 

4. Ответ LRN перезаписывается с использованием «Правила трансляции LRN». 

Назовем результат «LRN CLD».

Пример ответа, полученного от провайдера LRN:

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

Обязательные параметры следует располагать слева от @

• npdi  — сервер LRN указал, что номер изменился
• rn  - номер маршрута, после rn= следует LRN CLD
• за номером маршрута  (после rn=) должен следовать символ @  
• имя хоста/IP-адрес  после символа @

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

Из всего пакета 302 Moved временно используется только номер маршрутизации (213xxxx933).

За номером маршрутизации ДОЛЖЕН следовать знак @, после знака @ ДОЛЖЕН быть хост/IP, чтобы мы могли отличить имя пользователя в номере маршрутизации от имени хоста.

Все остальные случаи будут рассматриваться так, как будто мы ничего не получили от поставщика LRN: 

Поставщик LRN также может отправить нам формат контактной строки, который мы не можем правильно распознать.

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

Во всех вышеперечисленных случаях LRN CLD не будет извлечен из пакета.

5. Программный коммутатор взимает с Учетной записи плату, основанную на LRN_CLD. 

Если от поставщика не было получено CLD LRN, то плата будет взиматься на основе исходного CLD.

5.1 Если LRN включен и префикс для LRN_CLD не найден в Тарифе, вызов будет отклонен с сообщением «Нет тарифа».

6. Программный коммутатор выбирает список записей маршрутизации из группы маршрутизации с соответствующими соединениями поставщика для отправки вызова на основе LRN_CLD  .

если в соединении не установлен флажок «Игнорировать LRN», то используется оригинальный CLD. 

Обратите внимание, что маршрутизация будет применяться для соединений с исходным CLD и LRN CLD на основе политики маршрутизации.

6.1. Если LRN не игнорируется, то в наборе адресатов выполняется поиск префикса на основе CLD LRN, и вызов отправляется с CLD, отличным от LRN (только исходный CLD), переписанным с использованием правила трансляции CLD компании Vendor Connections.

6.2. Если LRN игнорируется, то в наборе адресатов выполняется поиск префикса на основе CLD, отличного от LRN (только исходный CLD), и вызов отправляется с CLD, отличным от LRN (только исходный CLD), переписанным с использованием правила трансляции CLD компании Vendor Connections.

6.3 Если LRN включен и префикс для LRN CLD не найден в наборе адресатов, соответствующая запись маршрутизации не будет использоваться для этого вызова. Если соответствующие записи маршрутизации не найдены, вызов будет отклонен с ошибкой «Нет маршрута найден». .

В CDR вы можете видеть только оригинальные CLD, LRN CLD там не отображается. Поскольку LRN CLD используется только для выставления счетов/маршрутизации (а не для фактической настройки вызовов), вы можете увидеть новый параметр «Префикс выставления счетов» для CDR загрузки поставщика и CDR клиентов в системе самообслуживания.

Нет необходимости добавлять LRN IP в качестве поставщика.

Начиная с версии 2020 года в RURI исходящего INVITE поставщику можно поместить LRN CLD (rn/ndpi).

Этого можно добиться, установив флажок «Добавить LRN к RURI» в «Системных параметрах — SIP» . Это изменение повлияет на вызовы любого соединения в среде.   

Сокращенная последовательность маршрутов:

1. Получен ORIG_CLD
2. Применить авторизацию. Правило CLD tr для ORIG_CLD, получен CLD
3. Примените правило CLD tr учетной записи для CLD, получите CLD
4. LRN отправил запрос с CLD (IP LRN должен быть только в "системных параметрах"), получил в ответ что-то вроде LRN_CLD
5. Поиск маршрутов по LRN_CLD (используйте «Включить LRN» в группе маршрутизации), но для фактического вызова используйте простой CLD.
6. По каждому маршруту:

          6.1 Примените поставщик->соединение -> «правило CLD tr» для CLD, в результате получите CLD_OUT
          6.2 Отправьте вызовы через соединение с CLD_OUT

Начиная с версии 2021, CDR содержат результаты поиска LRN, например «Успешно», «Не удалось», «Успешно из кэша» или «Не требуется»: