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

Односторонний звук означает, что звонок установлен, но только одна сторона слышит другую. SIP-сигнализация может выглядеть нормальной, телефон может звонить, и вызов может быть успешно принят, но голосовой поток не проходит правильно в обоих направлениях. Эта проблема обычно связана с NAT, передачей RTP, политиками брандмауэра, SIP ALG, согласованием кодеков, конфигурацией конечной точки или настройками медиа на сервере.

Начните с различия между сигнализацией и медиа

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

Во многих случаях часть SIP успешна, потому что сеть разрешает стандартный SIP-порт, часто UDP или TCP 5060. Телефон может нормально регистрироваться, набирать номер и отвечать на звонки. Но порты RTP, используемые для голоса, отличаются от порта сигнализации SIP. Если RTP-путь заблокирован, неправильно маршрутизирован, неверно транслируется или отправляется на неправильный IP-адрес, вызов может установиться без нормальной двусторонней голосовой связи.

Поэтому устранение неполадок не должно останавливаться на статусе регистрации SIP. Телефон, успешно зарегистрированный, все еще может иметь проблемы с медиа. Инженеры должны проверить, могут ли обе стороны отправлять и получать RTP-пакеты во время вызова.

NAT является распространенным источником проблем с направлением звука

NAT позволяет устройствам внутри локальной сети получать доступ к внешним сетям через публичный IP-адрес. Это часто встречается в офисах предприятий, филиалах, отелях, на заводах и в удаленных местах. Когда IP-телефон или SIP-сервер находится за NAT, устройство может объявлять частный IP-адрес в информации SIP или SDP. Затем удаленная сторона может попытаться отправить RTP-пакеты на недоступный частный адрес.

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

Чтобы решить эту проблему, развертывание должно использовать правильный дизайн обхода NAT. Общие методы включают STUN, TURN, симметричный RTP, отображение публичных адресов, перенаправление портов, развертывание SBC или ретрансляцию медиа через SIP-сервер. Лучший выбор зависит от топологии сети и от того, развернута ли система внутри частной сети, через публичные сети или между несколькими филиалами.

Правила брандмауэра должны включать трафик RTP

Политика брандмауэра — еще одна частая причина одностороннего звука. Многие администраторы открывают только порт сигнализации SIP и забывают о диапазоне портов RTP. В результате телефоны могут регистрироваться, и звонки могут создаваться, но голосовые пакеты не могут пройти через брандмауэр.

RTP обычно использует UDP-порты. Диапазон портов зависит от конфигурации телефона, PBX, SIP-сервера, SBC или медиаплатформы. Во многих средах SIP RTP может использовать такие диапазоны, как UDP 16384-32768, или другой пользовательский диапазон, определенный системным администратором. Точный диапазон следует проверить как в конфигурации телефона, так и в конфигурации сервера.

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

Маршрутизации RTP нужен четкий медиапуть

Голос IP-телефона передается потоками RTP. Если адрес назначения RTP, адрес источника, порт или путь маршрутизации неверны, аудио может работать только в одном направлении. Это может произойти не только в сценариях с публичной сетью, но и внутри частной LAN.

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

Во время развертывания проектная группа должна подтвердить, является ли голосовой путь «конечная точка-конечная точка», «конечная точка-сервер» или «конечная точка-SBC». Все устройства в потоке вызова должны использовать достижимые IP-адреса и совместимые настройки портов RTP.

SIP ALG может помочь или нарушить звонок

Многие маршрутизаторы и брандмауэры включают функцию SIP ALG. Она предназначена для проверки и изменения SIP-пакетов, чтобы SIP-трафик мог легче проходить через NAT. Теоретически это звучит полезно. На практике SIP ALG иногда может неправильно изменять информацию SIP или SDP и вызывать односторонний звук, сбои вызовов или нестабильную регистрацию.

Если сеть уже использует правильный SBC, отображение публичных адресов, STUN или механизм ретрансляции медиа, SIP ALG может стать ненужным или даже вредным. Во многих случаях устранения неполадок отключение SIP ALG на маршрутизаторах или брандмауэрах может решить проблемы с односторонним звуком.

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

Согласование кодеков должно быть согласованным

IP-телефоны обычно поддерживают несколько голосовых кодеков, таких как G.711, G.729, G.722 и другие аудиоформаты. Эти кодеки выбираются во время SIP-согласования. Если две стороны не имеют совместимого кодека, вызов может не иметь звука, иметь искаженный звук или нестабильное медиа-поведение.

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

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

Конфигурацию на стороне телефона нельзя игнорировать

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

Когда проблема возникает только на одном или нескольких телефонах, полезно сравнение конечных точек. Инженеры могут сравнить работающий телефон с проблемным и проверить настройки учетной записи SIP, сетевой адрес, диапазон портов RTP, список кодеков, режим обхода NAT, версию прошивки и состояние аудиоустройства.

Этот метод часто быстрее, чем немедленное изменение глобальных настроек сервера. Если проблема ограничена одной конечной точкой, основная причина обычно находится ближе к этой конечной точке или ее локальной сети.

Настройки сервера и медиа-прокси влияют на все вызовы

Конфигурация SIP-сервера также может вызывать односторонний звук. Адрес медиа-сервера, режим RTP-прокси, внешний IP-адрес, внутренний IP-адрес, диапазон портов, политика прямых медиа, обработка NAT и настройки ретрансляции — все это может повлиять на путь RTP.

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

Когда проблема сложна, полезны захват пакетов и журналы сервера. Проверяя информацию SIP/SDP и поток RTP-пакетов, инженеры могут увидеть, какой IP-адрес и порт объявляются, куда отправляется RTP-поток и получает ли его другая сторона.

Мультисетевые интерфейсы могут отправлять медиа не туда

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

Это может создать ситуацию, когда сигнализация выглядит нормальной, но звук не может вернуться правильно. Устройство может объявлять неправильный IP-адрес в SDP или отправлять RTP-пакеты с неожиданного сетевого интерфейса.

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

Практический рабочий процесс устранения неполадок

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

После этого сосредоточьтесь на RTP. Проверьте политики брандмауэра, диапазоны портов RTP, настройки обхода NAT, статус SIP ALG, согласование кодеков, режим ретрансляции медиа и настройки внешнего IP-адреса сервера. Если проблема остается неясной, используйте захват пакетов, чтобы подтвердить, отправляются ли RTP-пакеты и принимаются ли в обоих направлениях.

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

Планирование стабильного двустороннего звука

Лучшее решение — снизить вероятность одностороннего звука на этапе проектирования. Для небольших развертываний в LAN сохраняйте сеть простой и убедитесь, что телефоны, PBX и шлюзы используют согласованные настройки RTP. Для мультисайтовых развертываний планируйте обход NAT, правила брандмауэра, маршрутизацию VPN и размещение SBC до установки телефонов.

Для развертываний в публичной сети или облачной PBX обычно лучше использовать ретранслятор медиа или SBC для управления путем RTP. Это позволяет избежать многих проблем, связанных с NAT, и улучшает совместимость между различными сетевыми средами.

Документация также важна. Порт SIP, диапазон портов RTP, политика кодеков, метод NAT, IP-адрес сервера, настройки медиа-прокси и правила брандмауэра должны быть записаны для будущего обслуживания.

Заключение

Односторонний звук в IP-телефонных системах обычно не вызывается одной фиксированной проблемой. Он может возникать из-за трансляции NAT, заблокированных портов RTP, неправильной политики брандмауэра, вмешательства SIP ALG, несоответствия кодеков, конфигурации конечной точки, настроек медиа на сервере или маршрутизации мультисетевых интерфейсов.

Хорошее решение начинается с понимания разницы между сигнализацией SIP и медиа RTP. Регистрация и набор номера могут работать нормально, в то время как передача голоса не удается. Пошагово проверяя медиапуть, проектные группы могут быстрее найти проблему и построить более стабильную систему IP-голосовой связи.