Взрывозащищённый SIP-телефон может показывать состояние «Зарегистрирован», хотя вызовы не поступают, соединяются без звука или обрываются после ответа. Регистрация, установление вызова, передача медиаданных и физический звуковой тракт требуют отдельных проверок. Определите первый неработающий этап, прежде чем менять настройки или заменять телефон.
Начните с удалённых журналов и согласованного тестового вызова. Физический осмотр во взрывоопасной зоне требует компетентного персонала, разрешений объекта, отключения источников энергии и соблюдения инструкций оборудования. Не открывайте корпус под напряжением и не подключайте обычный ноутбук или измерительный прибор во взрывоопасной зоне без необходимых мер контроля. Сетевая диагностика не подтверждает целостность взрывозащиты.
Что подтверждает регистрация и что остаётся непроверенным
Успешная транзакция REGISTER подтверждает принятие запроса регистратором; для понимания результата проверьте привязки Contact и срок их действия. Аутентификация распространена, но сам по себе 200 OK не доказывает, что она выполнялась. Отображаемое состояние может отражать прежнее обновление, а не текущую доступность.
Для вызова всё ещё нужны доставка INVITE нужному адресату, приемлемое описание сеанса и работающий звуковой тракт. Contact терминала, маршрутизация PBX, шлюз или SBC и адрес медиаданных могут использовать разные адреса и политики. Аналоговый взрывозащищённый телефон через шлюз FXS необходимо диагностировать с учётом этого шлюза; сам телефон не является нативным SIP-терминалом.
Классифицируйте симптом до изменения конфигурации
| Наблюдаемый симптом | Какие данные собрать вначале |
|---|---|
| Нет звонка или немедленная ошибка | Исходящий INVITE, адресат, окончательный ответ и маршрут PBX. |
| Соединение без звука или с односторонним звуком | Адреса и порты SDP, затем поступление медиаданных в каждом направлении. |
| Вызов обрывается после ответа | Доставка ACK, отправитель BYE, таймеры транзакций и журналы платформы. |
| Прерывистая или периодически пропадающая речь | Пропуски последовательности RTP, джиттер, загрузка канала и поведение локального аудио. |
Запишите время, номера вызывающей и вызываемой сторон, направление, прошивку, топологию и недавние изменения. Проверьте, одинаково ли отказывают внутренние, внешние, диспетчерские и громкоговорящие направления. Отказ отдельного маршрута отличается от проблемы всех вызовов; сохраните трассировку сбоя до перезагрузки или редактирования конфигурации.
Шаг 1: проследите сигнализацию до первого сбоя
Сверьте набранный номер с фактическим Request-URI и планом нумерации PBX. Проверьте префиксы, преобразование номеров, разрешения исходящих вызовов и маршрут к нужному абоненту или транку. При входящих сбоях проверьте текущий зарегистрированный Contact и поступление входящего INVITE на телефон.
Рассматривайте коды ответов как данные, а не готовые диагнозы. Первый 401 или 407 может быть обычным запросом аутентификации; исследуйте цикл или отклонённую повторную попытку с аутентификацией. 403 означает отказ, 404 — отсутствие адресованного пользователя или домена, 408 — тайм-аут, 480 — временную недоступность. 488 может отклонять характеристики сеанса, не ограничиваясь несовместимостью кодеков. Читайте подробности ответа и журналы системы, которая его сформировала.
Если PBX вообще не получает INVITE, сравните результаты DNS, VLAN, шлюз, транспорт, порт назначения и правила доступа. Если запрос получен, но не пересылается, проверьте маршрутизацию и политики платформы. Для INVITE с ответом проверьте 200 OK и ACK на соответствующих участках вызова; индикация соединения сама по себе не доказывает завершения каждого обмена.
SIP часто использует порт 5060 или 5061 с TLS, но возможны и другие порты. Проверяйте настроенный транспорт и прослушиваемые службы вместо открытия предполагаемого диапазона. При TLS обычный сетевой захват не раскрывает зашифрованное содержимое SIP; используйте разрешённую диагностику терминала или сервера.
Шаг 2: сравните SDP с реальным медиатрактом
Исследуйте согласованный SDP, включая c=, m=, a=rtpmap и атрибуты направления, например a=sendrecv. Проверьте параметры соединения на уровне сеанса и медиапотока, принятые форматы, отклонённые или неактивные потоки. Обмен предложением и ответом может идти в разных сообщениях SIP; не предполагайте, что INVITE и 200 OK всегда содержат всё согласование.
Убедитесь, что каждый объявленный медиаадрес и порт достижим в используемой топологии. Частный адрес создаёт проблему, когда другая сторона не может маршрутизировать к нему трафик, а не просто потому, что он частный. Сравните пакеты по обе стороны межсетевого экрана или границы NAT, чтобы определить, где прерывается одно направление. Разрешайте настроенные медиапотоки; универсального диапазона портов RTP для всех телефонов нет.
SBC может закреплять медиатрафик на себе, если настроен соответствующим образом. STUN, TURN и ICE выполняют разные задачи и требуют совместимой поддержки терминала и платформы; ни один из них не является универсальным переключателем для исправления NAT. Изучите проект до изменения SIP ALG или поведения межсетевого экрана и сохраните возможность отката.
Сравните принятые типы полезной нагрузки, параметры кодеков, пакетизацию и требования RTP/SRTP на каждом участке. Шлюз или PBX может транскодировать только при поддержке и включении этой функции. Ответ SDP может принимать несколько форматов; неверно считать, что каждый ответ выбирает ровно один кодек. Не определяйте поддержку кодеков по взрывозащищённому корпусу или другой модели.
Если медиаданные прекращаются после удержания, перевода или re-INVITE, сравните новые адреса, порты и направление SDP с исходным сеансом. При разрывах через фиксированный интервал изучите сообщение освобождения и журналы до обвинения таймера сеанса или истечения NAT. Потери RTP и джиттер описывают транспорт; ни то ни другое не доказывает, что микрофон формирует пригодную речь.
Шаг 3: проверьте локальный звуковой тракт и необходимые службы
Когда медиаданные достигают нужных терминалов, по утверждённым процедурам проверьте отключение звука, усиление, трубку, микрофон, громкоговоритель и выбранный аудиовыход. Двунаправленные пакеты могут нести тишину или недекодируемую нагрузку. Сравните с заведомо рабочим вызовом и терминалом, не считая замену доказательством аппаратного дефекта: учётные данные, прошивка, порт коммутатора и сетевые настройки тоже могут отличаться.
Проверяйте трубку, громкую связь и внешние выходы оповещения отдельно, если они имеются. Рабочая трубка не доказывает исправность внешнего усилителя, рупорной линии или реле оповещения. Отображение местоположения у диспетчера, запись, приоритет и связь с сигнализацией относятся к платформе или интеграции, если конкретный терминал явно не реализует их сам.
Используйте синхронизированные захваты в подходящих разрешённых точках: диагностика терминала, зеркальный порт коммутатора, PBX или SBC. Сопоставляйте SIP Call-ID и временные метки, учитывая, что SBC может создавать разные участки вызова. Захватывайте только необходимый трафик и защищайте журналы и записи. Зашифрованный SRTP нельзя прослушать из обычного захвата без разрешённого ключевого материала и подходящего метода анализа.
После одного контролируемого изменения повторите неисправный маршрут и оба направления аудио, затем проверьте затронутые функции оповещения или диспетчеризации и восстановление после запланированного переключения. Сохраните итоговые настройки, ссылку на трассировку и результат. Долгосрочные методы мониторинга и настройки описаны в материале об удалённом обслуживании взрывозащищённых телефонов громкого оповещения.
Частые вопросы
Почему внутренние вызовы работают, а внешние — нет?
Внешние вызовы добавляют маршрутизацию транка, разрешения, преобразование номеров и вышестоящие политики. Сравните успешный внутренний путь с неуспешным транковым вызовом, включая обратную сигнализацию и участки медиатрафика, вместо предположения, что регистрация проверяет транк.
Нужно ли считать любую проблему отсутствия звука ошибкой кодека?
Нет. Сначала установите согласованные параметры сеанса и поступление медиаданных на каждый терминал. Маршрутизация, NAT, правила доступа, совместимость SRTP и локальное аудио могут приводить к тишине. Настройка кодека на веб-странице не доказывает, что было согласовано в вызове.
Является ли перезагрузка ремонтом?
Перезагрузка может восстановить процесс или обновить привязку, но не выявляет причину. По возможности сначала сохраните данные, затем проверьте воспроизводимость восстановления. Зафиксируйте перерывы обслуживания и организуйте предусмотренный на объекте альтернативный способ связи на время работ.
Технические источники
Протокольная основа: IETF RFC 3261, SIP и IETF RFC 3264, предложение/ответ SDP. Контекст обслуживания опасных зон: рекомендации HSE по электрооборудованию в потенциально взрывоопасных атмосферах.
