Одним из нововведений Lync Server 2010 стало появление стандартного для IP-АТС механизма ограничения вызовов по WAN-каналам (Call Addition Control, CAL). Подробно об этой технологии уже писал Николай Муравлянников в статье «Новые возможности Microsoft Lync Server 2010 (Часть 1). Контроль допуска звонков в Lync Server 2010 (Call Admission Control)» Данная статья посвящена в основном расчету пропускной способности для работы CAC. Также мы затронем расчет трафика в канале, но тут уже всё будет гораздо проще. Механизм CAC, реализованный Microsoft, существенно отличается от общепринятого. У администраторов нет прямого контроля над списком доступных аудио/видео-кодеков и количеством вызов. Можно лишь задать максимальную используемую Lync под голос (Audio Limit) и видео (Video Limit) полосу пропускания и максимальную полосу пропускания одной сессии (Audio Session Limit и Video Session Limit соответственно).
Параметры кодеков
Каждый аудио/видео-кодек имеет ряд параметров. Адаптивные кодеки могут эти параметры менять на лету.
Время пакетизации: 20, 40, 60 мс. Чем больше время разговора, передаваемое за один раз, тем больше задержка в передаче, но тем меньше накладные расходы на передачу (меньше суммарный объем различных заголовков)
Частота дискретизации: Narrowband (8 КГц), Wideband (16 КГц), Ultra-Wideband (32 КГц). Не буду вдаваться в подробности (вспоминаем теорему Котельникова из курса физики), но чем больше частота дискретизации, тем естественнее голос. Но и информации при этом передается значительно больше.
Коррекция ошибок (Forward Error Correction, FEC): ВКЛ, ВЫКЛ :-). Избыточность данных, помогающая восстановить данные при искажении / потери части пакетов в канале.
В хорошем канале адаптивный кодек включит минимальное время пакетизации, выставит максимальную частоту дискретизации и отключит коррекцию ошибок.
При наличии потерь пакетов будет включен FEC, а на загруженных каналах будет уменьшена частота дискретизации и увеличено время пакетизации.
Время пакетизации увеличивается в последнюю очередь. В официальной документации MS даже нет информации о полосе пропускания кодеков при значениях 40 и 60 мс. Дело в том, что задержка от времени пакетизации складывается с другими и, в конце концов, может превысить допустимые для нашего мозга 300 мс. RTT (туда обратно). При этом ответ собеседника придёт позже, чем мы ожидаем, и мы непроизвольно уточним, слышат ли нас с другой стороны. В результате, мы перебьём начавшего было говорить человека :-). Секунд 5 будет потрачено на «АЛЛО АЛЛО». Затем начнется общение, но с внутренним дискомфортом (мозг от таких асинхронных коммуникаций входит в ступор). Думаю, с таким все сталкивались при звонках на дальние расстояния.
Кодеки Lync
Кодекам, используемым в Lync, неплохо бы посвятить отдельную статью с описанием, как самих кодеков, так и причин их выбора в MS.
Пока лишь уточню, что кодеки RTAudio и RTVideo были несколько лет назад куплены MS и теперь постоянно дорабатываются, а кодеки Siren и G.722 лицензированы у компании Polycom.
Еще замечу, что RTAudio позиционируется MS как супер-адаптивный кодек. Но пока у него есть два ограничения: не предназначен для конференций и имеет не самые низкие требования к каналам (там где тот-же Skype работает стабильно, RTAudio может начать проседать).
Теперь пора привести таблицы из документации к Lync Server 2010 по кодекам продукта, которые предлагается использовать для планирования каналов.
Таблица планировании аудио / видео сессий точка-точка
| Тип медиа трафика | кодек | Средняя занимаемая полоса пропускания (Кбит/с) | Максимальная занимаемая полоса пропускания без FEC | Максимальная занимаемая полоса пропускания с FEC |
| Audio | RTAudio Wideband | 39.8 | 62 | 91 |
| Audio | RTAudio Narrowband | 29.3 | 44.8 | 56.6 |
| Main video CIF | RTVideo | 220 | 260 | нет |
| Main video VGA | RTVideo | 508 | 610 | нет |
| Main video HD | RTVideo | 1210 | 1510 | нет |
| Panoramic video | RTVideo | 269 | 360 | нет |
Таблица планировании аудио / видео конференций
| Тип медиа трафика | кодек | Средняя занимаемая полоса пропускания (Кбит/с) | Максимальная занимаемая полоса пропускания без FEC | Максимальная занимаемая полоса пропускания с FEC |
| Audio | G.722 | 46.1 | 100.6 | 164.6 |
| Audio | Siren | 25.5 | 52.6 | 68.6 |
| Main video CIF | RTVideo | 220 | 260 | нет |
| Main video VGA | RTVideo | 508 | 610 | нет |
| Panoramic video | RTVideo | 269 | 360 | нет |
Таблица планирования вызовов в город
| Тип медиа трафика | кодек | Средняя занимаемая полоса пропускания (Кбит/с) | Максимальная занимаемая полоса пропускания без FEC | Максимальная занимаемая полоса пропускания с FEC |
| Audio | G.711 | 64.8 | 97 | 161 |
| Audio | RTAudio Narrowband | 30.7 | 44.8 | 56.6 |
А теперь несколько советов и немного малоизвестной информации
Собственно, ради чего данная статья и затевалась. Надеюсь, информация в данном разделе будет для вас полезна.
Microsoft рекомендует не выставлять Session Limit для аудио вызовов. Поскольку количество вызовов можно спрогнозировать, а требуемую полосу пропускания вычислить – рекомендуется заранее планировать и закупать каналы с необходимой полосой пропускания. Сразу предвижу контраргументы, думаю в России их видят все, так что пожалуйста, опустим в комментариях разговоры про дураков и дороги и про бизнес, IT и деньги :-). Качество VS затраты. Так было всегда.
Как вы видите на таблицах выше, для конференций и для вызовов «точка-точка» используются разные аудиокодеки. Это нужно учитывать при задании ограничений. Если, например, указать Audio Session Limit, равный 44,8, – этого хватит для вызовов «точка-точка», но конференции если и будут идти, то с повышенным временем пакетизации, что может вызвать негативную реакцию пользователей.
Если уж указывать ограничение для голоса, то коллеги из MS рекомендуют выставить Audio Session Limit в районе 65. В этом случае мы получим кодек хорошего качества RTAudio Wideband на стабильных каналах, а в случае проблем, автоматически переключимся на кодек приемлемого качества RTAudio Narrowband, но с коррекцией ошибок. Конференции тоже продолжат работать, но с небольшими задержками.
Audio Session Limit и Audio Limit ограничивают не только лимит аудиовызова, но и лимит аудиочасти в видеовызовах. Не совсем понятно из документации.
Поэтому, если вы выставили альтернативный маршрут для голоса, то голос в рамках одной сессии может идти одним маршрутом, а видео – другим.
Для расчёта, стоит ли пускать еще один голосовой вызов, Lync Server вычитает суммарную максимальную пропускную способность всех текущих вызовов в канале из Audio Limit, вычитает из полученного значения Audio Session Limit и если результат положительный – пропускает вызов. То же и с видео-вызовами.
Поясню на примере:
Допустим, мы выставили Audio Limit в 1024 Кбит/с, a Audio Session Limit в 100 Кбит/с. В текущий момент в канале идет 14 вызовов RTAudio Wideband без FEC (62 Кбит/с). Вызов делает 15-й пользователь. Lync Server делает расчет “(1024 – 62*14) – 100”, получает положительное число 56 и пропускает вызов.
Зная описанное выше, думаю, вы сможете рассчитать требования к полосе пропускания для своей инфраструктуры, и, если необходимо, принять меры по оптимизации медиа-трафика Lync по каналам.
Расчет трафика.
Теперь, когда мы приблизительно знаем параметры наших вызовов, мы можем подсчитать предполагаемый объем трафика в канале за день/неделю/месяц. Для этого нам потребуется дополнительная информация, которую обычно не так сложно получить, а именно время в секундах, которое в среднем тратят сотрудники на телефонные переговоры между площадками за отчетный период. Данные можно получить от оператора телефонии (придётся обработать) либо собрать с вашей уже существующей АТС, если ведется отчетность.
Зная суммарное время, умножаем его на значение из столбца «Средняя занимаемая полоса пропускания» таблиц выше для выбранного кодека.
При переходе на IP-телефонию реальные значения будут несколько выше по понятным причинам, но приблизительное представление о предстоящих расходах, если у вас не безлимит, вы получите.
Александр Донин
Поправьте Call Addition…