Кратко

  • RFC 5133 — Proposed Standard декабря 2007 года, обновляющий RFC 4233.
  • RFC 4129 ранее назначил management type 5 запросу состояния DLC в DUA.
  • RFC 4233 позднее назначил тот же type 5 запросу TEI в IUA.
  • При одинаковых class 0/type 5 заголовок не различал две операции.
  • RFC 5133 требует кодировать TEI Query Request типом 8.
  • Текущий реестр IANA сохраняет DLC Status Request под 5, а TEI Query Request под 8.
  • Уникальная регистрация не доказывает обновление установленного ПО.
  • Работающая SCTP association не доказывает активность ASP и поддержку type 8.
  • RFC 4129 рекомендует PPID 10 для DUA, но допускает PPID 1 в совмещённом backhaul.
  • SCTP сам не использует PPID как семантическую проверку; это не аутентификация.
  • ASSIGNED означает, что Q.921 считает TEI назначенным, а не что личность устройства проверена.
  • Необходимо разделять реестр, build, конфигурацию, transport, wire, decode, response, link и service outcome.

Узкое слово стало широкой претензией

Слово ASSIGNED выглядит окончательным. Но в RFC 4233 у него есть точный субъект: Q.921 рассматривает TEI как назначенный. Это состояние layer management. Оно не содержит имени абонента, серийного номера, сертификата, физического присутствия или факта текущего обмена сигнализацией.

Статус полезен именно в своей узкой роли. ASP может подготовиться к приёму и передаче сигнализации, решить, запрашивать ли установление data link, или проверить неожиданный TEI. Эти действия ещё не произошли только потому, что пришла индикация.

Поэтому интерфейс должен писать «TEI считается назначенным Q.921 на такой-то интерфейс и момент», а не «терминал подтверждён». Последняя фраза переносит утверждение через несколько ненаблюдаемых слоёв.

До статуса была коллизия

Первоначальный IUA в RFC 3057 не определял TEI Query. RFC 4129 расширил архитектуру для DPNSS/DASS 2 и ввёл management-сообщения DLC Status: Request 5, Confirm 6, Indication 7. RFC 4233 затем добавил TEI Query Request и также использовал management type 5.

Один и тот же class 0/type 5 стал обозначать два вопроса. Получатель не мог извлечь различие из common header. Роль устройства или ожидание оператора могли подсказать догадку, но догадка не была свойством пакета.

RFC 5133 перенёс TEI Query на type 8. IANA сейчас показывает раздельные назначения. Исправление возвращает детерминированную интерпретацию для реализаций, которые его применяют.

Оно не вводит capability negotiation, transition marker, request identifier или downgrade. И не обновляет старые binary. Нормативная однозначность и фактическая совместимость — разные состояния.

Внешний PPID не заменяет внутренний тип

RFC 4129 рекомендует PPID 10 для DUA и 1 для IUA. Но он допускает использование IUA PPID для DUA, например при backhaul ISDN и DPNSS через одну SCTP association. Документ также говорит, что SCTP непосредственно не использует PPID; некоторые entities могут применять его для распознавания содержимого DATA chunk.

Следовательно, PPID — метка верхнего уровня, а не принуждение transport. Разрешённая конфигурация может делить значение. Capture может потерять ancillary context. Parser может выбрать ветвь по ошибочной роли. Коллизия class/type должна была быть устранена независимо.

Наблюдение PPID 1 и class 0/type 8 хорошо подтверждает современный IUA TEI Query в точке захвата. Оно не подтверждает организационную идентичность peer, его полномочия, build получателя или полноту ответа.

SCTP может исправно переносить несовместимость

RFC 4233 разделяет SCTP association, состояние ASP и application traffic. Association может быть up, пока ASP остаётся INACTIVE. Mapping Interface Identifier на association/stream меняется при смене состояния и может временно быть недействительным во время failover.

Поэтому транспортный health check — лишь один receipt. Для RFC 5133 нужны peer, association, stream, PPID, version, class, type, length, direction, builds обоих концов, parser branch и ответ.

Unsupported Message Type означает отсутствие поддержки типа. Unexpected Message говорит о неожиданности в текущем состоянии или процедуре. Protocol Error — отдельная категория. Молчание не равно успеху: возможны silent discard, потеря обратного наблюдения или ошибка после decode.

Положительный результат — ожидаемый полный набор TEI Status Indications в заданном временном и интерфейсном контексте.

DLCI присутствует, но не выбирает цель

TEI Query содержит common header и IUA header. RFC 4233 требует от SG игнорировать DLCI в этом сообщении. Наличие поля в общей структуре не даёт ему смысла во всех операциях.

Если аналитика группирует TEI Query по этому DLCI, привязывает к клиенту или считает его адресом цели, она создаёт несуществующую связь. Значение можно сохранить как часть wire image, но нужно отметить как неинтерпретируемое для данного запроса.

После ответа цепочка продолжается. Нужно связать indications с query и интерфейсом, проверить полноту и свежесть, наблюдать Q.921 link, процедуру Establish, сигнализацию и результат приложения. ASSIGNED не перепрыгивает эти этапы.

Опасность совместимого type 5

Старый receiver может отвергнуть type 8. Автоматический повтор с 5 кажется практичным. Но в DUA type 5 означает DLC Status Request. При DUA поверх PPID 1 исчезает и внешняя подсказка. Система может успешно выполнить другой запрос и ошибочно засчитать его как TEI-совместимость.

Legacy-исключение допустимо только для именованного peer в доказанном IUA-only контексте, с telemetry каждого fallback, запретом на DUA/combined, сроком удаления и negative tests. Невидимый shim лишает последнего старого узла стимула обновиться и делает неоднозначность постоянной обязанностью всей сети.

Матрица включает new-new, new-old, old-new, IUA-only, DUA-only, combined и failover. Она должна доказывать не только правильный успех, но и видимый отказ неоднозначного пути до неправильного handler.

Что установлено, а что нет

RFC Editor и Datatracker устанавливают статус, дату и update. RFC 5133 устанавливает коллизию и переход 5→8. RFC 4129 — DLC types и PPID-варианты. RFC 4233 — header, errors, TEI procedure и ASP states. IANA — текущую регистрацию; SCTP RFC — transport.

Источники не устанавливают build конкретного производителя, production trace, личность терминала или service outcome. Эти факты требуют текущих локальных доказательств. Стандарт делает вопрос однозначным; ответ даёт работающая система.

Sources