Перейти до вмісту

Зміна тарифу й маршрутизації після автентифікації

Цей переклад зроблено автоматично і ще не вичитано. Читати англійську версію

Правило автентифікації може перевизначити тариф і групу маршрутизації акаунта, але лише для дзвінків, які воно автентифікує. Дзвінки зареєстрованих пристроїв, що входять через SIP digest, і дзвінки, що надходять через DID Pool (пул DID), ніколи не проходять через правило автентифікації акаунта. Правила після автентифікації закривають цю прогалину: вони застосовуються, коли акаунт уже відомо, хоч би як його було знайдено, і вибирають дзвінки за віддаленою IP-адресою, CLI і CLD. У цьому посібнику ви спрямуєте дзвінки одного акаунта до Великої Британії через окрему групу маршрутизації й тариф. Закладіть близько 20 хвилин.

Акаунт із прикладу office-pbx (ID 3092) реєструється з digest-обліковими даними. Його дзвінки на номери, що починаються з 44, мають використовувати тариф UK premium (ID 12) і групу маршрутизації UK premium (ID 7).

  • Тариф і група маршрутизації існують, і ви знаєте їхні ID: i_tariff та i_routing_group в URL панелі, коли ви їх відкриваєте, або з API.
  • Ви можете викликати XML-RPC API, як описано в розділі Огляд API. У прикладах використовується допоміжна функція call() з розділу Виклик API з Python.

Крок 1: Зрозумійте, коли застосовується правило

Розділ «Крок 1: Зрозумійте, коли застосовується правило»

Після того як комутатор автентифікував дзвінок і застосував правила трансляції правила автентифікації, він шукає правило після автентифікації акаунта, що збігається з дзвінком:

Поле Зіставляється з Синтаксис шаблону
remote_ip IP-адреса, з якої надходить дзвінок точний збіг
cli Номер того, хто дзвонить символи підстановки
cld Набраний номер символи підстановки

Правилу потрібне хоча б одне з трьох полів; поле, яке ви залишаєте порожнім, збігається з будь-яким дзвінком. У cli і cld:

  • * відповідає будь-якій послідовності символів: 0038* збігається з 0038943794.
  • ? відповідає одному символу: 0?7834 збігається з 007834 і 017834.
  • [1-5] відповідає одному символу з діапазону, [^p] — одному символу, що не є p.
  • \ робить наступний символ буквальним: \* — це зірочка.

abc?_[1-5][2]0* збігається з abcd_1201234567, але не з abcde_1201234567.

Коли правило збігається, дзвінок отримує тариф і групу маршрутизації правила замість налаштувань акаунта, а правила трансляції CLI і CLD цього правила переписують номери. Власні правила трансляції акаунта виконуються після цього. Повний порядок див. у розділі Трансляція номерів.

Результат: ви знаєте, які поля заповнити для свого випадку.

Крок 2: Додайте правило

Розділ «Крок 2: Додайте правило»

Викличте addPostAuthRule з акаунтом і шаблоном CLD:

call("addPostAuthRule", {
"i_account": 3092,
"cld": "44*",
"i_tariff": 12,
"i_routing_group": 7,
})
response
{"result": "OK", "i_post_auth_rule": 418}

Додайте "remote_ip": "198.51.100.20", щоб застосовувати правило лише до дзвінків з IP-адреси офісу. Додайте "cld_translation_rule" або "cli_translation_rule", коли нова група маршрутизації очікує інший формат номера, наприклад s/^44/0/.

Результат: акаунт має правило після автентифікації з ID 418.

Крок 3: Перевірте роботу

Розділ «Крок 3: Перевірте роботу»
  1. Викличте listPostAuthRules з {"i_account": 3092} і перевірте поля правила.
  2. Зробіть тестовий дзвінок із пристрою, зареєстрованого як office-pbx, на номер, що починається з 44.
  3. Відкрийте Reports → Call Records (CDRs) (записи про дзвінки) і деталі дзвінка. I-Post-Auth-Rule (ID правила після автентифікації) у розділі Call Authentication (автентифікація дзвінка) показує 418, а ціна й вендор беруться з UK premium.
  4. Зробіть дзвінок на інший напрямок. I-Post-Auth-Rule порожнє, і застосовуються тариф і група маршрутизації акаунта.

Щоб пізніше змінити правило, викличте updatePostAuthRule з i_post_auth_rule і полями, які ви змінюєте; щоб видалити його, викличте deletePostAuthRule.