При обслуживании взрывозащищённого SIP-телефона ответ 200 OK на транзакцию REGISTER подтверждает только то, что терминал успешно создал аутентифицированную привязку адреса к серверу регистрации. Это не гарантирует, что INVITE будет правильно маршрутизирован, SDP согласует совместимый кодек, а RTP-медиа будут проходить в обоих направлениях между взрывозащищённым телефоном и удалённой стороной. Иными словами, состояние «Зарегистрирован» описывает лишь часть достижимости плоскости управления SIP, а не полную возможность сквозного телефонного соединения.
Поэтому взрывозащищённый телефон может отображаться как успешно зарегистрированный, но при этом не звонить, соединяться без звука, передавать речь только в одном направлении или разрывать соединение сразу после ответа. Во многих случаях сервер регистрации не является реальным источником неисправности. Проблема находится в сигнальном тракте, медиатракте или локальной аудиоцепи после регистрации. Диагностика по трём уровням — сигнализация, медиапоток и локальное аудио терминала — превращает расплывчатую жалобу «зарегистрирован, но не звонит» в последовательность независимо проверяемых этапов и позволяет не тратить время на многократные перезагрузки устройства в неверном направлении.
Почему статус «Зарегистрирован» не означает, что телефон обязательно может выполнять вызовы?
Сначала нужно понять, что именно делает регистрация. Запрос REGISTER, отправляемый терминалом, обычно содержит несколько важных полей: Request-URI, определяющий домен регистрации; To, представляющий регистрируемую учётную запись или Address-of-Record (AOR); Contact, указывающий текущий достижимый адрес терминала, обычно IP-адрес и порт; а также Expires, задающий срок действия регистрации.
Регистрация не является одноразовой операцией. Платформа хранит в службе определения местоположения связь, показывающую, что определённый AOR в данный момент доступен через конкретный Contact. Такая привязка имеет срок действия, часто около одного часа. Терминал должен обновить регистрацию до его истечения. Если этого не сделать, платформа со временем может считать данный внутренний номер отключённым.
Аутентификация обычно проходит в два обмена. Сначала терминал отправляет REGISTER без учётных данных, а сервер отвечает 401 Unauthorized с параметрами проверки подлинности, например realm и nonce. Затем терминал рассчитывает значение Digest-аутентификации по данным учётной записи и отправляет новый REGISTER с заголовком Authorization. Только после этого обычно приходит 200 OK. Следовательно, с точки зрения сигнализации «регистрация успешна» означает лишь то, что терминал и сервер только что завершили аутентифицированную транзакцию REGISTER.
Для реального телефонного вызова требуется значительно больше. После набора номера терминал должен сформировать INVITE. PBX, SIP-сервер или диспетчерская платформа должны маршрутизировать вызываемый номер согласно правилам нумерации и разрешениям. Затем обе стороны через SDP согласуют кодек, медиадрес и RTP-порт, и только после этого голос действительно может передаваться.
Сигнализация и медиа идут по разным путям. SIP-сигнализация обычно использует UDP/TCP 5060 или TLS 5061, а RTP — отдельный диапазон динамических UDP-портов. Если межсетевой экран разрешает 5060, но блокирует диапазон RTP, регистрация будет работать без ошибок, а разговор останется без звука.
REGISTER выполнен успешно
→ SIP-учётная запись отображается как онлайн
→ INVITE всё ещё может быть отклонён
→ Даже если возвращён 200 OK
→ RTP всё ещё может блокироваться межсетевым экраном, NAT или неверным медиадресом
→ Даже если RTP доходит до терминала
→ Локальный микрофон или громкоговоритель всё ещё могут быть неисправны
Ключевой вывод прост: статус регистрации — это снимок, показывающий успешность одной транзакции в определённый момент; он не доказывает сквозную доступность голосовой связи. Он даже не доказывает, что сеть достижима именно сейчас, поскольку регистрация обновляется периодически, а отображаемый статус может лишь отражать последнее успешное обновление.
Сначала определите: проблема в установлении вызова или в передаче голосового потока
Когда сообщают, что телефон «зарегистрирован, но звонить не может», первым шагом не должно быть изменение кодеков или сетевых параметров. Сначала нужно точно определить, что именно означает «не может звонить». Несколько вопросов обычно позволяют выбрать направление диагностики ещё до применения каких-либо инструментов.
Полный SIP-вызов можно разделить на два основных этапа. Первый — установление вызова: от INVITE до ответа 200 OK со стороны вызываемого абонента и отправки ACK вызывающей стороной. Второй — голосовой медиапоток, когда SDP уже согласован и должен реально идти двусторонний RTP. Самая простая граница между этими этапами — отображается ли вызов в интерфейсе как соединённый.
Если при наборе сразу появляется ошибка, отсутствует вызов или удалённый абонент вообще не видит входящего звонка, проблема, скорее всего, в SIP-сигнализации или маршрутизации вызова. Если обе стороны показывают соединение, таймер разговора идёт, но звука нет или он только односторонний, диагностику нужно перенести на медиапуть SDP и RTP.
| Симптом | Вероятный этап | Первые проверки |
|---|---|---|
| Сразу ошибка набора / нет звонка / удалённая сторона ничего не получает | Установление вызова | Маршрутизация номера, разрешения, SIP-коды ответа, достижимость сигнализации |
| Вызов отображается как соединённый, но звука нет | Голосовой медиапоток | SDP-медиадрес, RTP-порты, межсетевой экран, NAT, кодек |
| Соединение есть, но звук только в одном направлении | Голосовой медиапоток | Сравнить SDP, RTP, NAT-сопоставление и захваченные медиапотоки по направлениям |
| Вызов обрывается через несколько секунд | Установление + медиа | ACK, Session Timer, истечение NAT, политика завершения сессии платформой |
| Звук прерывается или становится нестабильным | Качество передачи медиапотока | Потеря пакетов, джиттер, задержка, полоса пропускания и изменения RTP-портов |
Полезны ещё два типичных варианта. Если телефон может звонить наружу, но не принимает вызовы, причина часто связана с маршрутизацией входящего номера, адресом Contact, NAT или маршрутизацией платформы. Если входящие работают, а исходящие нет, следует проверить план набора, исходящие разрешения, формат номера или конфигурацию SIP-транк.
Если обычные SIP-внутренние номера звонят друг другу, но вызовы на диспетчерскую консоль, систему оповещения или PSTN не проходят, область поиска заметно сужается и, вероятнее всего, связана с конкретным маршрутом или интерфейсом системы.
Поэтому полезный отчёт с объекта должен отвечать на четыре вопроса:
Ошибка возникает при исходящих или входящих вызовах?
Есть ли звонок?
Показывает ли интерфейс, что вызов соединён?
Звука нет совсем, он односторонний или соединение обрывается через несколько секунд?
Эти четыре ответа намного полезнее, чем просто фраза «телефон не работает».
Если установление вызова не удаётся, что проверять сначала: номер, разрешения или SIP-ответ?
Если проблема возникает на этапе установления вызова, прежде чем подозревать аппаратную часть взрывозащищённого телефона, пройдите по пути SIP-сигнализации. Практический порядок: номер → разрешения → код ответа → достижимость сигнализации.
Начните с номера и план набора. Соответствует ли Request-URI, отправляемый терминалом, ожиданиям платформы? Нужен ли внутреннему номеру префикс? Требует ли межсистемный набор кода зоны, кода доступа или преобразования номера? Многие случаи «зарегистрирован, но не звонит наружу» в итоге оказываются несовпадением между форматом номера, отправленным телефоном, и правилами маршрутизации PBX.
Например, телефон может отправлять 8001, тогда как PBX ожидает 8#8001 или полный номер в формате E.164. Захват пакетов с Request-URI в INVITE сразу подтверждает это.
Затем проверьте разрешения учётной записи. Некоторые внутренние номера могут выполнять только внутренние вызовы и не имеют доступа к PSTN. Другие могут звонить обычным SIP-абонентам, но не имеют доступа к аварийным линиям, диспетчерским группам или зонам оповещения. Такие настройки класса обслуживания легко пропустить в промышленных проектах, поскольку регистрация не проверяет эти бизнес-разрешения. REGISTER отвечает на вопрос «эта учётная запись онлайн?», а попытка вызова — «разрешено ли этой учётной записи звонить на данное направление?».
Далее SIP-коды ответа помогают ещё сильнее сузить область поиска:
| Класс | Типовые ответы | Типичное направление проверки |
|---|---|---|
| 1xx Информационный | 100 Trying, 180 Ringing, 183 Session Progress | Установление продолжается; проблема может быть дальше по цепочке или в медиа |
| 2xx Успех | 200 OK | Установление успешно; перейти к диагностике медиа |
| 4xx Ошибка клиента | 401/407 аутентификация, 403 запрет, 404 не найдено, 408 тайм-аут, 480 недоступен, 486 занят, 488 несовместимость кодека | Часто связано с конфигурацией терминала, маршрутизацией или политикой сервиса |
| 5xx Ошибка сервера | 500, 503 Service Unavailable | Сторона PBX, SBC или диспетчерской платформы |
| 6xx Глобальная ошибка | 603 Decline | Получатель явно отклоняет вызов |
Некоторые ответы встречаются особенно часто. 401/407 обычно указывают на обработку проверки подлинности — учётные данные, алгоритм или привязку аккаунта. 403 направляет проверку к правилам разрешений, политике учётной записи или причине отказа платформы. 404 может означать отсутствие номера или подходящего маршрута. 408 и 480 связаны с тайм-аутом либо недоступностью пользователя. 488 часто указывает на несовместимые медиавозможности или неудачное согласование кодека.
Если SIP-конфигурация выглядит правильной, но INVITE не доходит до целевой системы, вернитесь к сетевому пути. Проверьте VLAN, шлюз, межсетевой экран, ACL и фактический адрес назначения, который использует телефон. Самый быстрый тест — захват трафика на стороне сервера. Если INVITE приходит, но не пересылается дальше, проверяйте маршрутизацию PBX или диспетчерской платформы. Если INVITE вообще не приходит, сосредоточьтесь на терминале или сети между терминалом и сервером.
Если вызов соединён, но звука нет или он только односторонний, что проверять?
«Обе стороны показывают соединение, но звука нет» — одна из самых распространённых SIP-неисправностей. К этому моменту сигнализация вызова обычно уже завершена успешно. Проблема вероятнее находится в SDP-согласовании или RTP-транспорте. Диагностика должна перейти от сигнальной плоскости к медиаплоскости.
Начните с медиаданных в SDP. Особенно важны строки: c= — адрес соединения, m= — тип медиа и порт, a=rtpmap — сопоставление тип полезной нагрузки с кодеками, a=sendrecv/sendonly/recvonly — направление медиапотока.
Аудиоадрес, объявленный терминалом в SDP сообщения INVITE или 200 OK, должен быть доступен удалённой стороне. Если терминал указывает в SDP немаршрутизируемый частный адрес, например 192.168.x.x, а удалённая сторона находится в другой сети, SIP-вызов всё равно может установиться, хотя RTP-поток никогда не достигнет назначения. Это классический случай «соединение есть, звука нет».
В NAT-средах такая проблема встречается особенно часто, а способ решения зависит от архитектуры сети. SIP-сигнализация может успешно пройти через NAT, в то время как медиапуть полностью не работает. Распространённые типы поведения NAT: полно-конусный NAT, ограниченно-конусный NAT, NAT с ограничением по порту и симметричный NAT — с постепенно усложняющимся прохождением.
В промышленных сетях часто используют SBC как медиарелей, чтобы RTP проходил через известную точку. В других средах STUN помогает определить отображение публичного адреса, а более сложные реализации могут использовать TURN или ICE. Правильный механизм зависит от реальной топологии. Успешный REGISTER не доказывает, что RTP может пройти через NAT.
Межсетевые экраны — ещё одна частая причина. В некоторых проектах открывают только 5060 или 5061 как очевидные SIP-порты, тогда как голос использует отдельный RTP-диапазон. Многие устройства динамически выделяют RTP-порты, например в диапазоне 10000–20000. Если SIP разрешён, а RTP заблокирован ACL, пользователь получает ровно тот симптом: «вызов соединён, но звука нет».
Одностороннее аудио следует диагностировать по направлению. Если диспетчерская слышит полевой телефон, а пользователь на объекте не слышит диспетчерскую, как минимум одно направление RTP или одна локальная аудиоцепь уже работает. Вместо повторной проверки всей сети сравните оба SDP-адреса, RTP-порты, NAT-сопоставления и захваченные медиапотоки. Направленные различия часто прямо указывают на NAT, правило межсетевого экрана или неверный SDP-адрес одной стороны.
После проверки сети проверьте кодек и локальную аудиоцепь
Наличие RTP-пакетов не гарантирует разборчивую речь. Следующий шаг — убедиться, что обе стороны действительно согласовали совместимый кодек.
Согласование кодека работает по модели предложения/ответа SDP. Вызывающий терминал перечисляет поддерживаемые кодеки в SDP INVITE, обычно в порядке приоритета. Вызываемый терминал выбирает один из поддерживаемых им кодеков и возвращает его в 200 OK. Если общих кодеков нет, медиасогласование завершается неудачей.
В промышленных взрывозащищённых телефонах распространены G.711 (PCMU/PCMA, 64 kbps, широкая совместимость с PSTN), G.729 для каналов с меньшей полосой, G.722 для широкополосной речи и Opus на некоторых новых устройствах. Если на телефоне включена только одна группа кодеков, а PBX, система записи или диспетчерская платформа поддерживает другую, результатом может быть 488 Not Acceptable Here либо, в некоторых реализациях, соединённый вызов с аномальным медиапотоком.
Правильный способ диагностики — сравнить тип полезной нагрузкиs и списки кодеков в обоих SDP-сообщениях, а не просто смотреть на страницу управления, где кодек отмечен как включённый.
После подтверждения согласования кодека и RTP-транспорта переходите к физическому аудиотракту терминала. Взрывозащищённые телефоны часто длительно работают в шумной, влажной, пыльной или коррозионной среде. Микрофон, трубка, громкоговоритель, усилительный модуль, разъём или полевой кабель могут выйти из строя даже при полностью исправном SIP-стеке.
Практический метод — сопоставить RTP-статистику с тем, что реально слышно на объекте. Если захват показывает непрерывный двусторонний RTP с нормальным числом и временными интервалами пакетов, но одна сторона всё равно не слышит звук, проверьте состояние отключения звука, уровень аудио и физический микрофон или громкоговоритель. Если RTP передаётся, но аудиосодержимое фактически тихое, нужно проверить и цепь захвата сигнала с микрофона.
При количественном анализе медиа особенно полезны три показателя: потеря пакетов, джиттер и односторонняя задержка. С ростом потерь качество речи ухудшается, чрезмерный джиттер может потребовать большего буфера, а высокая односторонняя задержка мешает естественному разговору. Если потери сосредоточены на конкретном сетевом участке, возможны перегрузка канала или проблемы радиотранспорта.
Для взрывозащищённых переговорно-оповещательных станций с усиленным выходом различайте встроенный громкоговоритель телефона и внешний рупор или выход усилителя. Они не обязательно используют один и тот же аудиотракт. Нормальная работа трубки или громкой связи не доказывает исправность внешнего оповещения, и наоборот. При вводе в эксплуатацию и диагностике каждый требуемый аудиопуть нужно проверять отдельно, не считая любую жалобу «нет звука оповещения» SIP-ошибкой.
Как захват пакетов быстро сужает область неисправности?
При сложной SIP-проблеме многократное изменение параметров обычно менее эффективно, чем запись одного полного неудачного вызова и его последовательный разбор от REGISTER до BYE. В большинстве случаев достаточно Wireshark. Полезные точки захвата: сторона телефона, зеркальный порт коммутатора, сторона SBC или PBX.
Место захвата определяет, что можно доказать. Трасса на терминале точно показывает, что телефон отправил и получил, и помогает определить локальное происхождение ошибки. Трасса на SBC или PBX показывает, правильно ли платформа получила и переслала сигнализацию. В сетях через несколько VLAN, площадок или SBC лучше захватывать в нескольких точках: одна точка доказывает только прохождение сообщения через неё, но не корректную работу следующего сегмента.
После получения трассы анализируйте вызов в следующем порядке:
1. Успешен ли REGISTER?
→ 2. Был ли действительно отправлен INVITE?
→ 3. Получил ли PBX INVITE и правильно ли его маршрутизировал?
→ 4. Вернула ли удалённая сторона 18x / 200 OK?
→ 5. Согласовал ли SDP общий кодек?
→ 6. Есть ли реально двусторонний RTP?
→ 7. Правильны ли IP-адреса и порты назначения RTP?
→ 8. Передают ли полевой микрофон и громкоговоритель реальный звук?
Wireshark предоставляет полезные инструменты. SIP-сообщения можно фильтровать выражениями sip или sip.CSeq. В разделе Telephony → VoIP Calls можно просмотреть вызов вместе с последовательностью сигнализации и связанными RTP-потоками. RTP-анализ также помогает выявить потери, джиттер и другие показатели качества медиа.
Порядок диагностики должен оставаться таким: сначала сигнализация, затем медиа. Если сигнализация не проходит, проблема в установлении вызова. Если сигнализация завершена, но медиа отсутствуют, следует исследовать медиапуть.
Для случая «исходящие работают, входящие нет» проверьте, действительно ли входящий INVITE приходит на взрывозащищённый телефон. Если соединение регулярно обрывается через несколько или десятки секунд, проверьте ACK, Session Timer, NAT-сопоставление и освобождение сессии платформой из-за отсутствия ожидаемого сообщения.
Ещё один менее очевидный случай — повторное согласование медиа во время разговора. re-INVITE может изменить RTP-адрес или порт. Если во время такого согласования ломается NAT-сопоставление, симптом может выглядеть как «несколько секунд всё работало, затем звук пропал».
Цель не в том, чтобы запоминать все SIP-коды ответа. Постоянно задавайте один вопрос: какой последний уровень этот вызов прошёл успешно и где впервые появилось аномальное поведение? После нахождения первого места отказа большая часть диагностики уже выполнена.
Часто задаваемые вопросы
Если SIP-телефон показывает «Зарегистрирован», доказывает ли это хотя бы работоспособность сети?
Нет. Статус «Зарегистрирован» показывает только, что терминал смог завершить SIP-регистрацию с Registrar в определённый момент. Он не доказывает работоспособность маршрутизации, достижимости назначения, RTP, NAT, правил межсетевого экрана или аудиооборудования терминала. Также он не гарантирует отсутствие потерь пакетов или большой задержки во время реального разговора. Поскольку регистрация периодическая, отображаемый статус может отражать только последнее успешное обновление.
Обе стороны показывают соединение, но звука нет. Что проверять первым?
Сначала проверьте медиап IP-адреса, RTP-порты и согласование кодеков в SDP. Затем убедитесь, что межсетевой экран, NAT-устройство или SBC разрешает двусторонний RTP. Если двусторонний RTP точно приходит к обоим терминалам, переходите к микрофону, громкоговорителю, состоянию отключения звука и локальным настройкам вывода. Практический порядок: сначала медиапуть, затем локальное оборудование.
Почему один и тот же взрывозащищённый телефон выполняет внутренние вызовы, но не звонит в PSTN?
Внутренние и PSTN-вызовы обычно используют разные маршруты. Для внешней связи также нужны исходящие разрешения, преобразование номера, конфигурация SIP-транк, маршрутизация оператора и правила отображения номера вызывающего абонента. Успешный вызов между внутренними номерами доказывает только работоспособность части SIP- и медиапути. PSTN-вызов ещё должен пройти через SIP-транк и сеть оператора, где действуют дополнительные правила маршрутизации и политики.
Регистрация нормальная, но звук прерывается или вызов обрывается во время разговора. Что может быть причиной?
Часто проблема в качестве медиатранспорта: потеря пакетов, чрезмерный джиттер, недостаточная полоса или истёкшее NAT-сопоставление могут прервать RTP во время разговора. Сначала проверьте потери и джиттер RTP, затем ёмкость канала и радиопокрытие, если оно используется. Если вызовы стабильно обрываются через предсказуемый интервал, проверьте также повторное согласование медиа через re-INVITE и работу Session Timer.
Почему после замены телефона проблема исчезает, а исходное устройство продолжает не работать?
Это часто указывает на конфигурацию, прошивку или локальное оборудование исходного телефона, а не на сеть. Возможны ошибка прошивки, неверные SIP-параметры — время регистрации, обработка NAT или диапазон RTP-портов — либо неисправность DSP или аудиомодуля. Сравните два устройства параметр за параметром, особенно списки кодеков, SIP-порты и NAT, вместо того чтобы сразу списывать различие на нестабильную сеть.
Можно ли считать перезагрузку взрывозащищённого SIP-телефона правильным методом диагностики?
Перезагрузка иногда временно восстанавливает регистрацию, обновляет NAT-сопоставление или освобождает зависший процесс, но не должна заменять локализацию неисправности. Если причина в план набора, SIP-разрешениях, правилах межсетевого экрана, согласовании кодеков или медиамаршрутизации, перезагрузка лишь ненадолго скроет проблему или не поможет вообще. Лучше зафиксировать симптомы, сохранить трассы сигнализации и журналы, а затем определить, где впервые возникает сбой — в терминале, сети или коммуникационной платформе.
Becke Telcom может помочь с диагностикой с учётом реальной архитектуры терминала, IP PBX, SIP-транк, сетевой коммутации, SBC и диспетчерской системы. Becke Telcom также поставляет взрывозащищённые телефоны, взрывозащищённые переговорно-оповещательные телефоны, SIP-шлюзы, IP-оповещение и оборудование интегрированной диспетчеризации для нефтехимии, энергетики, горнодобывающей отрасли, тоннелей и других промышленных объектов.
