Кратко

  • H.323 URL помогает разрешить адрес пользователя, устройства или сервиса; user — alias без местоположения, а hostport может указывать на функциональный элемент, но не на конечный исход.
  • Успех lookup не наследует доказательства transport connection, gatekeeper admission, call signaling, media negotiation, recipient identity, application outcome и resource release.

Метрика остановилась на первом удобном успехе. DNS вернул адрес, сервис ответил на соединение, и одна строка стала completed call. Следующие отказы больше не попадали в знаменатель.

RFC 3508 опубликован в апреле 2003 года как Informational RFC. Он воспроизводит H323-URL из H.323 version 4 для доступной ссылки и регистрации IANA и прямо не является Internet Standard.

Регистрация координирует схему

IANA сейчас перечисляет h323 как Permanent URI scheme со ссылкой на RFC 3508. Документ говорит, что регистрация предотвращает дублирование имени схемы.

Это реальное, но узкое утверждение. Оно не показывает установленный обработчик, живой gatekeeper, выделенный alias, доступный endpoint или совершённый звонок.

Registry snapshot нужен для интерпретации префикса. Runtime receipt нужен для каждого действия после него.

Alias не несёт местоположение

Адрес может состоять из user, @hostport или их комбинации. User называет alias пользователя, устройства или сервиса и не содержит location information.

User-only форма требует внешнего контекста: зоны, directory или interworking table. Одинаковый текст может иметь разные назначения в двух областях. Service alias способен вести к пулу.

Binding должен содержать authority, scope, owner, version, freshness и authenticated responder. Финальный IP не сохраняет эти координаты.

Hostport указывает роль, а не человека

Hostport может называть Endpoint, Gatekeeper, Border Element или иной функциональный элемент, куда направляют вызов или запрос сервиса.

Доступный gatekeeper — контрольная точка, а не получатель. Border element — промежуточная роль. DNS связывает имя и адрес, но не доказывает власть процесса над alias.

Сохраняйте ожидаемую роль, selection policy, адрес, peer identity и connection result. Admission и дальнейшие стадии остаются отдельными.

Сравнение предшествует lookup

Host case-insensitive. User — Unicode, кодируется UTF-8 и escape при необходимости. Символы ниже 0x80 в user case-insensitive, выше или равные — case-sensitive.

Общий Unicode lowercase может объединить разные alias. Бинарное сравнение может разделить эквивалентные ASCII-варианты. Percent decoding и нормализация directory создают дополнительные ключи.

Храните received octets, decoded bytes, Unicode, comparison key, algorithm и version. Совпадение по ключу не является удостоверением личности.

Параметры требуют отдельного контракта

RFC допускает параметры после ;, но оставляет конкретные определения для будущей работы. Character set и case sensitivity определяются каждым параметром.

Parser может сохранить неизвестное значение, не понимая его. Посредник может передать его, а endpoint проигнорировать. Точная доставка не доказывает общей семантики.

Receipt включает definition, version, support, unknown policy и observed effect. Синтаксический token не получает routing authority автоматически.

Carrier определяет область безопасности

H.323 URL может переноситься H.225.0, SIP, TRIP, веб-страницей или XML. RFC 3508 относит защиту H.225.0 к H.235, а других carrier — к их протоколам.

Аутентифицированный SIP peer доказывает peer и защищённые поля в заданной trust domain. Он не обязательно владеет H.323 alias. TRIP announcement не является admission. XML integrity не задаёт нормализацию.

Security claim должен называть carrier, identity, protected object, mapping authority и потребившее решение.

Interworking выбирает источник перевода

RFC 4123 разрешает SIP-H.323 IWF переводить адреса через таблицы gatekeeper, SIP registrar или другой базы, LDAP, DNS либо TRIP.

Источники имеют разные scope, owner и freshness. Два IWF могут получить разные корректные по синтаксису результаты. Старый mapping может вести к достижимому, но уже не уполномоченному элементу.

Сохраняйте input, output, source, revision, read time, priority и fallback. Воспроизводимость по старой таблице не делает решение современным.

Admission — самостоятельное решение

После resolution возможны registration и gatekeeper admission. Gatekeeper может быть доступен и отказать из-за policy, capacity или неизвестного alias. Доступность его socket не предсказывает решения.

После admission остаются signaling и capability negotiation. Финальный signaling status не гарантирует media path. Media может не пройти NAT, ключевое согласование или endpoint policy.

Даже текущий поток не доказывает нужную identity и application outcome. Человек может ответить не на тот сервис; приложение может отвергнуть содержимое.

Ресурсы должны быть освобождены

RFC 4123 отдельно требует освобождать call-related resources после завершения в interworking. Это напоминает, что outcome включает не только setup.

Вызов может закончиться для пользователя, но оставить state, allocation или mapping. Teardown status и time принадлежат той же цепочке, но не должны скрываться в setup success.

Показывайте resolved, reachable, admitted, signaled, media established, recipient confirmed, outcome confirmed и released как отдельные состояния.

Цепочка квитанций

Сначала URI, source, carrier, octets, escapes, UTF-8, parsed fields, comparison и parameter definitions. IANA state и specification version дают контекст синтаксиса.

Затем alias directory, binding owner/version/freshness, запросы DNS/TRIP/LDAP/registrar/gatekeeper, выбранная роль и connection. Для IWF — translation source и rule.

Далее registration, admission, final signaling, media addresses/keys/path, recipient identity, authorization, authenticated outcome, teardown и alternate-resolution replay.

Граница доказательства

Статья не указывает на текущий продукт, endpoint, gatekeeper, operator, user, call, incident или deployment. Она не измеряет adoption, interoperability, latency или media quality.

Она не повторяет URL/URN, ipn, Gopher, VEMMI или SIP voicemail. Её область — последовательность после успешного разрешения RFC 3508 и запрет считать ранний результат поздним.

Принципы Heng Lu о минимальной начальной спецификации и running code раскрыты как редакционная оптика. Они поддерживают тонкий общий контракт и evidence executed path, но не измеряют H.323.

Вывод: resolver может безошибочно завершить свою работу в транзакции, которая никогда не получила права стать разговором.

Sources