요약

  • RFC 3054는 IP 전화기를 간단한 Megaco 미디어 게이트웨이로 묘사했다. 잘 알려진 Termination 이름과 최소 프로필 덕분에 미디어 게이트웨이 컨트롤러(MGC)가 패키지(Package)만으로 기능을 추론하지 않고도 전화기의 의도된 구성을 이해할 수 있었다.
  • IPPhone 프로필을 선언하고 수락하는 것만으로는 전화기의 선택적 기능, 현재 물리적 상태, 논리적 컨텍스트, RTP 경로, 디코딩된 오디오 또는 사용자 경험을 입증하지 못했다. 이들은 별개의 증빙으로 남았다.

2001년 1월, 인터넷 전화기는 서로 보완적인 두 가지 방식으로 상상될 수 있었다. 피어 지향 시스템처럼 단말에 더 많은 호출 지능을 담는 방식. 또는 원격 컨트롤러의 지휘 아래 비교적 단순한 기기로 동작하는 방식이었다.

RFC 3054는 두 번째 가능성을 발전시켰다. 전화기 자체가 미디어 게이트웨이가 되었다. 미디어 게이트웨이 컨트롤러(MGC)가 대부분의 애플리케이션 지능을 보유했다. 전화기는 사용자 인터페이스, 핸드셋, 핸즈프리 장치, 헤드셋, RTP 스트림 같은 논리적 구성 요소를 노출했고, 컨트롤러는 Megaco/H.248을 통해 이를 발견하고 조작할 수 있었다.

이 문서는 Informational이었으며 인터넷 표준이 아니었다. 배치 사례나 성공적인 호출을 보고하지도 않았다. 그 역사적 중요성은 다른 곳에 있다. 프로필이 서로 다른 기기들 사이의 사전 합의를 압축하면서도, 실제로 무엇이 존재하는지 묻고 실제로 무엇이 일어나는지 관찰할 필요를 없애지 않는 방식을 보여주었다는 점이다.

전화기는 책상 끝의 게이트웨이였다

미디어 게이트웨이 제어는 여러 회선을 종단하고 네트워크 유형 사이에 놓이는 장비를 중심으로 설명되곤 했다. RFC 3054는 같은 모델을 개별 전화기에 적용했다. 사용자 책상 위의 기기가 미디어 게이트웨이였고, 오디오 입력, 오디오 출력, 제어 장치를 직접 구현했다. 하나의 MGC는 이 프레임워크에서 여러 대의 그러한 전화기 게이트웨이를 제어할 수 있었다.

이 배치는 분업을 유난히 잘 드러냈다. 단말은 미디어와 사용자 인터페이스 동작을 수행했다. 컨트롤러는 그 구성 요소들이 호출에 어떻게 참여할지를 결정했다. 키 입력은 Notify가 전달하는 이벤트(Event)가 되었다. 디스플레이나 표시등은 시그널(Signal)에 반응했다. 컨트롤러는 컨텍스트에 핸드셋을 추가하거나, 핸즈프리 변환 장치를 옮기거나, 오디오 요소 집합을 제거할 수 있었다.

그러나 그 어떤 동사도 호출 그 자체는 아니었다. Notify 메시지는 키 이벤트를 정확히 보고하면서도 애플리케이션이 의도한 결정을 내렸다는 것을 입증하지 않았다. Modify 명령은 수락되었지만 램프가 켜졌음을 증명하지 않았다. 컨텍스트에 RTP Termination과 핸드셋이 담겨 있더라도 네트워크 경로, 디코더, 증폭기 또는 물리적 변환 장치가 여전히 실패할 수 있었다.

이 아키텍처는 책임을 분리함으로써 단순성을 얻었다. 동시에 증빙이 그 증빙을 만들어낸 행위자에게 붙어 있도록 요구했다.

이름은 패키지가 담지 못한 의미를 실었다

프로필은ui라는 이름을 가진 사용자 인터페이스 Termination을 정확히 하나 요구했다. 또한 핸드셋, 핸즈프리, 헤드셋, 마이크 또는 스피커를 식별할 수 있는 이름을 가진 오디오 변환 장치 Termination을 최소 하나 요구했다. 핸드셋은at/hs로, 핸즈프리 요소는at/hf로 나타났고,at/*같은 와일드카드는 오디오 그룹 전체를 지정했다.

이들은 장식적 라벨이 아니었다. 두 물리적 요소가 동일한 패키지를 지원하면서도 전화기를 쥔 사람에게는 전혀 다른 의미를 가질 수 있었다. 일반적인 기능만 보는 컨트롤러는 이어피스와 방 전용 스피커를 구별하기 어려웠다. 잘 알려진 이름은 모든 종류의 변환 장치마다 별도의 패키지를 요구하지 않으면서 의도된 인간적 의미를 전달했다.

이름 붙이기는 발견과 묶음 동작도 효율적으로 만들었다. MGC는 와일드카드로 모든 오디오 Termination을 감사하거나 한 컨텍스트에서 함께 제거할 수 있었다. 임의의 집합을 검사하고 각각의 기능을 기능 목록에서 추론할 필요가 없었다.

그러나 식별자는 논리 모델 안의 서술에 머물렀다. 구현은 각 물리적 요소를 따로 노출할 수도 있고, 여러 실제 입력과 출력을 하나의 논리적 Termination 뒤에 숨기고 로컬에서 그중 하나를 선택할 수도 있었다. 따라서at/hs라는 이름은 프로토콜 객체의 의미를 입증할 뿐, 장치 배선의 완전한 목록을 입증하지 않았다. 핸드셋이 연결되어 있고, 건강하며, 선택되어 있고, 들리는지는 증명하지 않았다.

프로필은 상당 부분의 추론을 사전 합의로 대체했다

기동 또는 서비스 변경 시 전화기는 MGC에 프로필 이름IPPhone, 버전 1을 알렸다. 이 선언에는 큰 기대 묶음이 실려 있었다.ui객체 하나, 이름 붙은 오디오 변환 장치 구성, 최소 하나의 오디오 변환 장치, 최소 하나의 RTP Termination, 필수 텍스트 인코딩, 필수 제어 전송 지원.

이것이 프로필의 경제성이었다. 컨트롤러가 이름을 인식하면 더 이상 빈 이론에서 장치를 다루지 않았다. 공통의 구성과 동작은 가정할 수 있었다. 컨트롤러가 발견해야 하는 것은 중요한 변형뿐이었다.

그래도 교환에는 결정이 담겨 있었다. MGC는 제어를 수락하거나, 전화기를 다른 컨트롤러로 재지향하거나, 거부할 수 있었다. 전화기가 “나는 IPPhone 버전 1을 사용한다”고 말하는 것은 컨트롤러가 책임을 맡았다는 증거가 아니었다. 수락이 이루어지면 양쪽은 프로필에 구속되었고, 그 규칙 밖의 프로토콜 사용은 오류가 되었다.

수락된 사전 합의에도 경계가 있었다. 그것은 최소 형태와 동작을 기술할 뿐, 제조사의 구현, 특정 부팅, 현재 상태 또는 물리적 출력을 인증하지 않았다. 공유된 문법은 질문의 비용을 줄였지만 모든 운영상 질문에 답하지 않았다.

선택성이 곧 상품이었기 때문에 감사는 여전히 필요했다

컨트롤러는 AuditValue를 사용해 실제 논리적 목록과 지원되는 패키지를 조회했다. 전화기 전체에 대한 와일드카드 감사는 사용자 인터페이스 Termination과 이용 가능한 오디오 Termination을 돌려줄 수 있었다. 추가 감사는ui, 특정 변환 장치 또는at/*전체에 걸친 패키지를 검사할 수 있었다.

이 단계가 중요한 이유는 RFC 3054가 사용자 인터페이스를 의도적으로 열어 두었기 때문이다. 텍스트 디스플레이, 키패드, 기능 키, 표시등, 소프트키, 보조 입력은 모두 선택 사항이었다. 덕분에 같은 프로필이 핸드셋과 훅스위치를 가진 로비 전화기, 작은 회의용 기기, 기능이 풍부한 사무용 전화기를 모두 기술할 수 있었다.

따라서 부재가 자동으로 실패를 뜻하지는 않았다. 디스플레이가 없는 전화기도 규격에 부합할 수 있었다. 존재가 자동으로 준비됨을 뜻하지도 않았다. 감사가 디스플레이 패키지를 보고하더라도 화면은 손상되었거나, 로컬에서 비활성화되었거나, 특정 지시를 렌더링하지 못할 수 있었다.

프로필은 변동을 위한 통제된 공간을 만들었다. AuditValue는 그 공간 안의 논리적 주장을 밝혔다. 어느 쪽도 요청된 동작과 그 물리적 결과를 시험하는 대체물이 아니었다.

최소 코어는 확장을 가능하게 했고, 동시에 계승 문제를 낳았다

RFC 3054는 자신이 최소 설계를 정의한다고 분명히 밝혔다. 구현자는 Termination 유형, 패키지, 전송, 인코딩 또는 내장 지능을 추가할 수 있었다. 이 균형은 두 목표를 함께 섬겼다. 컨트롤러에 신뢰할 수 있는 공통 기준선을 주고, 제품 차별화의 여지를 남기는 것이다.

같은 유연성이 수명 주기의 질문을 만들었다. 선택적 추가 요소는 컨트롤러와 전화기가 그것을 일관되게 식별하고 해석할 수 있을 때만 유용했다. 독점 패키지나 로컬 동작은 한 시스템을 개선하면서 그 MGC나 단말의 교체를 더 어렵게 만들 수 있었다. 애플리케이션 지능이 컨트롤러에 많이 살수록 전화기는 그 컨트롤러가 자신의 프로필과 확장을 계속 이해하는 데 더 의존했다.

중앙화된 모델은 단말의 복잡도와 비용을 낮출 수 있었다. 동시에 결정 권한을 집중시킬 수도 있었다. MGC가 컨텍스트 구성을 선택하고, 표시등과 디스플레이를 구동하고, 사용자 이벤트에 응답했다. 컨트롤러의 장애, 낡은 목록 또는 호환되지 않는 확장은 단순히 관리 대시보드를 없애는 정도가 아니었다. 그 외에는 정상 동작하는 수많은 기기의 기능 로직을 제거할 수 있었다.

최소 사양은 초기 상호운용성 부담을 줄였다. 그러나 확장 거버넌스, 버전 규율, 폴백, 그리고 탈출 경로의 필요를 없애지는 않았다.

제어 전송과 미디어 전송은 서로 다른 시스템이었다

IPPhone 프로필은 Megaco 제어를 위한 UDP 상의 애플리케이션 계층 프레이밍(ALF)을 요구했고 ABNF 텍스트 인코딩을 요구했다. TCP와 ASN.1 바이너리 인코딩은 기본 프로토콜에 따라 구현될 때 선택적 대안이었다.

이 요구 사항들은 컨트롤러와 전화기가 명령을 주고받는 방식을 기술했다. 오디오는 RTP Termination을 통해 흘렀다. 이 구분은 근본적이다. 신뢰할 수 있거나 인증된 제어 교환이 논리적 미디어 경로를 구성하는 동안 RTP 패킷은 도착하지 않을 수 있었다. RTP는 한 방향으로 도착하면서 복귀 오디오가 실패할 수 있었다. 패킷이 전화기에 도착했는데도 디코딩에 실패할 수 있었다. 디코딩된 샘플이 존재하면서도 선택된 변환 장치가 침묵할 수 있었다.

프로필은 RTP 스트림을 표현하는 데 필요한 객체를 요구했다. 그러나 패킷 트레이스를 발행하지는 않았다. 이후의 RTP와 전화 이벤트 사양은 미디어 경계를 이해하는 데 도움을 주며, 이후의 H.248 문서들이 게이트웨이 제어의 진화를 설명하는 것과 같다. 이후의 모든 메커니즘을 특정 RFC 3054 전화기가 구현했거나 성공적으로 수행했다는 역방향 증거로 읽을 수는 없다.

보안은 컨트롤러의 손길을 그대로 물려받았다

RFC 3054는 애플리케이션 프로필이 Megaco/H.248에 고유한 문제 이외의 새로운 보안 문제를 더하지 않는다고 밝혔다. 이 문장은 신규성의 범위를 정했을 뿐, 지킬 것이 없다는 뜻이 아니었다.

컨트롤러는 오디오 경로, 디스플레이, 표시등, 키에 대한 응답에 영향을 줄 수 있었다. 따라서 정당한 제어 관계는 기기에 대한 상당한 권한을 실었다. 인증은 어떤 컨트롤러가 명령을 보냈는지 확립할 수 있었다. 그러나 명령이 사용자 의도와 일치하는지, 미디어가 기밀인지, 물리적 출력이 올바르게 동작하는지, 중앙화된 제어가 남용되지 않는지를 증명하지 않았다.

규모는 이 경계를 증폭시켰다. 하나의 MGC가 많은 전화기를 제어하면 공통 정책과 유지보수가 쉬워지는 반면, 결함이나 침해된 권한은 많은 단말에 도달할 수 있었다. 전화기별 지능을 줄인 같은 아키텍처적 지렛대가 컨트롤러의 가용성, 권한 부여, 상태 복구, 제한된 확장의 중요성을 키웠다.

유용한 지름길은 최종 증빙이 아니었다

RFC 3054는 장치 이질성에 대한 절제된 답을 제시했다. 장치에 공통 프로필을 부여하라. 논리적 부품에 안정적인 이름을 주어라. 선택적 기능은 선택 사항으로 두어라. 차이를 추측하는 대신 감사하라. 그다음 평범한 Megaco 연산으로 원하는 미디어 및 인터페이스 상태를 조립하라.

이 절차는 어느 극단보다 정밀하다. 컨트롤러는 무(無)에서 모든 객체의 의미를 다시 발견할 필요가 없었다. 반대로 프로필 이름을 외피 뒤의 모든 것에 대한 증거로 취급할 자격도 없었다.

전화기는 자기 부품들의 이름을 말했다. 그래도 컨트롤러는 무엇이 있는지 물어야 했다. 그다음에는 명령, 컨텍스트 상태, 패킷, 디코딩된 오디오, 그리고 책상 앞의 사람이 각각 서로 다른 증빙을 제공했다.

출처

Lu Heng은 RFC 3054나 관련 표준을 저작하거나 승인하지 않았다. 그의 에세이는 명시된 분석적 렌즈로만 사용되었다.