Шаг 16. Звонки во внешние сети

Кейс: Пользователь набирает на телефоне 9 и городской номер, осуществляется вызов городского номера, пользователь слышит сигналы КПВ (код посылки вызова), после ответа внешнего абонента они соединяются в диалоге.

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

В текущем кейсе маршрутизация определила в качестве цели внешнее направление. Для этого администратор домена настроил сущности route и vectorrule, последняя в свою очередь ссылается на сущность provider, которую также предварительно создал администратор домена.

Для того, чтобы система могла интегрироваться с провайдерами телефонии и корпоративными АТС, администратор добавляет в конфигурацию роль ESG. Администратор домена настраивает сущности provider и provider_callerid.

Сущность provider определяет конкретный экземпляр ESG, который обеспечивает поддержку канала и является промежуточным сервером, через который проходят все звонки из системы к провайдеру и наоборот. Сущность provider имеет большое количество настроек, позволяющих детализировать поведение ESG при работе с этой учетной записью. Соответственно, учетная запись может:

  • работать с регистрацией на стороне провайдера или без (по прямым IP-адресам),

  • устанавливать username, логин, пароль, доменное имя,

  • устанавливать использование outbound proxy-сервера, указывая IP-адрес и порт,

  • устанавливать дополнительные адреса и доменные имена, с которых могут приходить пакеты от провайдера,

  • устанавливать использование регулярной отправки ping-пакетов в различных форматах,

  • устанавливать использование BGMG (шаг 14),

  • прочее.

Роль ESG, а именно тот экземпляр, который установлен в учетной записи provider, производит и поддерживает её регистрацию на внешнем сервере. В тот момент, когда через ESG проходит звонок (в любую сторону), там, аналогично B2BUA, образуется два плеча одного диалога. Любой звонок, проходящий через систему, всегда имеет посередине ровно один сервер B2BUA. Таким образом, например, в маршруте звонка между внешним абонентом и внутренним абонентом присутствуют 3 SIP-сервера: ESG, B2BUA, SG, и как следствие этот звонок имеет 3 плеча с различающимися идентификаторами.

esg_call

При этом внутри и снаружи системы возможно сохранение единой информации об абонентах, либо настроить модификации From:Displayname, From:Username, To:Username. Делается это с помощью сущностей домена типа provider_callerid. Эти правила применяются аналогично правилам маршрутизации: детектируется самое приоритетное подходящее правило (на основе масок направления, From и To), и производятся модификации From:Displayname, From:Username, To:Username.

Для сокращения числа правил provider_callerid в домене может применяться группировка – одно правило provider_callerid на несколько учетных записей provider, а также двухэтапная модификация: сначала применяются модификаторы From, а затем вторым проходом модификаторы To.

Перевод внешнего звонка

Особенность роли ESG в том, что она самостоятельно обрабатывает REFER. Такая концепция реализована, поскольку номерной план во внешней системе (ГТС, провайдер телефонии, либо сторонняя АТС предприятия) и номерной план внутри системы в общем случае не синхронизированы.

Кейс: В диалоге общаются внешний абонент Aлиса (A, за провайдером) и внутренний пользователь Борис (B). Алиса производит перевод Бориса на Варвару ©, номер которой известен ей и достижим во внешней сети. Варвара является внешним абонентом для системы и для Бориса.

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

esg_refer_ext
Кейс: В диалоге общаются внешний абонент Aлиса (A, за провайдером) и внутренний пользователь Борис (B). Борис производит перевод Алисы на Владимира ©, номер которого известен ему и достижим во внутреннем номерном плане.

Аналогично, при получении REFER изнутри системы ESG трактует это как необходимость вызвать абонента посредством внутренней маршрутизации. И действительно, внешний абонент ни при каких обстоятельствах не сможет обработать этот REFER правильным образом самостоятельно, и, скорее всего, оставит его снаружи, а не приведет другим звонком внутрь системы. Если же внутреннему пользователю необходимо перевести звонок на другого внешнего абонента, то это всё равно будет сделано через внутреннюю маршрутизацию и через один из экземпляров роли B2B, то есть с сохранением диалога внутри системы.

esg_refer_int
Table 1. Используемые термины
Термин Определение

КПВ (код посылки вызова)

!

ESG

!

provider

!

provider_callerid

!
  • Персонализация
  • Увеличить шрифт
  • Уменьшить шрифт