Как подключить SIP-звонки к Microsoft Teams через Direct Routing — пошагово и без лишней воды

Как подключить SIP-звонки к Microsoft Teams через Direct Routing — пошагово и без лишней воды

Если ты уже используешь Microsoft Teams для внутренней связи, а теперь хочешь, чтобы сотрудники звонили на внешние номера — через SIP-провайдера, а не через лицензии Microsoft Calling Plan — тогда Direct Routing тебе нужен. Это не теория. Это то, что мы делали десятки раз для клиентов: от небольших компаний с 20 сотрудниками до корпораций с сотнями офисов. И да, это реально работает. Но только если всё настроить правильно.

Суть простая: ты подключаешь свой SIP-телефонный сервис (например, от Tele2, Sipnet, МегаФон или любого другого провайдера) напрямую к Teams, минуя Microsoft как посредника. Это дешевле, гибче и даёт полный контроль над номерами, маршрутами и качеством звонков. Но если сделать это наспех — звонки будут отваливаться, качество хромать, а поддержка Microsoft тебе не поможет.

Почему не использовать Calling Plan?

Microsoft предлагает Calling Plan — лицензию, которая включает в себя входящие/исходящие звонки через их инфраструктуру. Проблема в том, что:

• Цена — от 1200 рублей в месяц за пользователя (в России). Для 50 человек — это 60 000 рублей в месяц. Только за звонки.
• Ты теряешь контроль над номерами: не можешь перенести существующие номера, если они не входят в поддерживаемый диапазон.
• Нет гибкости: не можешь настроить сложные маршруты, IVR, резервирование каналов, интеграцию с CRM по своему сценарию.
• Зависишь от Microsoft: если у них сбой — звонки не работают. Никакого SLA с провайдером, только их условия.

Direct Routing — это когда ты сам выбираешь провайдера, сам настраиваешь маршруты, сам отвечаешь за качество. И платишь за трафик, а не за лицензию. Для большинства компаний это в 2–3 раза дешевле. И это не миф — это реальные цифры с наших проектов.

Что тебе нужно для настройки Direct Routing

Это не «включил и забыл». Это минимум три компонента, которые должны работать вместе:

1. SIP-провайдер — компания, которая даёт тебе внешние номера и каналы для звонков. Должен поддерживать SIP over TLS и SRTP. Проверь, есть ли у них опыт работы с Teams (не все провайдеры умеют).
2. SIP-шлюз — это устройство или программное решение, которое переводит SIP-трафик в формат, понятный Teams. Может быть физическим (например, Audiocodes Mediant) или программным (например, Ribbon SBC, Ribbon Cloud SBC, FortiGate с SIP-модулем).
3. Microsoft Teams с лицензией E3/E5 — без лицензии на Teams Phone System (или Phone System Virtual User) Direct Routing не заработает. Calling Plan не нужен, но Phone System — обязателен.

Важно: SIP-шлюз — это не опционально. Это обязательный мост. Teams не умеет общаться напрямую с SIP-провайдером. Он требует SBC (Session Border Controller) как промежуточное звено. Без него — ничего не сработает. Даже если провайдер говорит «мы поддерживаем Teams» — без SBC это пустой звук.

Как выбрать SIP-шлюз: три варианта

Тут выбор ограничен — и это хорошо. Слишком много вариантов только запутывают. Вот три реально рабочих варианта, которые мы проверили на практике:

Тип	Примеры	Плюсы	Минусы	Для кого
Физический SBC	Audiocodes Mediant, Ribbon SBC 5000	Высокая надёжность, поддержка QoS, детальная настройка, резервирование	Дорого (от 150 000 руб.), требует места, питания, обслуживания	Компании с 100+ пользователями, важные звонки, офисы с централизованным IT
Облачный SBC	Ribbon Cloud SBC, 8×8 SBC, Vonage SBC	Нет оборудования, масштабируется, быстрая настройка, поддержка провайдера	Зависимость от облака провайдера, цена за канал, может быть дороже при большом трафике	Компании с удалёнными сотрудниками, быстрый старт, нет IT-персонала на месте
Программный SBC на сервере	FortiGate с SIP-модулем, Cisco ISR с CUBE	Используешь уже имеющееся оборудование, экономия на покупке	Требует опыта настройки, может не поддерживать все функции Teams, сложная диагностика	Компании с сильным IT-отделом, уже использующие Fortinet/Cisco

Если у тебя меньше 50 пользователей и нет IT-специалиста на месте — выбирай облачный SBC. Если у тебя офис с серверной и 200+ сотрудников — физический SBC. Если ты уже используешь FortiGate — попробуй его как SBC. Но не делай это «на глазок» — тестируй с реальным провайдером.

Как настроить: пошагово

Это не 5 минут. Это 1–2 недели, если всё делать правильно. Вот как мы это делаем:

1. Выбери SIP-провайдера. Убедись, что он поддерживает Teams и имеет сертификат от Microsoft. Попроси у них пример конфигурации. Если не могут дать — ищи другого.
2. Настрой SBC. Подключи его к сети, дай ему публичный IP (или настрой NAT с пробросом портов 5061/TLS и 50000–50019/UDP). Загрузи сертификат от Microsoft (он нужен для аутентификации с Teams).
3. Настрой SBC для Teams. Введи данные от Microsoft: FQDN (sbc.yourdomain.com), порты, протоколы. Убедись, что TLS 1.2 включён, SRTP — включён, кодеки G.711 и OPUS — разрешены.
4. Подключи SBC к Teams. В админ-центре Teams перейди в Voice > Direct Routing. Добавь SBC по FQDN. Проверь статус — он должен быть «Connected».
5. Назначь номера пользователям. В PowerShell (или через админ-центр) привяжи SIP-номер к пользователю: Set-CsUser -Identity "ivan@company.ru" -EnterpriseVoiceEnabled true -HostedVoiceMailtrue -OnPremLineURI "tel:+74951234567".
6. Проверь звонок. Позвони с Teams на мобильный. Проверь, что звонок идёт через твой SIP-провайдер (в логах SBC). Проверь качество: нет задержек, нет обрывов, нет эха.

Если на шаге 6 звонок не идёт — 90% проблем в: неправильном FQDN, неправильном сертификате, закрытых портах на фаерволе или несовместимом кодеке. Не трать время на перезагрузку Teams — смотри логи SBC.

Частые ошибки — и как их избежать

• Ошибка 1: «Мы купили SBC, всё должно работать». Нет. SBC — это только мост. Если провайдер не поддерживает SRTP или использует SIP over UDP без шифрования — Teams откажется подключаться. Проверь требования Microsoft до покупки.
• Ошибка 2: «У нас уже есть шлюз от Cisco, просто подключим». Cisco CUBE — отличное устройство, но для Teams нужна специфическая конфигурация. Без правильного профиля SIP и TLS — он не поймёт Teams. Не полагайся на «обычную» настройку.
• Ошибка 3: «Мы хотим использовать 2 провайдера для резервирования». Можно, но не на первом этапе. Начни с одного. Если звонки падают — сначала разбери причину. Два провайдера = вдвое больше точек отказа и сложности диагностики.
• Ошибка 4: «Мы не стали тестировать». Никогда не запускай Direct Routing без тестового периода. Подключи 2–3 пользователя, дай им звонить 3–5 дней. Запиши, где падают звонки, какое качество, есть ли эхо. Без теста — ты запустишь катастрофу на всех.
• Ошибка 5: «Мы не поняли, что нужен Phone System». Лицензия E3 — не значит, что звонки работают. Тебе нужна лицензия Phone System (входит в E5, или отдельно в E3). Без неё — даже если всё настроено, звонки не пойдут.

Что выбрать в зависимости от ситуации

• Ситуация 1: У тебя 15 сотрудников, все работают удалённо, бюджет ограничен. → Выбирай облачный SBC (Ribbon Cloud SBC) + SIP-провайдер с поддержкой Teams. Срок настройки — 3–5 дней. Стоимость — около 500–700 руб. за пользователя в месяц (включая трафик).
• Ситуация 2: У тебя офис в Москве, 120 сотрудников, есть IT-отдел, хочешь полный контроль. → Физический SBC (Audiocodes) + провайдер с SLA 99.9%. Срок настройки — 1–2 недели. Стоимость — 300–400 руб. за пользователя в месяц (только трафик).
• Ситуация 3: У тебя уже есть FortiGate 60F, ты хочешь сэкономить. → Попробуй настроить SIP-модуль на FortiGate. Тестируй с 5 пользователями. Если стабильно — запускай. Если падает — переходи на специализированный SBC. Не рискуй основной инфраструктурой.
• Ситуация 4: Ты перехожишь с АТС на Teams и хочешь сохранить старые номера. → Убедись, что SIP-провайдер позволяет переносить номера. Процесс занимает 7–14 дней. Начни за 3 недели до отключения старой АТС.

Как лучше сделать — практические рекомендации

• Не покупай SBC без теста. Попроси провайдера или дистрибьютора дать демонстрацию с твоим провайдером.
• Используй только сертифицированные SBC от Microsoft. Список — на сайте Microsoft. Не трать время на «совместимые» устройства без сертификации.
• Сертификаты — это не «для галочки». Без правильного TLS-сертификата (от доверенного центра, с правильным FQDN) Teams не подключится. Убедись, что он не просрочен.
• Настрой Quality of Service (QoS) на маршрутизаторе: выдели приоритет для трафика SIP (DSCP 46) и медиа (DSCP 40). Без этого звонки будут прерываться даже при хорошем интернете.
• Запусти мониторинг: используй Teams Call Quality Dashboard. Там ты увидишь, где теряются пакеты, какая задержка, есть ли эхо. Это твой главный инструмент диагностики.
• Обучи пользователей: если они звонят через Teams, им нужно понимать, что микрофон/наушники — это не «всё равно». Плохой микрофон = плохое качество звонка для собеседника. Дай им рекомендации по оборудованию.

Итог: что делать прямо сейчас

Если ты читаешь это — ты уже понимаешь, что Calling Plan дорог и не гибок. Ты хочешь перейти на Direct Routing. Вот что делать:

1. Проверь, есть ли у твоих сотрудников лицензия Teams Phone System. Если нет — купи её. Без этого ничего не сработает.
2. Выбери SIP-провайдера, который подтверждает поддержку Teams и Direct Routing. Попроси у них документацию и пример конфигурации.
3. Выбери SBC: облачный — если ты хочешь быстро и просто; физический — если у тебя офис и IT-команда.
4. Запусти тест на 3–5 пользователях. Дай им 5 дней. Запиши: звонки идут? Качество? Есть ли задержки?
5. Если тест прошёл — запускай на всех. Если нет — ищи причину в SBC или провайдере. Не тяни с этим.

Direct Routing — это не «магия». Это инженерная задача. Её можно решить. Но только если не пытаться обойти шаги. Не пытайся сэкономить на SBC. Не пытайся настроить всё за день. Не полагайся на «наверное, сработает».

Когда всё сделано правильно — ты получаешь систему, которая работает дешевле, надёжнее и гибче, чем Calling Plan. Ты управляешь номерами, качеством, маршрутами. И никто не сможет сказать тебе, что «у Microsoft сбой» — потому что ты сам выбрал, где и как работают твои звонки.

Информация в статье носит ознакомительный характер. Настройка Direct Routing требует технических знаний и может повлиять на работу телефонной системы компании. Перед изменениями проконсультируйтесь с ИТ-специалистом или провайдером.