요약

  • RFC 3435는 모든 엔드포인트에 하나의 현재NotifiedEntity를 할당했지만, 이 값은 게이트웨이가 발신하는 명령의 목적지를 정하는 것이었을 뿐입니다. 응답은 여전히 각 명령의 발신지를 따랐고, 명령은 다른 발신지에서 올 수도 있었습니다.
  • 백업 인계는 라우팅 연관 관계를 바꿨지만, Call Agent 간 충돌 해결, 완전한 상태 이전, 끊김 없는 미디어에 대한 증명은 제공하지 않았습니다. 감사, 해제, 도달 가능성, 권한, 사용자 결과는 서로 별개의 수신 증표로 남았습니다.

하나의 포인터, 여러 종류의 진실

컨트롤러가 응답을 멈춘 가상의 액세스 게이트웨이를 생각해 봅시다. 백업이 엔드포인트에 도달해 새로운NotifiedEntity를 전달합니다. 이제 게이트웨이는 다음 알림을 어디로 보낼지 알게 됩니다. 이는 유용합니다. 그러나 완료된 인계보다는 훨씬 부족한 것입니다.

백업은 실패한 컨트롤러가 내린 모든 연결 결정을 알지 못할 수 있습니다. 기존 컨트롤러는 다른 시각을 가진 채 복구될 수 있습니다. 새로 도착한 명령의 응답은 그 명령의 네트워크 발신지로 돌아갈 수 있으며, 게이트웨이 발신 명령은 다른 곳을 향해 있을 수 있습니다. 미디어는 여전히 흐르고 있을 수도, 이미 끊겼을 수도, 곧 해제될 수도 있습니다. 라우팅 포인터는 한 가지 질문에 답하면서 나머지를 열어 둔 채로 둡니다.

이 경계는RFC 3435, 즉 2003년 1월에 나온 Media Gateway Control Protocol 1.0 개정판 내부에 있습니다.일반 텍스트판,RFC Editor 기록,Datatracker 페이지,문서 이력,참조 그래프,정오표 기록이 문서적 기록을 확립합니다. 그러나 이들만으로는 특정 네트워크가 이 메커니즘을 구현했거나 측정 가능한 장애를 견뎠다는 증거가 되지 못합니다.

분해된 게이트웨이를 위한 프로토콜

MGCP는 시스템을 분리했습니다. Call Agent가 통화 제어 지능을 담당했고, 미디어 게이트웨이는 미디어 기능을 처리하며 엔드포인트를 노출했습니다. 컨트롤러는 연결을 요청하고, 매개변수를 수정하고, 삭제하며, 엔드포인트에 이벤트 관찰, 신호 생성, 서비스 변경 보고를 요구할 수 있었습니다. 감사 명령으로 엔드포인트와 연결 상태를 점검할 수도 있었습니다.

RFC 3435가 폐기한RFC 2705는 이미 이 마스터-게이트웨이 구조를 기술하며 Call Agent들이 서로 동기화할 것으로 가정했습니다. 다만 그 동기화를 정의하지는 않았습니다.RFC 2805는 보증, 복구, 조정을 포함한 미디어 게이트웨이 제어에 대한 더 넓은 IETF 요구사항을 기록했습니다.RFC 3015는 RFC 3435의 IESG 노트가 구현자에게 고려하도록 지시한 Megaco/H.248 표준 트랙 아키텍처를 문서화했습니다.

이 인접 문서들이 중요한 이유는 RFC 3435가 Informational 문서였기 때문입니다. 그 상세 요구사항은 해당 프로토콜에 대해 유효하지만, IETF 표준 지위, 보편적 배포, 성공적인 통화의 증거는 아닙니다. 따라서 본 글은 프로토콜 용어를 시장 역사로 바꾸지 않고 하나의 내부 제어 표면만을 따릅니다.

Notified 주체가 실제로 한 일

RFC 3435에 따르면 각 엔드포인트에는 주어진 시점에 정확히 하나의 Call Agent가 연관됩니다. notified 주체의 현재 값은 그 연관을 나타내며 게이트웨이가 명령을 보내는 곳을 결정합니다. Call Agent가 전달한NotifiedEntity매개변수는 엔드포인트의 저장된 값을 변경합니다.

명시적 값이 한 번도 도착하지 않았다면 프로비저닝된 기본값이 적용됩니다. 값이 비어 있고 기본값도 없다면—RFC가 강하게 권장하지 않는 구성—마지막 비감사(non-audit) 명령의 발신 주소가 목적지가 됩니다. 감사 트래픽만으로는 이 포인터를 은밀히 탈취할 수 없습니다.

이 정밀성이 중요합니다. notified 주체는 게이트웨이 발신 프로토콜 트래픽의 주소 지정 가능한 수신자입니다. 암호학적 권한 증서가 아닙니다. 완전한 통화 상태 장부가 아닙니다. DNS 이름 뒤의 모든 플랫폼이 현재 메모리를 공유한다는 증거가 아닙니다. 패킷이 미디어 평면을 통과했다는 증거도 아닙니다.

응답은 다른 곳으로 갈 수 있었다

응답에는 다른 규칙이 적용됩니다. RFC 3435는 현재 notified 주체와 무관하게, 명령을 유발한 발신 주소로 응답을 보냅니다. 그 응답에 piggyback된 Notify도 같은 데이터그램 목적지를 따릅니다. 다른 부분에서 RFC는 게이트웨이가 수신하는 명령이 어떤 발신지에서든 올 수 있다고 말합니다.

이로써 로그가 평탄화해서는 안 되는 세 가지 사실이 생깁니다. 첫째, 엔드포인트에는 자체 명령의 현재 목적지가 있습니다. 둘째, 특정 명령은 특정 발신지에서 도착했습니다. 셋째, 게이트웨이는 그 발신지로 응답을 돌려보냈습니다. 이 중 어느 것 하나만으로도 그 발신지가 유일하게 권한 있는 컨트롤러였거나, 경쟁하는 Call Agent들이 전환에 대해 합의했다는 증명은 되지 않습니다.

RFC 2119의 요구사항 어휘와RFC 2234의 문법 규약은 메시지 동작을 정밀하게 만듭니다. 그러나 와이어 수준의 정밀성이 결여된 제도적·분산 상태 증거를 만들어내지는 못합니다.

DNS는 도달 가능성을 제공했지 공유 메모리를 제공하지 않았다

Call Agent는 고정된 네트워크 주소가 아니라 도메인 이름과 선택적 포트로 지정되었습니다. 하나의 이름이 여러 인터페이스 또는 논리적 컨트롤러로 동작하는 여러 물리 시스템으로 해석될 수 있었습니다. 게이트웨이는 현재 요청에 이미 연관된 주소를 우선하고, 접촉 실패 시 대안을 시도해야 했습니다. 페일오버는 DNS 응답 순서에 의존해서는 안 되었습니다.

이것은 실용적인 간접 계층이었습니다. 안정적인 논리적 이름이 인터페이스 변경을 넘어 유지되고 게이트웨이가 대체 주소를 탐색할 수 있게 했습니다. 그러나 두 주소로의 해석이 성공했다는 것은 그 기계들이 동일한 연결 기록을 보유하고, 같은 알림 순서를 봤거나, 같은 권한 정책을 적용한다는 것을 보여주지 못합니다. DNS는 패킷을 어디로 보낼 수 있는지 말할 뿐이며, 상태 복제에는 그 자체의 수신 증표가 필요합니다.

빠져 있던 인계 중재자

Call Agent 전체가 도달 불가능해지면 영향을 받은 엔드포인트는 결국 연결 해제(disconnected) 상태가 됩니다. 백업 Call Agent가 새 notified 주체로 접촉할 수 있었습니다. RFC 3435는 제어를 반환할 때 실패한 컨트롤러와 백업 컨트롤러가 통신·동기화하거나 주/백업 역할을 교환할 것이라고 가정했습니다.

그러고 나서 이 문서는 감추지 않은 한계를 명시했습니다. 별개의 Call Agent 간 인계를 위한 충돌 해결은 마련되어 있지 않다는 것입니다. 프로토콜은 컨트롤러들이 자신이 하는 일을 알고 서로 통신한다는 데 의존했습니다.AuditEndpoint는 현재 notified 주체를 공개할 수 있었지만, 현재 포인터의 조회만으로는 과거의 모든 결정을 재구성하거나 어느 컨트롤러가 정당한 권리를 주장하는지 판단할 수 없었습니다.

이 구분이 본 글의 역사적 중심입니다. 시스템은 그 필드가 어떻게 바뀌었는지에 대한 분산 합의 없이도 단일 현재 필드를 가질 수 있습니다. “마지막으로 저장된 값”은 관찰입니다. “정당한 컨트롤러”는 권한에 대한 결론입니다. “같은 통화가 살아남았다”는 운영 결과입니다. RFC 3435는 이 문장들이 동의어라고 가장하지 않았습니다.

연결 해제는 판정이 아니라 선택을 만들었다

MGCP는 데이터그램 한 개의 손실만으로 엔드포인트를 연결 해제로 선언하지 않았습니다. 재전송, 지수 백오프, 대체 주소, DNS 갱신, 유한한 타이머를 사용했습니다. T-MAX가 재전송을 제한했고, T-HIST의 두 배를 넘으면 엔드포인트는 disconnected 상태로 들어갔습니다. 무작위화된 지연은 많은 엔드포인트가 동시에 복구를 알리는 위험을 줄였습니다.

연결 해제 이후 첫 비감사 교환은 disconnected 사실을 전달해야 했습니다. Call Agent가 이를 학습하면, RFC는 컨트롤러가 할 수 있는 일의 예를 제시했습니다. 엔드포인트를 감사하거나, 모든 연결을 해제(clear)하는 것입니다. 이 두 행동은 동등하지 않았습니다. 감사는 프로토콜에서 볼 수 있는 상태로부터 조정을 시도했습니다. 해제는 파괴를 통한 수렴을 선택했습니다.

어느 경로도 미디어가 계속되었다는 것을 보장하지 않았습니다. 성공적인 RestartInProgress 교환은 프로토콜 트랜잭션이 완료됐다는 것을 증명할 뿐입니다. 활성 통화가 들렸는지, 상태가 사라지지 않았는지, 가입자가 중단을 겪지 않았는지는 증명하지 못합니다. 이후RFC 3661이 반환 코드 사용을 명확히 했지만, 더 잘 정의된 결과 코드조차 그 결과 코드의 범위를 넘지 못합니다.

이후의 패키지들이 특정 간격을 좁혔다

RFC 3991은 MGCP 리디렉션 및 리셋 패키지를 정의했습니다.RFC 3992는 유한한 클래스의 알림 상호작용에 대해 lockstep 상태 보고를 정의했습니다. 이들은 운영자와 설계자가 리디렉션과 상태를 둘러싼 더 명시적인 메커니즘을 필요로 했음을 보여줍니다. 그러나 이들이 기본 notified 주체 필드를 소급하여 컨트롤러 선출 또는 복제 상태 프로토콜로 바꾸지는 못했습니다.

IANA MGCP 패키지 레지스트리와LocalConnectionOptions 레지스트리는 이 프로토콜의 할당된 어휘를 보존합니다. 등록은 조율된 이름과 참조를 보여줄 뿐, 실행 중인 구현이나 올바른 동기화, 서비스 연속성을 증명하지 않습니다.

오래 남는 교훈

RFC 3435가 가치 있는 이유는 페일오버라는 단어 뒤에 얼마나 많은 계층이 숨어 있는지 드러내기 때문입니다. 목적지는 바뀔 수 있습니다. 대체 주소는 응답할 수 있습니다. 컨트롤러는 disconnected 통지를 받을 수 있습니다. 감사는 상태를 돌려줄 수 있습니다. 해제 명령은 성공할 수 있습니다. 그래도 미디어는 실패할 수 있고, 두 컨트롤러는 여전히 불일치할 수 있습니다.

Lu Heng의 이후 저작인reality layers는 유용한 분석 규율을 제공합니다. 눈에 보이는 포인터가 그 안에 담겨 있지 않은 증거로부터 권위를 빌려오지 말라는 것입니다. 그의running-code primacy논지는 운영 수신 증표를 표준 설계와 분리해 둡니다.minimum-initial-specification관점은 왜 유한한 포인터가 행동을 조율하면서도 미래의 충돌 해결을 공통 코어 바깥에 둘 수 있는지를 설명합니다. 이들은 소급적인 편집 적용이며, RFC 저자들의 의도에 대한 주장이 아닙니다.

notified 주체는 게이트웨이가 다음 명령을 보낼 곳이 필요했기 때문에 필수였습니다. 그러나 연속성에는 주소 이상의 것이 필요했기 때문에 불충분했습니다. 프로토콜은 그 구분을 텍스트에 보존했습니다. 역사도 그 구분을 보존해야 합니다.

출처