Звонок в Asterisk оборвался через 30 секунд? Проверяем SIP и RTP

Обрыв примерно через 30 секунд сам по себе не доказывает, что виноваты таймеры. Я начинаю с SIP-трассы: кто отправил BYE, был ли ответ на запрос и что происходило с RTP. Затем проверяю транспорт NAT и согласованные кодеки — без правок наугад.

Что означает обрыв примерно через 30 секунд

Фраза «ровно через 30 секунд» полезна как наблюдение, но это не название конкретной неисправности. SIP-сессия и медиапоток — разные части вызова: телефон может успешно установить сигнализацию, а RTP при этом идти только в одну сторону или не идти вовсе. Таймеры тоже существуют, но у них разные задачи. По одному времени завершения нельзя заключить, что Asterisk решил считать линию мёртвой.

Я фиксирую три момента: начало вызова, первый подозрительный пакет и завершение. В SIP-трассе ищу запрос BYE, ответы на INVITE и re-INVITE/UPDATE, а также таймерные заголовки, если они есть. Если BYE отправил удалённый телефон или оператор, нужно выяснять, почему его сторона завершила сессию. Если BYE отправил Asterisk — проверяю его журнал и логи приложения. Если обмен сигнализацией продолжается, но пропадает звук, исследую RTP отдельно. Секундомер — улика, не приговор.

Настройка timers в PJSIP относится к SIP session timers и согласованию обновления сессии. Она не включает универсальный keepalive для голоса, не чинит NAT и не означает «подтверждать ACK каждые 30 секунд». Значения timers_min_se и timers_sess_expires задают ограничения для времени сессии; менять их следует только когда трасса показывает проблему именно в этой процедуре. Иначе можно изменить поведение вызовов, не затронув причину.

Сначала собираю трассу, а не меняю конфиг

Подключитесь к CLI Asterisk и включите временную диагностику командами core set verbose 4, core set debug 4 и pjsip set logger on. Официальное руководство Asterisk рекомендует эти команды для сбора данных о проблеме PJSIP. После воспроизведения сохраните относящийся к вызову фрагмент и отключите подробный SIP-лог командой pjsip set logger off: в нём могут быть номера, адреса и другие данные участников.

Для проверки объектов используйте pjsip show endpoints, а для конкретного объекта — pjsip show endpoint ИМЯ. Эти команды показывают конфигурацию и состояние endpoint, но не доказывают, что RTP проходит между сторонами. Сопоставьте их с SIP-трассой и системным журналом Asterisk. Ищите инициатора BYE, коды ответа, повторные запросы без ответа, SDP с адресами медиа и момент, когда пропал звук. Сравните несколько вызовов: один сбой может быть случайностью, повторяемый рисунок уже полезен.

Не включайте отладку надолго на нагруженной АТС. Сначала зафиксируйте время и конкретный вызов, затем соберите минимальный диагностический фрагмент. Не публикуйте полный SIP-лог в открытом тикете: в нём могут оказаться идентификаторы звонка, номера, IP и данные авторизации. Если причина не видна, используйте захват пакетов на подходящих интерфейсах и сопоставьте его с журналом. Инструмент захвата помогает увидеть обмен; он не подменяет понимание, какой узел отправил завершающий запрос.

Сохраните исходный материал так, чтобы была видна последовательность сообщений, а не только строка ошибки из конца журнала. Для одного вызова важны Call-ID и временные отметки; при сравнении тестов сопоставляйте именно одинаковые направления и типы устройств. Снимок состояния endpoint полезен рядом с трассой, потому что показывает применённую конфигурацию. Если журнал панели управления расходится с файлом, сначала выясните, какой источник фактически управляет параметрами. Иначе можно часами исправлять файл, который Asterisk не читает.

Ошибка первая: принять session timers за keepalive

В res_pjsip параметр timers управляет SIP session timers. Это механизм обновления и ограничения срока SIP-сессии, согласуемый участниками вызова. Он не проверяет доступность RTP и сам по себе не гарантирует, что конечное устройство ответит на OPTIONS. Поэтому совет «добавьте timers=yes во все endpoints, и звонки перестанут падать» неверен: без трассы он предлагает менять штатное поведение наугад.

Проверьте, что именно договорились использовать стороны: наличие поддержки timer в SIP-заголовках, значения Session-Expires и Min-SE, периодические re-INVITE или UPDATE и ответы на них. Если журнал показывает отказ или отсутствие ответа именно на обновление сессии, изучите timers, timers_min_se и timers_sess_expires в документации для установленной версии Asterisk. Не переносите директивы из chan_sip механически: у PJSIP другая модель объектов и параметры не всегда совпадают.

OPTIONS и keepalive — отдельная диагностика доступности контакта/транспорта. Настройки qualify и транспортного keepalive не становятся заменой session timers. Сначала определите, какой пакет перестал получать ответ и кто завершил вызов. После точечной правки перечитайте конфигурацию подходящей командой pjsip reload, если сборка и способ управления Asterisk это поддерживают; в некоторых системах настройки управляются через панель, и ручное редактирование файла будет перезаписано.

Ошибка вторая: искать NAT не в том объекте

При Asterisk за NAT важны адреса из SDP и SIP-заголовков, а также маршрут RTP через маршрутизатор. В типовом сценарии внешняя адресация external_media_address, external_signaling_address и локальная сеть local_net указываются в секции type=transport; direct_media относится к endpoint. Это принципиально: совет добавить внешние адреса «в секцию endpoint» смешивает объекты конфигурации. Официальный пример Asterisk описывает эти параметры именно на transport.

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

В параметрах NAT PJSIP также могут участвовать rtp_symmetric, force_rport и rewrite_contact для удалённых устройств за NAT. Их применимость зависит от топологии и направления вызова. Не копируйте весь набор без разбора: при прокси, нескольких сетевых интерфейсах или раздельных адресах сигнализации и медиа схема отличается. SIP ALG можно проверить как возможный источник изменения пакетов, но не объявлять виновником заранее; отключение имеет смысл как контролируемый сравнительный тест с ответственным за сеть.

Адрес, который виден на сервере, не всегда совпадает с тем, который должен быть объявлен удалённому узлу. В документации Asterisk NAT-правила переписывают адрес медиа в SDP при заданных условиях: назначение находится вне local_net, а исходный адрес SDP относится к локальной сети. Поэтому проверьте и саму подсеть local_net, и адреса в SDP, и путь обратного RTP. Если сигнализация и медиа используют разные внешние адреса, настройка должна отражать именно эту схему. Одно поле с публичным адресом не исправит неверный маршрут или ошибочную маску локальной сети.

Ошибка третья: объявить кодеки причиной таймера

Кодеки согласуются при установлении медиасессии. У сторон должен быть совместимый набор форматов, иначе вызов может не установиться или медиа не заработает как ожидается. Но несовпадение кодеков не объясняет автоматически завершение ровно через 30 секунд. Если голос есть, а затем сессия завершается, ищите в SIP-трассе, кто прислал BYE и что происходило непосредственно до него. Не смешивайте качество RTP, переговоры о кодеках и таймеры SIP в одну причину.

В endpoint можно ограничить список кодеков параметрами disallow и allow; официальный пример использует disallow=all и разрешает нужный формат через allow. Для диагностики сравните SDP предложения и ответа на INVITE, а также настройки обоих endpoints и транка. Убедитесь, что есть общий формат и что Asterisk располагает нужной поддержкой, если требуется транскодирование. Приоритет сам по себе не «лечит стабильность»: он влияет на выбор среди допустимых форматов.

Делайте одну правку за раз и повторяйте вызов в одинаковых условиях. Сначала сохраните исходный pjsip.conf, затем проверьте результат загрузки конфигурации и трассу. Если после изменения списка кодеков вызов всё ещё завершается, не оставляйте эту гипотезу единственной: вернитесь к автору BYE, ответам на SIP-запросы и маршруту RTP. Устойчивый телефонный сервис получается из проверяемых причин, а не из длинного списка «полезных» директив.

При согласовании кодеков читайте SDP целиком и сравнивайте предложения двух сторон. Список, разрешённый в одном endpoint, не показывает, что в итоге согласовано с транком. Если после установления вызова аудио продолжает идти, а через фиксированное время приходит BYE, приоритет кодека — слабая гипотеза без подтверждающей записи. Если же вызов не устанавливается или медиа не согласуется, общий поддерживаемый формат становится прямым направлением проверки. Такой порядок экономит время и не заставляет менять кодеки без основания.

Порядок исправления и безопасная проверка

Сведите наблюдения в короткую таблицу: время вызова, инициатор завершения, последний успешный SIP-обмен, направление RTP, изменение после теста. Это отделяет проблему сигнализации от медиа. Если в трассе запрос обновления сессии остаётся без ответа, исследуйте timers и доступность второй стороны. Если SIP продолжается, но нет аудио, проверяйте SDP, NAT и RTP. Если вызов завершает удалённая сторона, запросите её журнал или данные оператора — локальный конфиг не объяснит удалённое решение без фактов.

Изменения выполняйте в согласованное окно, с копией конфигурации и понятным способом отката. Для PJSIP конфигурация обычно перечитывается через pjsip reload, однако поведение транспорта и способ управления зависят от установленной версии и платформы; сверяйтесь с документацией и журналом после команды. Не перезапускайте весь сервер только ради эксперимента, если достаточно штатной перезагрузки конфигурации. После правки проверьте входящие и исходящие вызовы, удержание/перевод, двусторонний звук и повторение исходного сценария.

Если симптом воспроизводится лишь у удалённых телефонов, разбирайте их NAT и сеть отдельно от локальных аппаратов. Если обрываются только звонки через транк — анализируйте обмен с оператором и согласованные параметры. Если проблема появилась после миграции chan_sip на res_pjsip, перепроверьте соответствие объектов и NAT-настроек по руководству миграции. Автоконвертация не заменяет проверку. Так мы получаем объяснимое исправление, а не конфигурацию, которую страшно трогать.

Частые вопросы