Какая пропускная способность нужна для VoIP?

Рассчитайте необходимую пропускную способность VoIP по числу одновременных голосовых потоков, используемому кодеку и служебному сетевому трафику. Количество сотрудников или телефонных номеров не заменяет эти данные. Проверьте исходящий и входящий каналы отдельно, затем учтите трафик других приложений и запас пропускной способности.

Представленный ниже расчет выполняется на уровне IP-сети. Он показывает, откуда берется пропускная способность и помогает сравнить предположения. Это не полное руководство по выбору интернет-плана. Фактические требования зависят от телефонной системы, маршрута, безопасности и других приложений.

Соберите данные перед расчетом

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

Просмотрите журнал телефонных звонков и определите максимальное количество одновременных разговоров. Не делите общее количество минут телефонных звонков в день на рабочее время. Среднее использование скрывает пиковое время. Для нового офиса, согласуйте ожидаемый сценарий с руководителями команды и подтвердите его после запуска.

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

Определите кодек и интервал пакетной передачи

Кодек определяет, как представляется звук, и его битрейт. Пакет содержит не только голос: к нему добавляются заголовки. Также определите интервал пакетной передачи, который часто называют ptime. Он указывает, сколько миллисекунд звука содержится в каждом пакете.

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

Выберите границу измерения

Один и тот же вызов может давать разные результаты при подсчете объема данных голоса, IP-пакетов или передачи по физической связи. Всегда указывайте, что входит в результат. В примере ниже подсчитывается один поток RTP по UDP и IPv4 без дополнительных расширений.

Базовый заголовок IPv4 занимает 20 байт, UDP – 8 байт, а базовый заголовок RTP – 12 байт. Вместе это составляет 40 байт на пакет. Источники, расширения RTP, IP-опции, шифрование и туннели могут добавлять больше данных. Эти 40 байт не являются универсальным общим накладным издержками для всех телефонных систем.

Формула для одного потока голоса

При постоянном битрейте используйте три шага. Объем данных в пакете, байты = битрейт кодека, бит/с × интервал пакетной передачи, с / 8. Количество пакетов в секунду = 1 / интервал пакетной передачи, с. Пропускная способность на поток, бит/с = размер пакета, включая подсчитанные заголовки, × 8 × количество пакетов в секунду.

Пример G.711 с пакетами размером 20 мс

Предположим, что G.711 работает на 64 000 бит/с с интервалом 20 мс, или 0,02 с. Объем данных: 64 000 × 0,02 / 8 = 160 байт. Скорость передачи: 1 / 0,02 = 50 пакетов в секунду. При 40 байтах заголовков, каждый пакет составляет 200 байт.

Использование пропускной способности: 200 × 8 × 50 = 80 000 бит/с, или 80 кбит/с в одном направлении. Обычный разговор с такими же параметрами второго потока требует 80 кбит/с в исходящем и 80 кбит/с во входящем направлении. Суммарно два потока используют 160 кбит/с, но это не означает, что в каждом направлении требуется по 160 кбит/с.

Здесь, «kbps» и «Mbps» используют десятичные множители: 1 kbps соответствует 1000 битам/с, а 1 Mbps соответствует 1 000 000 битам/с. Не путайте биты с байтами или не заменяйте 64 000 на 65 536.

Как кодирование и пакетная передача влияют на расчет

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

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

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

Три сценария одновременных вызовов

Во всех трех сценариях используется G.711 при 64 кбит/с, пакетах длиной 20 мс и заголовках IPv4, UDP и RTP, занимающих в общей сложности 40 байт. Каждый разговор создает один исходящий и один входящий поток через указанное соединение. Подавление тишины исключено. Каждый поток использует 80 кбит/с.

Это пропускная способность для голосовой связи на выбранном уровне, а не достаточная скорость подключения для офиса. В таблице исключается управляющий трафик RTCP, сигнализация вызовов, дополнительная информация о безопасности, уровень канала и другой трафик. Не добавляйте базовые 40 байт снова. Они уже включены в 80 кбит/с.

Вы можете увидеть 87,2 кбит/с для того же примера G.711. Метод Cisco дает эту цифру путем добавления 18 байт Ethernet на пакет. Он все еще не учитывает все физические затраты на передачу. Сравнивайте цифры только после согласования границы измерения и включенных затрат.

Учтите другие приложения и рабочий запас пропускной способности

Проверьте исходящий и входящий каналы отдельно

При асимметричном подключении исходящий канал может достичь предела раньше входящего. Отправка файлов в облако конкурирует с исходящим голосовым трафиком, а скачивание обновлений — с входящим. Удалённый сотрудник также использует домашнюю сеть. Хорошие результаты в офисе не подтверждают качество его домашнего подключения.

Для каждого направления сложите рассчитанную потребность голосовых потоков, ранее неучтённый служебный трафик телефонии и ожидаемый одновременный трафик других приложений. Затем добавьте рабочий запас пропускной способности. Его размер зависит от колебаний трафика, возможностей управления очередями и требований к сервису. Универсальный процент без этих исходных данных не подтверждает достаточность канала.

Измерьте доступную пропускную способность в рабочее время

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

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

Оцените, сколько разговоров поддерживает доступная пропускная способность.

Обратный расчёт возможен, когда для голосовых потоков выделена определённая пропускная способность с учётом прочего служебного трафика и необходимого запаса. Разделите её на пропускную способность одного потока в соответствующем направлении. Рассчитайте ограничения исходящего и входящего каналов отдельно, округлите оба результата вниз и выберите меньшее значение. Единицы измерения и границы учёта трафика должны совпадать.

Например, предположим, что на уровне IP доступно 1000 кбит/с в исходящем и 800 кбит/с во входящем направлении, а каждому потоку требуется 80 кбит/с. Округление вниз даёт соответственно 12 и 10 разговоров. Ограничение в этом расчёте — 10 разговоров. Это не рекомендация по выбору интернет-тарифа: фактическое подключение должно также обеспечивать весь неучтённый служебный трафик и выполнять требования к качеству.

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

Пропускная способность не заменяет тестирование качества.

Измерьте задержку, джиттер и потерю пакетов.

Задержка влияет на паузы и перебивание разговоров. Джиттер описывает изменение задержки доставки пакетов. Потеря пакетов может вызывать прерывания в аудио. Даже быстрое соединение может обеспечить плохое качество звука, если путь нестабилен или очередь перегружено.

Стандартный тест скорости помогает в первоначальной оценке, но не подтверждает качество каждого звонка. Проверьте путь к фактической платформе, статистику потоков мультимедиа и качество звука при высокой нагрузке. Время отклика (ping) не равно задержке звонка в одном направлении. Согласуйте целевые значения и методы оценки с провайдером выбранной системы.

Буфер для сглаживания обеспечивает равномерный приём пакетов, но за счёт этого увеличивается задержка. Сам буфер не восстанавливает потерянные пакеты и не увеличивает пропускную способность соединения. Он может работать в телефоне, приложении или другом компоненте системы.

Учитывайте ограничения QoS и локальную сеть

QoS может отдавать приоритет трафику, чувствительному к задержке, при условии поддержки соответствующими правилами оборудования. Он использует существующую пропускную способность, а не создает её. Приоритет на офисном маршрутизаторе не гарантирует одинаковое обращение по всему общедоступному интернету.

Отдельная VLAN помогает разделить трафик телефонии, но не устанавливает для него приоритет. Для установки приоритета требуются правила QoS и поддержка оборудования. Убедитесь, что правила применяются к необходимым участкам пути.

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

Если звук работает только в одном направлении, проверьте путь передачи данных, правила брандмауэра и перевод адресов с провайдером. Не отключайте безопасность или не создавайте произвольный обход, просто чтобы протестировать звук. Другой тарифный план не исправит ошибку маршрутизации или разрешения.

Проверьте расчёт с помощью активных звонков

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

Что необходимо подготовить для оценки сети

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

Если вам необходимо оценить сеть и телефонию, обсудите услуги сети и телекоммуникаций от DKs. Предоставьте параметры вызовов и наблюдаемые проблемы для определения объема проверки подключения и оборудования.

Источники

• Базовый заголовок RTP и расширения в RFC 3550
• Метод Cisco для расчета пропускной способности кодека и накладных расходов
• Работа буфера задержки в RFC 7005
• Документация Microsoft о назначении и настройке QoS