Определение своих требований для контроля допуска звонков в Lync Server 2013

 

Последнее изменение раздела: 2013-10-28

Для планирования контроля допуска звонков (CAC) необходимы подробные сведения о топологии сети предприятия. Чтобы успешно спланировать контроль допуска звонков, выполните следующие действия.

  1. Укажите концентраторы или магистральные области (называемые сетевыми регионами) в вашей корпоративной сети

  2. Укажите офисы или филиалы (называемые сетевыми сайтами) в каждом сетевом регионе.

  3. Определите сетевой маршрут между каждой парой сетевых регионов.

  4. Определите ограничения полосы пропускания для каждого соединения WAN.

    Примечание.

    Ограничения пропускной способности относятся к объему пропускной способности на канале глобальной сети, выделенной для трафика Корпоративная голосовая связь аудио- и видеосвязи. Если WAN-канал характеризуется как соединение с ограниченной полосой пропускания, это значит, что для этого WAN-канала установлено ограничение пропускной способности, которое меньше значения ожидаемого пикового трафика.

  5. Определите IP-подсети, назначенные каждому сетевому сайту.

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

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

Пример топологии сети Litware Inc.

Примечание.

Все сетевые сайты связаны с сетевым регионом. Например, Портленд, Рено и Альбукерке включены в регион "Северная Америка". На этом рисунке представлены соединения WAN, к которым применяются политики CAC, с указанием ограничений полосы пропускании. Сетевые сайты Чикаго, Нью-Йорк и Детройт представлены внутри региона "Северная Америка", поскольку полоса пропускания для них не ограничена, а поэтому применение политик CAC не требуется.

Описание компонентов этой примерной топологии приведено в следующих разделах. Дополнительные сведения о планировании этой топологии, включая ограничения пропускной способности, см. в разделе Example : Gathering your requirements for call admission control in Lync Server 2013.

Определение сетевых регионов

Сетевой регион представляет собой сетевой концентратор или магистральную область.

Магистральная область или сетевой концентратор — это часть инфраструктуры компьютерной сети, которая соединяет различные части сети, предоставляя канал для обмена информацией между различными ЛВС или подсетями. Магистральная область может объединять разнообразные сети в широких географических масштабах. Емкости магистральной области обычно выше, чем емкостью сетей, подключенных к ней.

Пример топологии сети содержит три области: Северная Америка, EMEA (Европа, Ближний Восток и Африка) и APAC (Азиатско-Тихоокеанский регион). Сетевой регион содержит коллекцию сетевых сайтов (определение сетевых сайтов см. далее в этом разделе). Обратитесь к рабочей группе по работе с сетью, чтобы определить регионы сети.

Связь центрального сайта с каждым сетевым регионом

Cac требует, чтобы центральный сайт Lync Server был определен для каждого региона сети. Центральный сайт выбирается с учетом лучшего сетевого подключения и самой высокой пропускной способности для всех прочих сайтов в этом сетевом регионе. В предыдущем примере сетевой топологии демонстрирует три сетевых региона, каждый из которых имеет центральный сайт, обрабатывающий решения CAС. Соответствующее совмещение из предыдущего примера приведено в следующей таблице.

Примечание.

Центральные сайты не обязательно соответствуют сетевым сайтам. В примерах, приведенных в данной документации, некоторые центральные сайты — Чикаго, Лондон и Пекин — имеют те же имена, что и соответствующие сетевые сайты. Однако даже если центральный сайт и сетевой сайт используют одно и то же имя, центральный сайт является элементом топологии Lync Server, тогда как сетевой сайт является частью общей сети, в которой находится топология Lync Server.

Сетевые регионы, центральные сайты и сетевые сайты

Сетевой регион Центральный сайт Сетевые сайты

Северная Америка

Чикаго

Чикаго

Нью-Йорк

Детройт

Портленд

Рено

Альбукерке

Европа, Ближний Восток и Африка

Лондон

Лондон

Кельн

Азиатско-Тихоокеанский регион

Пекин

Пекин

Манила

Определение сетевых сайт

Сетевой сайт представляет собой место, в котором у организации имеется собственность, например офисы, здания или территории. Физический объект со связью через локальную или проводную сеть с другими сайтами считается сетевым сайтом. Начните с инвентаризации всех офисов организации. В нашем примере топологии сетевой регион "Северная Америка" состоит из следующих сетевых сайтов: Нью-Йорк, Чикаго, Детройт, Портленд, Рено и Альбукерке.

Необходимо связать каждый сетевой сайт с сетевым регионом. В зависимости от наличия или отсутствия у сетевого сайта ограниченной связи WAN сетевому сайту назначается политика пропускной способности. Подробнее о политиках CAC и полосе пропускания, выделяемой с их помощью, см. подраздел "Определение политик пропускной способности" далее в этом разделе. Чтобы настроить CAC, вы связываете сетевые узлы с регионами сети, а затем создаете политики выделения полосы пропускания для установления подключений с ограниченной полосой пропускания между данным сайтом или регионом и подключений WAN между сайтам и регионами.

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

Два региональных соединения — это соединение между Северной Америкой и регионом EMEA, которое обозначается как канал NA-EMEA-LINK, и соединение между регионами APAC и EMEA, которое обозначается как канал EMEA-APAC-LINK.

Соединения между сайтами обозначены как каналы, соединяющие Портленд, Рено и Альбукерке с регионом "Северная Америка", Манилу с регионом "APAC" и Кельн с регионом "EMEA". Соединение между Рено и Альбукерке представлено прямым сетевым каналом между этими двумя сайтами.

Определение политик пропускной способности

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

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

Политики полосы пропускания CAC могут определять любые из следующих характеристик (или все следующие характеристики).

  • Максимальная общая полоса пропускания, выделенная для аудио.

  • Максимальная общая полоса пропускания, выделенная для видео.

  • Максимальная полоса пропускания, выделенная для одного аудиовызова (сеанса).

  • Максимальная полоса пропускания, выделенная для одного видеовызова (сеанса).

Примечание.

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

Примечание.

Функции политики голосовой связи Lync Server 2013 предоставляют возможность переопределять проверки политики пропускной способности для входящих звонков пользователя (а не для исходящих вызовов, которые пользователь выполняет). После установления сеанса выполняется точный расчет использования полосы пропускания. Этот параметр следует использовать с осторожностью. Дополнительные сведения см. в статье о создании политики голосовой связи и настройке записей об использовании ТСОП в Lync Server 2013 или изменении политики голосовой связи и настройке записей об использовании ТСОП в Lync Server 2013 в документации по развертыванию.

Чтобы оптимизировать использование полосы пропускания для отдельных сеансов, примите во внимание тип аудио- и видеокодеков, которые будут использоваться. В частности, избегайте выделения недостаточной полосы пропускания для кодека, который предполагается использовать часто. Наоборот, если необходимо предотвратить использование кодека, для которого требуется выделение более широкой полосы пропускания, следует задать достаточно низкое значение максимальной полосы пропускания для отдельных сеансов, чтобы воспрепятствовать его использованию. Если речь идет об аудиокомпонентах, не все кодеки доступны для каждого сценария. Например:

  • Одноранговые аудиозвонки между конечными точками Lync будут использовать RTAudio (8 КГц) или RTAudio (16 кГц) при факторе пропускной способности и приоритетов кодеков.

  • Конференц-связи между конечными точками Lync и службой конференц-связи A/V будут использовать G.722 или Oren.

  • Вызовы к общедоступной телефонной сети (ТСОП) в конечные точки Lync или из них будут использовать G.711 или RTAudio (8 кГц).

Используйте приведенную ниже таблицу для подбора максимальных параметров полосы пропускания для отдельного сеанса.

Использование полосы пропускания — кодеки

Кодек Требования к полосе пропускания без метода прямой коррекции ошибок (FEC) Требования к полосе пропускания с методом прямой коррекции ошибок (FEC)

RTAudio (8 кГц)

49,8 кбит/с

61,6 кбит/с

RTAudio (16 кГц)

67 кбит/с

96 кбит/с

Siren

57,6 кбит/с

73,6 кбит/с

G.711

102 кбит/с

166 кбит/с

G.722

105,6 кбит/с

169,6 кбит/с

RTVideo (CIF, 15 кадров в секунду)

260 кбит/с

Неприменимо

RTVideo (VGA, 30 кадров в секунду)

610 кбит/с

Неприменимо

Примечание.

Требования к пропускной способности должны определяться с учетом следующих служебных данных: Ethernet II, IP, UDP, RTP и SRTP. Они также включают 10 кбит/с для RTCP.

Кодеки G.722.1 и Siren аналогичны, но они обеспечивают разную скорость потока.

Кодек по умолчанию для конференц-связи Lync Server в G.722 полностью отличается от кодеков G.722.1 и Lync Server.

Кодек Серен используется в Lync Server в следующих ситуациях:

  • Если для полосы пропускания установлено слишком низкое значение, которое не позволяет использовать G.722.

  • Если клиент Communications Server 2007 или Communications Server 2007 R2 подключается к службе конференц-связи Lync Server (так как эти клиенты не поддерживают кодек G.722).

Использование полосы пропускания в различных сценариях

Сценарий Требования к полосе пропускания, оптимизированные с учетом количества (кбит/с) Требования к полосе пропускания для сбалансированного режима (кбит/с) Требования к полосе пропускания, оптимизированные с учетом качества (кбит/с)

Одноранговые аудиовызовы

45 кбит/с

62 кбит/с

91 кбит/с

Конференц-вызовы

53 кбит/с

101 кбит/с

165 кбит/с

Вызовы ТСОП (между Lync 2013 и шлюзом ТСОП с обходом сервера-посредника)

97 кбит/с

97 кбит/с

161 кбит/с

Вызовы ТСОП (между Lync 2013 и сервером-посредником без обхода сервера-посредника)

45 кбит/с

97 кбит/с

161 кбит/с

Вызовы ТСОП (между сервером-посредником и шлюзом ТСОП без обхода сервера-посредника)

97 кбит/с

97 кбит/с

161 кбит/с

Lync — вызовы Polycom

101 Кбит/с

101 Кбит/с

101 Кбит/с

Определение IP-подсетей

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

В нашем примере сайту "Нью-Йорке" в регионе "Северная Америка" назначаются следующие IP-подсети: 172.29.80.0/23, 157.57.216.0/25, 172.29.91.0/23, 172.29.81.0/24. Предположим, Боб, который обычно работает в Детройте, отправляется в Нью-Йоркское отделение для прохождения обучения. Когда он включает свой компьютер и подключается к сети, его компьютер получает IP-адрес в одном из четырех регионов, которые зарезервированы для Нью-Йорка, например 172.29.80.103.

Предупреждение

IP-подсети, указанные во время настройки сети на сервере, должны соответствовать формату, предоставленному клиентскими компьютерами, чтобы гарантировать их надлежащее использование для обхода сервера-посредника. Клиент Lync принимает свой локальный IP-адрес и маскирует IP-адрес с помощью связанной маски подсети. При определении идентификатора обхода, связанного с каждым клиентом, регистратор сравнивает список IP-подсетей, связанных с каждым сетевым сайтом, с подсетью, предоставленной клиентом, для поиска точного совпадения. По этой причине крайне важно, чтобы подсети, введенные во время настройки сети на сервере, являлись действительным, а не виртуальными подсетями. (Если разворачивается контроль допуска звонков, а не обход сервера-посредника, то контроль допуска звонков будет работать должным образом даже при настройке виртуальных подсетей.)
Например, если клиент входит на компьютер с IP-адресом 172.29.81.57 с маской IP-подсети 255.255.255.0, Lync 2013 запросит идентификатор обхода, связанный с подсетью 172.29.81.0. Если подсеть определена как 172.29.0.0/16, то хотя клиент принадлежит к этой виртуальной подсети, регистратор не будет считать это соответствием, поскольку точно ищет подсеть 172.29.81.0. Поэтому важно, чтобы администратор вводит подсети точно так же, как это предоставлено клиентами Lync (которые подготавливаются с подсетями во время конфигурации сети статически или с помощью DHCP).)