Кратко

  • RFC 3435 назначала каждой конечной точке одну текущую NotifiedEntity, но это значение определяло лишь адрес команд от шлюза; ответ по-прежнему возвращался источнику конкретной команды.
  • Резервный агент мог изменить указатель, не получив механизма разрешения конфликта, доказательства полной синхронизации или гарантии непрерывного звука. Аудит, очистка, доступность, полномочия и результат оставались разными свидетельствами.

Новый адрес не был полной передачей

Представим шлюз, потерявший основной Call Agent. Резервный агент присылает новую NotifiedEntity, и шлюз узнаёт, куда отправить следующее уведомление. Но из этого не следует, что резерв получил все решения о соединениях, что вернувшийся основной агент не принесёт противоречивое состояние или что медиапоток вообще продолжался.

Эту границу документировала RFC 3435, опубликованная в январе 2003 года. Текстовая версия, карточка RFC Editor, Datatracker, история документа, ссылки и список исправлений подтверждают документ, но не конкретное внедрение.

MGCP отделял интеллект управления вызовом от функций медиашлюза. Заменённая RFC 2705 уже предполагала синхронизацию нескольких агентов, не определяя её. RFC 2805 формулировала общие требования, а RFC 3015 описывала Megaco/H.248, названный в примечании IESG стандартным путём. RFC 3435 имела статус Informational: подробные правила не доказывали всеобщего внедрения.

Узкое значение NotifiedEntity

В конечной точке сохранялось последнее явно полученное значение; если его не было, применялась настроенная величина. Если отсутствовали обе и поле оставалось пустым, что документ настоятельно не советовал, адрес источника последней команды, не являвшейся аудитом, становился новым получателем. Один лишь аудит указатель не менял.

Ответы подчинялись иному правилу: они уходили источнику вызвавшей их команды независимо от текущей уведомляемой сущности. Команды могли приходить из любого источника. Поэтому адрес исходящих команд шлюза, сетевой источник запроса, обратный ответ и полномочия контроллера нельзя было сводить в одно поле. Нормативные слова RFC 2119 и грамматика RFC 2234 уточняли обмен, но не создавали легитимности.

Имя Call Agent могло разрешаться в несколько интерфейсов или машин. Шлюз пробовал альтернативы и не должен был полагаться на порядок DNS. Это улучшало достижимость, но не доказывало, что машины имеют одинаковые таблицы соединений, последовательности событий или правила авторизации. DNS, доступность, логическая идентичность и реплика состояния требовали отдельных квитанций.

Пробел, названный прямо

После повторов, экспоненциальной задержки, альтернативных адресов и пределов T-MAX и T-HIST точка могла стать disconnected. Резервный агент связывался с ней и задавал новое направление. RFC предполагала общение и синхронизацию старого и нового агентов, но прямо говорила: разрешения конфликтов передачи между отдельными Call Agent нет.

AuditEndpoint показывал текущее значение, но не восстанавливал все решения и не определял законного владельца управления. Единственное актуальное поле ещё не означало распределённого согласия о том, как оно появилось.

Узнав об отключении, контроллер мог провести аудит или удалить все соединения. Аудит пытался сверить наблюдаемое состояние; удаление добивалось сходимости разрушением. Успешный RestartInProgress не доказывал слышимого непрерывного разговора. RFC 3661 уточнила коды возврата, не превратив их в свидетельство пользовательского результата.

RFC 3991 добавила пакет перенаправления и сброса, RFC 3992 — ограниченный режим lockstep. Реестры IANA для пакетов MGCP и LocalConnectionOptions подтверждают согласованный словарь, а не правильную работу.

Сохранившаяся граница

Позднейшая идея Heng Lu о слоях реальности помогает не приписывать видимому указателю отсутствующие полномочия. Приоритет работающего кода разделяет проект и результат, а минимальная исходная спецификация объясняет, почему общий минимум может согласовать адрес, оставив арбитраж за пределами протокола. Это ретроспективное редакционное применение, а не утверждение о намерении авторов RFC.

Указатель был необходим для следующей команды. Для непрерывности всё ещё требовались полномочия, синхронизация, правило конфликта и наблюдение медиапотока.

Источники