요약

  • RFC 3351은 SIP 설계자들에게 텍스트·음성·영상·중계 서비스·사용자 선호 설정을, 통화를 다시 시작하지 않고도 바뀔 수 있는 세션의 구성 요소로 다루도록 요청했습니다.
  • 이 문서는 표준화된 확장이 아니라, 문서에 제시된 시나리오를 기기와 서비스가 실제로 구현했음을 증명하지도 않는 정보성 요구 사항 메모였습니다.

RFC 3351의 결정적 문장은 거의 건축 설계도의 약어처럼 간결합니다. 통화에 참여하는 모든 사용자 에이전트(User Agent)는, 트랜스코딩 서비스를 포함해, 기존 통화를 해체하고 다시 수립하지 않고도 "미디어 스트림을 추가하거나 제거할 수 있어야 한다(MUST)"는 것입니다. 음성 통화에 텍스트가 추가될 수 있고, 중계 서비스가 참여해 모달리티 간 번역을 수행한 뒤 나갈 수 있으며, 참여자가 다른 채널을 필요로 하게 되었다는 이유만으로 대화를 처음부터 다시 시작할 필요가 없습니다.

이는 접근성 기능 목록보다 훨씬 흥미로운 역사입니다. 2002년 8월에 발표된 RFC 3351은 통신 선호 설정을 세션 설계 안에 배치했습니다. 이 문서는 사용자 프로필을, SIP가 전달하고 세션 처리 방식을 결정하는 데 사용할 수 있는 능력과 선호의 집합으로 정의했습니다. 텍스트·오디오·영상은 어느 방향으로든, 또는 조합하여 흐를 수 있었습니다. 중계 서비스는 음성을 텍스트로, 텍스트를 음성으로 바꿀 수 있었습니다. 게이트웨이는 최신 사용자 에이전트를 구형 텍스트전화(textphone)에 연결할 수 있었습니다. 고정된 기기 범주가 아니라 세션이 이러한 선택들이 만나는 자리가 된 것입니다.

그러나 문서의 지위는 계속 보고 있어야 합니다. RFC 3351은 Informational 문서이며, 인터넷 표준을 명시하는 문서가 아니라고 명시적으로 밝히고 있습니다. 이 메모의 "MUST"와 "SHOULD" 표현은 저자들이 요청한 요구 사항을 기록한 것일 뿐, 메모를 표준화된 SIP 확장으로 만들거나 어떤 구현을 인증하거나 접근 가능한 통화가 실제로 완성될 수 있음을 증명하지 않습니다. 문서의 시나리오는 설계 사례이지 배포 실태 조사가 아닙니다.

이 제안은 또한 유연성이 새로운 형태의 노출을 만들 수 있음을 이해하고 있었습니다. 프로필은 통화가 올바른 미디어 경로를 찾도록 돕지만, 한 사람의 능력이나 선호를 드러낼 수 있습니다. 그래서 RFC 3351은 익명성을 요구했습니다. 중계 서비스가 참여한다는 이유만으로 수신자가 발신자가 청각장애인임을 알게 되어서는 안 된다는 것입니다. 또한 제공자들이 그런 정보가 거래 과정에서 공개되지 않도록 사용자가 막을 수 있게 하기를 촉구했고, 제3자 트랜스코더에게 기밀 유지 정책을 명시하도록 요청했습니다. 접근성은 텍스트를 추가할 수 있는가의 문제만이 아니라, 그 과정에서 서비스가 무엇을 알게 되고, 저장하고, 공개하는가의 문제이기도 했습니다.

비용과 선택에 관한 언어는 이례적으로 구체적입니다. 메모는 사용자 에이전트가 스트림의 내용을 식별하고, 트랜스코딩 서비스를 능력과 정책 기준으로 비교하며, 대안을 찾아내기를 원했습니다. 중계 세션이 시작되기 전에 분당 요금과 최소 요금을 표시하자고 제안했습니다. 라디오 예시에서는 텍스트 스트림을 이용할 수 없었고, 트랜스코딩 제공자는 자원을 과부하시킬 수 있다는 이유로 오디오 처리를 거절했습니다. 통화 경로에는 마법 같은 보장이 아니라 운영상 한계가 있었습니다. 서비스를 선택 가능하게 만든다는 것은 중개자를 보이지 않는 인프라로 취급하는 대신, 그 한계와 가격을 드러내는 일이었습니다.

시나리오는 타이핑한 텍스트를 넘어 확장됩니다. 하나는 기존 음성 연결을 유지한 채 중계 서비스가 음성을 텍스트로, 타이핑한 답장을 다시 음성으로 바꿉니다. 다른 하나는 선호가 다른 회의 참가자를 위해 음성-텍스트, 텍스트-수화, 수화-텍스트 서비스를 사슬처럼 연결합니다. 음성 인식 메뉴는 중계 서비스를 통해 텍스트 경로를 얻습니다. 이는 야심적인 스케치들입니다. 사용자가 선택한 모달리티를 중심에 두지만, 변환 단계가 하나 추가될 때마다 제공자 하나, 정책 하나, 잠재적 요금 하나, 그리고 정보가 경계를 넘는 지점이 하나 더 생깁니다.

RFC 3351 이후의 역사는 일련의 사양 문서이지, 보편적 성공의 기록이 아닙니다. RFC 4103은 T.140 실시간 텍스트용 RTP 페이로드와 손실 문자 일부를 복구하기 위한 중복 전송을 정의했습니다. RFC 5194는 이후 텍스트, 트랜스코딩, 표현, 상호운용에 관한 더 상세한 요구 사항을 담은 SIP/IP 프레임워크를 제시하며 RFC 3351의 중계 지침을 인용했습니다. RFC 4504는 SIP 전화 기기가 RFC 3351의 접근성 요구 사항을 지원할 것을 권고했습니다. 그보다 훨씬 나중에 RFC 8865는 신뢰성 있고 순서가 보장되는 WebRTC 데이터 채널을 통한 T.140 전송을 명세했고, RFC 9071은 출처를 인식하는 다자간 RTP 텍스트를 다루며 RFC 4103을 갱신했습니다. 각 문서는 경로의 일부를 더 정밀하게 만듭니다. 그러나 어느 문서 하나만으로도 모든 엔드포인트, 제공자, 긴급 서비스 또는 사용자에게 그 경로가 이용 가능하다는 것은 확립되지 않습니다.

이 구분이 핵심입니다. 세션이 기술적으로 확장 가능하더라도 서비스는 이용 불가능하거나, 비쌀 수 있고, 호환되지 않거나, 스트림을 거부할 수 있습니다. 프로필은 통화를 매칭하는 데 도움을 주면서 동시에 민감한 정보를 노출할 수 있습니다. 중계 서비스는 미디어를 연결하면서도 요금이나 기밀 유지 위험을 부과할 수 있습니다. RFC 3351의 지속적 기여는 이러한 판단을 설계 논의 안에 놓은 것입니다. 매체를 바꾸는 일이 새로운 통화 수립을 강제해서는 안 되며, 사용자가 그 변경이 어떻게 일어나는지에 대해 의미 있는 통제를 유지해야 한다는 것입니다.

출처:RFC 3351·RFC 3351 기록·RFC 3351 Datatracker 기록·RFC 2119·RFC 8174·SIP: Session Initiation Protocol, RFC 3261·An Offer/Answer Model with SDP, RFC 3264·RTP Payload for Text Conversation, RFC 4103·Framework for Real-Time Text over SIP, RFC 5194·SIP Telephony Device Requirements, RFC 4504·T.140 Text over WebRTC Data Channels, RFC 8865·RTP-Mixer Formatting of Multiparty Real-Time Text, RFC 9071·Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption·Running-Code Primacy