Компоненты и топологии для контроля допуска звонков в Skype для бизнеса

Планирование отчета по контролю допуска звонков (CAC) при наличии сети MPLS, магистрали SIP или шлюза ТСОП или УАТС. Применимо к Skype для бизнеса Server Корпоративная голосовая связь.

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

Контроль допуска звонков в сети MPLS

В сети с многопротокольной коммутацией по меткам (MPLS) все сайты соединены в полную сетку. Это значит, что все сайты подключаются напрямую к MPLS-магистрали поставщика услуг Интернета, и каждому сайту выделяется полоса пропускания, используемая для взаимодействия по каналу глобальной сети с MPLS-облаком. Не существует ни сетевого концентратора, ни центрального сайта для управления IP-маршрутизацией. На следующем рисунке показана простая сеть, основанная на технологии MPLS.

Пример сети MPLS

Чтобы развернуть контроль допуска звонков в сети MPLS, требуется создать область сети, представляющую облако MPLS, и создать сетевой сайт, представляющий каждый вспомогательный сайт MPLS. На следующем рисунке показано, как следует настроить область сети и сетевые сайты, чтобы они представляли пример сети MPLS на предыдущем рисунке. Ограничения для общей пропускной способности и пропускной способности сеанса основываются на емкости канала связи глобальной сети от каждого сетевого сайта к области сети, которая представляет облако MPLS.

Область сети и сетевые сайты для сети MPLS

Контроль допуска звонков на канале SIP

Для развертывания контроля допуска звонков в магистрали SIP создается сетевой сайт, который представляет поставщика услуг интернет-телефонии (ITSP). Для применения значений политики пропускной способности в магистрали SIP создается межсайтовая политика между сетевым сайтом на предприятии и сетевым сайтом, созданным для представления ITSP.

На следующем рисунке показан пример развертывания контроля допуска звонков в магистрали SIP.

Конфигурация контроля допуска звонков в магистрали SIP

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

1. Создать сетевой сайт для представления поставщика услуг интернет-телефонии (ITSP). Вписать этот сетевой сайт в соответствующий сетевую область и выделить для этого сетевого сайта нулевую пропускную способность для аудио и видео. Дополнительные сведения см. в разделе Configure Network Sites for CAC документации по развертыванию.

   Примечание.

   Для ITSP конфигурация этого сетевого сайта не функциональна. Значения политики пропускной способности фактически применяются в шаге 2.

2. Создать межсайтовую связь для магистрали SIP с помощью соответствующих значений параметров для сайта, созданного на шаге 1. Например, можно указать имя этого сетевого сайта на предприятии в качестве значения параметра NetworkSiteID1, а имя сетевого сайта ITSP — в качестве значения параметра NetworkSiteID2. Дополнительные сведения см. в статьях Создание политик межсетевой сети в Skype для бизнеса Server документации по развертыванию и New-CsNetworkInterSitePolicy.

3. Получите IP-адрес точки завершения мультимедиа контроллера границ сеанса (SCB) из ITSP. Добавить этот IP-адрес с маской подсети 32 к сетевому сайту, представляющему ITSP. Дополнительные сведения см. в разделе Associate a Subnet with a Network Site.

Контроль допуска звонков с помощью стороннего шлюза ТСОП или УАТС

В этом разделе описаны примеры развертывания управления допуском звонков (CAC) на канале между интерфейсом шлюза сервера-посредника и сторонним шлюзом телефонной сети общего пользования (ТСОП) или частной УАТС.

Случай 1. Контроль допуска звонков между сервером-посредником и шлюзом ТСОП

CAC можно развернуть по каналу глобальной сети из интерфейса шлюза сервера-посредника в стороннюю УАТС или шлюз ТСОП.

Случай 1. Контроль допуска звонков между сервером-посредником и шлюзом ТСОП

В этом примере CAC применяется между сервером-посредником и шлюзом ТСОП. Если пользователь Skype для бизнеса клиента на сетевом сайте 1 отправляет вызов по ТСОП через шлюз ТСОП на сетевом сайте 2, мультимедиа передаются по каналу глобальной сети. Поэтому для каждого сеанса ТСОП выполняются две проверки контроля допуска звонков.

• Между клиентским приложением Skype для бизнеса и сервером-посредником

• Между сервером-посредником и шлюзом ТСОП

Проверки выполняются как для входящих звонков ТСОП, поступающих в клиент на сетевом сайте 1, так и для исходящих звонков ТСОП из клиентского приложения на сетевом сайте 1.

Случай 2. CAC между сервером-посредником и сторонней УАТС с точкой завершения мультимедиа

Эта конфигурация аналогична случаю 1. В обоих случаях сервер-посредник знает, какое устройство завершает носитель на противоположном конце канала глобальной сети, а IP-адрес шлюза ТСОП или УАТС с точкой завершения мультимедиа (MTP) настраивается на сервере-посреднике в качестве следующего прыжка.

Случай 2. Контроль допуска звонков между сервером-посредником и сторонней УАТС с точкой MTP

В этом примере CAC применяется между сервером-посредником и УАТС/MTP. Если пользователь Skype для бизнеса клиента на сетевом сайте 1 отправляет вызов по ТСОП через УАТС/MTP, расположенную на сетевом сайте 2, носитель передается по каналу глобальной сети. Поэтому для каждого сеанса ТСОП выполняются две проверки контроля допуска звонков.

• Между клиентским приложением Skype для бизнеса и сервером-посредником

• Между сервером-посредником и УАТС/MTP

Проверки выполняются как для входящих звонков ТСОП, поступающих в клиент на сетевом сайте 1, так и для исходящих звонков ТСОП из клиента на сетевом сайте 1.

Случай 3. CAC между сервером-посредником и сторонней УАТС без точки завершения мультимедиа

Случай 3 несколько отличается от первых двух. Если на сторонней УАТС нет MTP, для исходящего запроса сеанса к сторонней УАТС сервер-посредник не знает, где будет заканчиваться носитель на границе УАТС. В этом случае мультимедиа передаются непосредственно между сервером-посредником и сторонним устройством конечной точки.

Случай 3. Контроль допуска звонков между сервером-посредником и сторонней УАТС без точки MTP

В этом примере, если пользователь клиента Skype для бизнеса на сетевом сайте 1 отправляет вызов пользователю через УАТС, сервер-посредник может выполнять проверки CAC только на прокси-сервере (между клиентским приложением Skype для бизнеса и сервером-посредником). Так как сервер-посредник не имеет сведений об устройстве конечной точки во время запроса сеанса, проверки CAC невозможно выполнить по каналу глобальной сети (между сервером-посредником и сторонней конечной точкой) до создания вызова. Однако после установки сеанса сервер-посредник упрощает учет пропускной способности, используемой на магистрали.

Для вызовов, исходящих из сторонней конечной точки, сведения об этом устройстве конечной точки доступны во время запроса сеанса, а CAC проверка могут выполняться на обеих сторонах сервера-посредника.