Проверяем путь конфигурации SIP-телефона по шагам

Если SIP-телефон не берёт конфигурацию, сначала выясните, дошёл ли он до сервера загрузки и какой ответ получил. Это отдельный процесс от SIP-регистрации в Asterisk. Я покажу, как проверить DHCP, файлы и шаблоны, а затем отдельно разобрать регистрацию и NAT.

Сначала разделите загрузку конфигурации и регистрацию

Автонастройка и регистрация в Asterisk — два разных этапа. Сначала телефон получает адрес сервера конфигурации, запрашивает файл и пытается разобрать его. Затем он использует полученные параметры, чтобы зарегистрироваться на SIP-сервере. Если аппарат загрузился со старыми настройками, ищите сбой на первом этапе. Если файл скачан и применён, но регистрации нет, тогда проверяйте учётные данные, адрес Asterisk, транспорт и сетевую доступность. Смешать эти два сценария легко; найти причину после этого гораздо труднее. Отдельно проверьте, не задан ли вручную старый адрес сервера в настройках аппарата. Это отделяет ошибку сети от ошибки SIP-учётной записи.

Начните с наблюдаемого: какой адрес и имя файла запросил телефон, какой сервер ответил, какой код или сообщение показал аппарат. Сверьте MAC-адрес с именем файла, если модель строит имя по MAC. Убедитесь, что устройство находится в нужной VLAN и получает адрес из правильного DHCP-пула. Иначе оно может исправно скачать чужую конфигурацию или не найти файл вовсе. Один и тот же симптом «не берёт конфиг» скрывает разные неисправности. Диагноз по одной фразе — это гадание, только с более дорогим счетом. Зафиксируйте модель и версию прошивки: одна и та же марка может менять правила загрузки между линейками. Запишите исходное состояние до изменений, чтобы результат проверки можно было повторить и сравнить.

DHCP сообщает телефону адрес сервера

Для многих моделей точка входа — DHCP. Например, option 66 передаёт имя или адрес одного TFTP-сервера; отдельные модели используют option 150, а другие варианты и адрес сервера задаются по правилам производителя. Это не универсальная кнопка «включить телефонию»: сначала проверьте руководство именно к вашей модели и прошивке. В базе знаний зафиксировано применение option 66 для передачи адреса сервера автопровижининга. У Cisco для некоторых телефонов документированы и option 66, и option 150. Следовательно, копировать чужую DHCP-настройку без проверки модели — плохая идея. Сначала убедитесь, что DHCP-ответ относится именно к сети голосовых устройств. Сохраните lease и параметры телефона вместе с результатом.

Проверьте ответ DHCP с самого телефона или снимите трафик на его сегменте. Убедитесь, что выдан ожидаемый адрес сервера, имя разрешается, а пул не исчерпан. Для первичной проверки можно временно задать адрес сервера в веб-интерфейсе телефона, если модель это допускает. Если так устройство находит файл, проблема, скорее всего, в выдаче DHCP или в сетевом пути от клиента к серверу. После проверки верните штатную схему: ручной адрес на каждом аппарате превращает одну ошибку DHCP в десятки будущих ошибок эксплуатации. Если одновременно установлено несколько аппаратов, сравните их DHCP-ответы и журналы. Успешно настроенный телефон в том же сегменте — полезный контрольный пример, но не доказательство одинаковых настроек: могли отличаться VLAN, прошивка или сохранённый профиль.

Проверьте сервер и сам запрошенный файл

Получив адрес сервера, телефон должен достучаться до службы конфигурирования и запросить правильный путь. Не сводите проверку к словам «порт открыт»: убедитесь, что служба слушает нужный интерфейс, правило межсетевого экрана пропускает именно этот обмен, а в журнале сервера появляется запрос от адреса телефона. TFTP часто использует UDP/69 для начального запроса, но далее протокол задействует согласованный UDP-порт передачи. Поэтому одно правило только на UDP/69 может оказаться недостаточным. Если модель умеет HTTP или HTTPS, используйте предусмотренный производителем протокол и проверьте URL, сертификат и доступность пути. Ответ сервера сопоставляйте с настройками конкретной модели, а не только с кодом HTTP. Учтите, что межсетевой экран может менять поведение UDP.

Затем запросите тот же файл вручную с тестовой машины в той же сети и сравните результат с запросом телефона. Проверьте точное имя, регистр букв, каталог публикации, права чтения и содержимое ответа. Файл может существовать, но быть недоступен службе; может открываться браузером администратора, но не клиентом в изолированной VLAN. Не называйте XML «битым», пока не посмотрели байты ответа и журнал доступа. Иногда сервер отдал 404, иногда не ответил вообще, иногда аппарат скачал валидный XML, который не понимает из-за формата конкретной модели. Это три разных ремонта. При захвате пакетов фильтруйте по адресу телефона и времени его перезагрузки. Важен не только факт запроса: проверьте имя файла, транспорт, адрес назначения и ответ сервера. Так станет видно, где последовательность прерывается.

Шаблоны Asterisk: где появляются переменные

Asterisk может обслуживать конфигурации телефонов модулем res_phoneprov. В профиле задают статические файлы и динамические имена; для динамического файла можно использовать подстановку переменных Asterisk, например MAC-адреса, а шаблон хранить отдельно. Это конкретный путь реализации, но он не означает, что любая установка Asterisk уже раздаёт телефонные конфиги. Проверьте, загружен ли нужный модуль, настроен ли профиль и совпадает ли запрошенный телефоном URI с динамическим именем. Если используется отдельный TFTP/HTTP-сервис или система управления телефонией, проверяйте её конфигурацию, а не ищите магический переключатель в Asterisk. В тестовый файл полезно включить безопасное, заметное изменение одного параметра. Проверяйте именно ответ для этого устройства и его модели.

При подозрении на ошибку шаблона сравните исходник с результатом, который сервер отдал конкретному аппарату. Проверьте, из какого контекста подставляются переменные, что передаётся в генератор и не пусты ли значения для этого устройства. В документации Asterisk пример res_phoneprov связывает динамический URI с шаблоном и отдельно предупреждает о порядке загрузки функций, нужных при формировании имени. Файл modules.conf управляет загрузкой модулей, но autoload=yes само по себе не исправит неверный профиль или пустую переменную. Конфиг не телепат: ему нужно дать правильные входные данные. Учтите, что телефон может хранить прежний профиль или использовать резервный адрес. Перед выводом о DHCP сравните выданные параметры с экраном сетевого статуса самого аппарата и документацией производителя.

Логи и безопасная последовательность диагностики

Соберите события в одну временную линию: DHCP-ответ, запрос к серверу конфигурации, ответ с файлом, сообщение телефона о применении и попытка SIP-регистрации. Сопоставляйте время, IP устройства и MAC-адрес. В Asterisk смотрите журнал и CLI только для этапа регистрации и загрузки модулей. Если телефон ни разу не запросил файл, перезапуск Asterisk вряд ли поможет: сначала проверьте DHCP, VLAN и адрес сервера. Если запрос виден, но файл не отдан, изучайте журнал службы конфигурирования. Если файл скачан, но отвергнут, проверьте формат и сообщения самого телефона. Не публикуйте секреты SIP и пароли в общем шаблоне или открытом журнале. Если файл скачан, повторно проверьте его содержимое и версию.

Для модульной функции Asterisk проверьте modules.conf: в нём задают автоматическую или явную загрузку модулей, а также исключения. Команда module show like phoneprov в CLI помогает понять, загружен ли соответствующий модуль; сама по себе она ничего не меняет. Не добавляйте в чеклист features.conf, A2Billing или phpagi.conf просто потому, что эти имена встречаются в старых инструкциях. features.conf относится к пользовательским кодам и функциям вроде перехвата вызова; настройки AMI могут понадобиться A2Billing. Это отдельные задачи и без конкретного симптома к загрузке конфигурации телефона отношения не имеют. Если файл приходит по HTTP(S), проверьте доступ не только с сервера, но и из клиентской VLAN. DNS, маршрут, сертификат и авторизация могут вести себя по-разному для администратора и телефона.

NAT относится к связи, а не к выдаче файла

Если телефон уже получил конфигурацию, но не регистрируется или нет звука, переходите к SIP и RTP. За NAT Asterisk на PJSIP может публиковать внешний адрес для сигнализации и медиа; официальная документация описывает local_net, external_signaling_address и external_media_address, а параметры подбираются под схему сети. В базе знаний также встречаются local_net и rewrite_contact как настройки, которые стоит проверить в соответствующем NAT-сценарии. Не переносите значения из примера в рабочий конфиг без адресного плана. Главное — сопоставить SDP и Contact с тем, какие адреса реально доступны телефону и серверу. Перед изменением modules.conf выясните, какие ещё функции зависят от загрузки модулей. Не объявляйте причину найденной, пока не повторили проверку.

STUN не является обязательным условием загрузки конфигурации и не служит универсальным исправлением NAT. Нужен ли он конкретному телефону, зависит от топологии и поддержки со стороны устройства. Для локальных аппаратов в одной сети проблема может оказаться в неверной учётной записи; для удалённых — в маршрутизации, правилах экрана, SIP-транспорте или RTP. Проверяйте регистрацию отдельной командой CLI и смотрите, какой адрес зарегистрирован. Если файл уже скачан, возвращаться к DHCP option 66 бессмысленно. Разные этапы, разные журналы, разные причины. У TFTP проверьте диапазон UDP-ответов и состояние отслеживания соединений на межсетевом экране. Сетевые правила, подходящие для тестового запроса из той же подсети, не обязательно работают через маршрутизатор между VLAN.

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