Профиль, проверка подлинности и контакт решают разные задачи
В конфигурации PJSIP серверной системы Asterisk профиль endpoint связывает параметры устройства с другими объектами. Объект auth содержит настройки проверки подлинности, а AoR позволяет связать устройство с контактами, по которым его можно вызвать. Это разные роли, даже если администратор дал объектам похожие имена. Наличие записи об учётных данных не создаёт автоматически маршрут звонка. Также не стоит считать любой раздел регистрации настройкой телефона: отдельный объект registration используется для исходящей регистрации самого сервера на другой системе. В нашем учебном случае речь идёт о внутренних телефонах.
Набранный номер ищут в определённом контексте
Правила обработки вызовов организованы в план набора, который разделён на контексты. Контекст содержит доступные в нём номера и соответствующие действия; связи с другими контекстами задаются отдельно. Поэтому одинаковый номер может существовать в одной части плана и отсутствовать в другой. Для вызова важно, в какой контекст он попал. Если правило записано где-то в конфигурации, это ещё не доказывает, что именно этот звонок сможет его использовать. Сначала нужно установить точку входа, а затем проследить доступный путь обработки.
Два телефона и один недостающий маршрут
Представим вымышленный сервер с телефонами А и Б. У обоих есть необходимые профили и актуальные контакты. Вызов от А поступает в контекст внутренней связи. Однако действие для номера Б записано только в отдельном контексте испытаний, который из внутренней связи не подключён. По условиям этой модели регистрации успешны, но нужное правило недоступно из точки входа вызова. Это объяснение конкретного бумажного случая, а не диагноз любого сбоя телефонии. В реальной системе похожий симптом может иметь другие причины, поэтому вывод сопоставляют с журналом именно рассматриваемого вызова.
Фиксируйте границу уже проверенного
Для последовательного разбора полезно записать: что известно об устройстве, есть ли его контакт, откуда началась обработка набранного номера и какое действие было выбрано. Не следует объединять все ответы словом работает. Успешная регистрация, найденный маршрут и состоявшийся разговор — разные наблюдения. Если маршрут найден, но разговор не состоялся, дальнейший разбор начинается с нового установленного факта. Не нужно по одному признаку отключать проверки подлинности или открывать сервер наружу. Учебная схема помогает сформулировать вопрос к конфигурации, но сама не является готовой настройкой безопасной телефонии.
Попробуйте на практике
Найдите недостающую связь в бумажной модели, не подключаясь к реальному серверу.
- Нарисуйте телефоны А и Б и отметьте условие: необходимые профили и актуальные контакты обоих устройств уже есть.
- Нарисуйте два контекста: внутренняя связь и испытания. Укажите, что вызов от А входит в первый.
- Поместите действие для номера Б только в контекст испытаний. По условию между контекстами нет подключения; проследите путь вызова.
- Запишите, какое условие нужно проверить в плане набора, чтобы номер Б оказался доступен из нужной точки входа. Не записывайте это как команду изменения рабочего сервера.
Как проверить результат. Проблема учебной схемы находится в доступности правила из контекста входящего вызова. Успешная регистрация не устраняет отсутствующую связь между частями плана. Из бумажного решения не сделан вывод о работоспособности реальной сети.
Частые вопросы
Если телефон зарегистрирован, его номер уже существует в плане набора?
Не обязательно. Контакт устройства и действия для набранного номера относятся к разным частям настройки. Их соответствие проверяют отдельно.
Можно ли использовать одинаковые имена объектов?
Имена могут совпадать в допустимых конфигурациях, но это не отменяет различия ролей. При разборе полезно указывать не только имя, но и тип объекта.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.