요약

  • RFC 3015는Context를 위상(topology), 모드, 명령 및 범위 지정 식별자를 갖춘 미디어 게이트웨이의Termination로컬 연관으로 모델링했습니다. 이 명세는 그 객체를 보편적인 통화 기록으로 정의하지 않았습니다.
  • 트랜잭션 순서, 감사 및 최대 1회(at-most-once) 재시도 메모리는 더 좁은 실행 사실들을 확립했습니다. 이 중 어느 것도 외부 경로 전달, 원격 재생 또는 두 사람이 실제로 통신했다는 사실을 입증하지 않았습니다.

컨트롤러가 게이트웨이에 RTP 스트림을 회선과 연관시키도록 요청하는 장면을 상상해 보십시오. 게이트웨이는Add를 수락하고, 새 로컬 객체에 식별자를 할당하고, 성공을 반환합니다. 운영 화면에서는 이제 Context가 “연결됨”으로 표시됩니다. 그 문장의 모든 단어가 참일 수 있으면서도, 원격 상대방은 무음을 듣고 있을 수 있습니다.

이 간극은 이름의 결함이 아닙니다. 이것이 RFC 3015가 보이게 만든 경계입니다. 2000년 11월 Megaco Protocol Version 1.0으로 발표되어 ITU-T H.248과 공통 텍스트로 발행된 이 명세는 물리적으로 분해된 멀티미디어 게이트웨이 중 미디어 연결 제어에 속하는 부분을 다루었습니다. 그것은 제어 프로토콜을 게이트웨이 바깥의 모든 네트워크, 엔드포인트, 인간 이벤트의 증인으로 만들지 않았습니다.

객체는 하나의 게이트웨이 안에서 존재했습니다

연결 모델은 두 가지 추상화에서 시작했습니다.Termination은 하나 이상의 미디어 또는 제어 스트림을 송출하거나 수용했습니다.Context는 Termination들을 연관시키고 그 위상—who가 누구를 들거나 보았는지— 및 더 큰 그룹의 경우 믹싱 또는 스위칭 동작을 기술했습니다.

이 어휘는 의도적으로 로컬이었습니다. 미디어 게이트웨이가 각 ContextID를 할당했고, 그 값은 해당 게이트웨이 내에서만 고유했습니다. Context는 2자 통화의 일부, 회의 구성, 대기 통화 또는 다른 미디어 연관을 나타낼 수 있었습니다. 그것은 “그 통화”, 가입자, 과금 이벤트 또는 인간 교류에 대한 전역적이고 지속적인 식별자가 아니었습니다.

수명(lifetime) 구분은 이 차이를 구체적으로 만들었습니다. 프로비저닝된 회선 채널과 같은 물리적 Termination은 오랫동안 존재할 수 있었습니다. RTP 흐름의 표현과 같은 임시(ephemeral) Termination은 보통 사용 기간에만 존재했습니다. 널(null) Context는 다른 Termination과 연관되지 않은 물리적 Termination을 보유했습니다.Add는 활성 Context를 암묵적으로 생성할 수 있었고,Subtract는 물리적 Termination을 널 Context로 되돌리거나 임시 Termination을 소멸시킬 수 있었으며,Move는 Termination을 옮길 수 있었습니다. 마지막 Termination이 떠나면 Context는 자동으로 사라졌습니다.

로컬 명령의 결과로 나타나고 사라지는 기록은 가치 있는 운영 상태입니다. 그것은 서비스에 일어난 모든 일의 영구 기록이 아닙니다.

위상과 경계 모드는 서로 다른 질문에 답했습니다

RFC 3015는 Context 내부의 위상과 Termination의 모드를 구분했습니다. 위상은 Termination들 사이의 미디어 관계, 즉 MG가 보유한 객체들 사이의 양방향, 단방향 또는 고립된 경로를 기술했습니다. 모드는 게이트웨이의 인그레스 또는 이그레스에서의 흐름을 기술했습니다.

이것이 중요한 이유는 게이트웨이 모델에서 “T1이 T2를 들을 수 있다”는 원격 청취자의 마이크 보고가 아니라 프로그래밍된 연관이기 때문입니다. 게이트웨이는 이후 패킷이 폐기되거나, 잘못된 원격 소켓으로 전달되거나, 거부되거나, 잘못 디코딩되거나, 음소거되거나, 전혀 재생되지 않는 상황에서도 인커밍 회선을 아웃고잉 패킷 스트림으로 올바르게 스위칭할 수 있습니다. 반대로 감사는 그 구간 동안 어떤 외부 패킷이 도착했는지를 재구성하지 않고 로컬 모드만 관찰할 수 있습니다.

따라서 Context는 하나의 실재 계층, 즉 하나의 제어 대상 장치에서 실현된 연결 상태를 차지했습니다. 세션 기술, 전송 주소, RTP 시퀀스 및 수신 증거, 엔드포인트 재생, 인간의 이해는 서로 다른 관리자가 있는 이후 계층에 속했습니다.

트랜잭션은 대화 전체가 아니었습니다

명령은 Action 안에 중첩되었고, Action은 Transaction 안에 중첩되었습니다. 하나의 Action은 보통 하나의 Context를 대상으로 했습니다. 같은 트랜잭션 안의 명령은 순서대로 실행되었습니다. 이를 통해 컨트롤러는 일관된 로컬 변경을 요청하고, 성공한 명령의 결과 또는 처리 실패 지점의 오류를 받을 수 있었습니다.

그러나 서로 다른 트랜잭션 사이에서 순서는 자동으로 보장되지 않았습니다. 명세는 일관된 운영을 원하는 컨트롤러에게 규율을 강제하도록 지시했습니다. 하나의 Termination에 대해서는 명령들이 같은 트랜잭션을 공유하지 않는 한, 보통 최대 하나의 미결Add,Modify또는Move만 있어야 했습니다.Subtract는 끼어들 수 있었습니다. 와일드카드 제거는 미결 추가보다 먼저 진행될 수 있어, 컨트롤러는 잔존 항목을 정리하고 제거가 확인될 때까지 새 추가를 지연해야 했습니다.

본질적인 소유 구조는 명확했습니다. MG가 명령을 실행했고, MGC가 의도의 순서를 소유했습니다. 성공한 응답은 게이트웨이가 해당 트랜잭션에 대해 보고한 내용을 확립했습니다. 그것은 두 번째 컨트롤러가 같은 원하는 상태를 공유했음을, 또는 이후 트랜잭션이 그 연관을 보존할 것임을 증명하지 않았습니다.

TransactionPending은 더 좁았습니다. 그것은 처리가 여전히 활성 상태이며 미완료임을 말했습니다. 요청자의 타이머를 재시작했지만, 성공을 예측하거나 종단 간 경로를 예약하거나 미디어 흐름을 증명하지 않았습니다.

감사는 시간을 고정시키지 않았습니다

Megaco는 유용하지만 서로 다른 두 가지 질의를 제공했습니다.AuditValue는 현재 속성, 이벤트, 신호 및 통계 값을 반환했습니다.AuditCapabilities는 가능한 값을 반환했습니다. 가능성(capability)은 현재 상태가 아니었고, 현재 상태는 결과가 아니었습니다.

와일드카드는 또 하나의 한계를 더했습니다. 응답은 일치하는 Termination들에 걸친 합집합(union)을 담을 수 있었습니다. 이는 트래픽을 줄였지만, 합집합은 어느 멤버가 어느 가능한 값을 제공했는지 보여주지 않았습니다. 답변은 요청된 범위에 대한 증거로 남았고, 객체별 전체 이력이 아니었습니다.

가장 중요한 것은, RFC 3015가AuditValue와AuditCapabilities는 명령 순서화의 대상이 아니라고 명시했다는 점입니다. 변경 작업이 진행 중일 때 수행된 감사에는 시간과 순서 맥락이 필요했습니다. 한 값은 MG가 관찰한 순간에는 정확할 수 있지만 컨트롤러의 다음 결정과 비교하면 낡았을(stale) 수 있습니다. 응답을 “현재”라고 부른다고 해서 그것이 모든 관련 트랜잭션의 선형화된 스냅샷이 되지는 않았습니다.

Subtract는 Termination이 Context에 참여한 동안 수집된 통계를 제공했습니다. 그 수치들은 연관이 사라지기 전 로컬 사용을 재구성하는 데 도움이 될 수 있었습니다. 그러나 그것들은 여전히 게이트웨이 측에서 보고한 것이었습니다. 거기서의 바이트 또는 패킷 수는 원격 수신, 이해 가능한 재생 또는 완성된 인간 교류를 확립하지 못했습니다.

최대 1회 처리는 명령 경계를 보호했습니다

UDP는 요청이나 응답을 잃을 수 있었습니다. 많은 Megaco 명령은 멱등(idempotent)하지 않았기 때문에 보호 없이 대부분의 명령을 반복하는 것은 안전하지 않았습니다.Add를 두 번 실행하면 게이트웨이 상태가 예측 불가능해질 수 있었습니다. 따라서 RFC 3015는 최대 1회(at-most-once) 동작을 요구했습니다.

피어들은 최근 응답과 현재 실행 중인 트랜잭션을 보유했습니다. 그들은 송신자 식별자로 범위가 지정된 트랜잭션 식별자를 그 메모리와 비교했습니다. 완료된 중복은 기억된 응답을 받았고, 진행 중인 중복은 다시 실행되지 않으며TransactionPending을 받을 수 있었습니다. 응답 확인(acknowledgement)은 저장된 응답을 해제하도록 허용했고, 식별자는 지연된 중복을 폐기하기에 충분히 오래 유지되었습니다.

이 보장에는 명시된 관리(custody) 경계가 있었습니다. 그것은 보존된 메모리, 식별자 고유성, LONG-TIMER 및 현재 운영 에포크(epoch)에 의존했습니다. 만료 또는 재시작 이후에는 옛 증거가 영원히 말하지 않았습니다. 완벽하게 작동할 때조차, 최대 1회는 “이 게이트웨이 트랜잭션이 프로토콜의 비교 창 내에서 재실행되지 않았다”는 뜻이었습니다. “그 통화가 정확히 한 번 일어났다”는 뜻이 아니었습니다.

TCP는 이 구분을 폐지하지 않았습니다. RFC 3015는 장애 전후에서 트랜잭션 요청이나 응답이 여전히 손실될 수 있다고 언급하며 애플리케이션 수준 처리를 권고했습니다. 신뢰할 수 있는 바이트 스트림은 명령을 운반할 수 있었지만, 게이트웨이가 잃어버린 프로세스 메모리를 보존하거나 다운스트림 미디어를 인증할 수는 없었습니다.

보안은 결과가 아니라 권한을 지켰습니다

무단 Megaco 명령은 통화를 설정하거나 방해할 수 있었기 때문에, RFC는 IP 환경에서 제어 연결의 보호를 요구하고 IPsec을 명시했습니다. 발신 인증, 무결성, 안티 리플레이 및 기밀성은 지시 채널을 보호했습니다. 그러나 그것들이 컨트롤러를 원격 청취자로 변환하거나, 인증된 요청을 서비스가 작동했다는 증명으로 만들지는 않았습니다.

표준의 역사도 이 제한된 주장을 뒷받침합니다. RFC 3015는 RFC 2805의 아키텍처 요구사항을 충족했고 이후 RFC 3525로 대체(obsolete)되었습니다. RFC 3435는 MGCP를 별도의 Informational 계열로 두고 Megaco/H.248을 표준 기반 접근으로 지목했습니다. 이 기록들은 프로토콜 계열을 설명합니다. 그러나 어떤 제품이 어떤 판을 배치했는지, 두 벤더가 상호 운용했는지, 몇 통의 통화가 성공했는지는 알려주지 않습니다.

지속적인 성과는 “연결됨” 배지보다 더 정확했습니다. Megaco는 제어 소프트웨어에 로컬 연관을 명명하고, 프로그래밍하고, 검사하고, 트랜잭션 내에서 변경을 순서화하고, 중복 명령을 억제하는 공통 방법을 제공했습니다. 또한 더 큰 주장을 저항할 수 있을 만큼 경계를 남겨 두었습니다. Context는 통화를 입증하지 않은 채 연결되어 있을 수 있었습니다.

출처