Лучшие практики настройки VoIP-шлюза Yealink T4

Миф о «заводских» настройках: почему доверять умолчаниям нельзя

Самая дорогая ошибка, которую я вижу у коллег, — уверенность, что шлюз Yealink T4 работает «из коробки» корректно в любой инфраструктуре. На практике это не так. Сразу после первого подключения опытный специалист меняет три критичных параметра — и это не касается IP-адресации. Во-первых, уровень громкости линии FXO по умолчанию часто выставлен на 0 дБ, что в российских телефонных линиях с их затуханием даёт тишину на том конце. Обязательно поднимите его до +3–6 дБ в веб-интерфейсе — в разделе «Телефония → Аналоговые параметры». Во-вторых, сбросьте настройки DTMF: стандартный сигнал «In-band» может не распознаваться современными IP-АТС. Переключите на RFC2833 с payload 101 — это уберёт проблему неработающих добавочных номеров при IVR.

Подводные камни NAT и STUN, о которых молчат мануалы

Главная ловушка при размещении T4 за NAT — неочевидное поведение SIP-счётчика. Большинство ставят галочку «Поддержка NAT» и забывают. Но если ваш офисный роутер использует симметричный NAT, ни STUN, ни ALG не спасут. Я настоятельно рекомендую проверить модель NAT в своей сети заранее — через утилиту stun-client с консоли сервера Asterisk. Если NAT симметричный, единственный рабочий метод — пробросить порты для RTP вручную (обычно диапазон портов 10000–20000) на IP вашего T4. И ещё один неочевидный нюанс: веб-интерфейс T4 при включённом STUN может показывать корректный статус регистрации, но пакеты всё равно не доходят. Проверяйте принудительным звонком с захватом трафика через tcpdump.

Кодеки: тихая деградация качества, которую никто не замечает

Профессиональная настройка — это не просто выбор G.711 или G.729. Ошибка в приоритете кодеков в T4 может привести к тому, что звонок пойдёт через G.723 с потерей качества в 30%, хотя все абоненты поддерживают G.711. Хитрость в том, что шлюз запоминает список кодеков по порядку, и если убрать G.729 из начала — при звенящем перегрузе канала звонок упадёт. Мой совет: ставьте первым G.711a (до 256 кбит/с), вторым G.729 (8 кбит/с), третьим G.722 — для совместимости с мобильными клиентами. Никогда не включайте G.723 — он использует фреймы по 30 мс, создавая недопустимую задержку в реальном разговоре. И обязательно отключите все кодеки с patent-роялти, если вы работаете на голом Asterisk — это сэкономит процессорные ресурсы.

Прошивки: как не потерять часы на отладке

Самая распространённая история — когда интегратор ставит свежую прошивку Yealink «для порядка» и ломает совместимость с конкретной версией Asterisk. Лично я всегда проверяю версию прошивки T4 на сайте Yealink: для T41S/T42S/T43U есть «длинные» релизы с фиксами для старых ядер PBX. Особенно критично — версия 84.0.0.115 для T43U: она патчит ошибку с неверной обработкой SIP-заголовка «P-Asserted-Identity», но если ваша АТС не поддерживает это поле — звонок просто не пройдёт. Лучше использовать стабильный релиз 83.0.0.50 для всех моделей T4, если только вам не нужны конкретные баг-фиксы. Не доверяйте автоматическому обновлению — делайте только ручную загрузку через веб-интерфейс.

DTMF и факс: два неочевидных сценария провала

Когда клиент жалуется, что после настройки T4 перестал работать факс — причина почти всегда в настройке DTMF-метода. Шлюз по умолчанию отправляет DTMF как «SIP INFO» — это нормально для голоса, но убивает факсимильный трафик. Для T4 нужен специальный профиль: в разделе «Голос → Факс» установите T.38 с обязательным «Режим ретрансляции» = «Да» (он отключён по умолчанию!). И ещё один трюк: если факс всё равно не проходит — выставьте задержку отбоя линии (line timeout) до 1500 мс. Это компенсирует медленные реле в старых офисных мини-АТС. А для обычных DTMF-команд (IVR-меню) никогда не используйте «In-band» — только RFC2833.

Добавлено: 24.04.2026