요약

  • RFC 3087는 SIP 클라이언트나 프록시가 고유한 Request-URI를 선택하는 방식으로 애플리케이션의 시작 컨텍스트를 전달할 수 있게 했습니다. 여기에 저장하기, 이 인사말 사용하기, 이 사서함 검색하기, PIN 요청하기 등이 그 예입니다.
  • URI는 로컬에서 구성된 동작을 선택했습니다. URI는 발신자를 인증하지 않았고, 착신 전환 이유를 증명하지 않았으며, 사서함 접근을 허가하지도 않았고, 메시지가 저장되거나 재생되었음을 보여주지도 않았습니다.

전화는 도착했지만, 그에 딸린 단서는 그렇지 않았다

전통적인 음성사서함 시스템은 착신 번호, 발신 번호, 전환 사유를 참조할 수 있었습니다. 이 신호들을 통해 혼선 중 인사말, 부재중 인사말, 특정 사서함, 또는 자기 자리에서 전화한 가입자를 위한 검색 메뉴를 고를 수 있었습니다. 이 편의는 각 번호와 교환기 이벤트가 무엇을 의미하는지에 대한 일련의 가정에 의존했습니다.

SIP은 그 사슬을 느슨하게 만들었습니다. 하나의 호출이 여러 프록시에 의해 재지정될 수 있었습니다. 기존 호 상태 정보의 일부는 누락될 수도 있고 신뢰할 수 없을 수도 있었습니다. 안정적인To필드는 요청이 다른 서비스로 향하는 동안에도 처음 호출된 논리적 인물을 계속 가리킬 수 있었습니다. RFC 3087의 간결한 예에서 A가 B에게 걸었고, B가 C로 전환했으며, C가 C의 음성사서함으로 전환했습니다.To: B를 사서함 선택자로 취급하는 음성사서함 애플리케이션은 잘못된 저장소를 열게 됩니다.

RFC 3087은 2001년 4월에 Informational 메모로 발표되었으며, 새로운 SIP 메서드나 헤더를 제안하지 않았습니다. 기존의 구분을 활용한 것입니다.To필드는 논리적 수신자를 나타내는 반면, 프록시는 Request-URI를 현재 사용자 또는 서비스 대상으로 다시 쓸 수 있었습니다. 대상이 서비스 식별자가 될 수 있다면, 그 대상은 서비스의 초기 상태까지 선택할 수 있었습니다.

그 메커니즘이 이미 존재했기 때문에 사소해 보입니다. 그러나 그 결과는 아키텍처적이었습니다. 컨텍스트가 과거의 잔해에서 추측하는 애플리케이션 논리가 아니라 명시적인 라우팅 결과가 된 것입니다.

하나의 애플리케이션이 여러 문을 열 수 있었다

이 메모는 음성사서함 시스템에 별도로 구성된 SIP 식별자들의 집합을 부여했습니다. 어떤 URI는 일반 인사말로 가입자 사서함에 저장하는 것을 의미할 수 있고, 다른 URI는 혼선 중 인사말이나 특별 인사말을 선택할 수 있었습니다. 검색 역시 SIP 계층에서 이미 인증된 요청용 입구와 대역 내 PIN 입력을 요구하는 입구로 나뉠 수 있었습니다. 일반 입구는 발신자에게 사용할 사서함을 물어볼 수 있었습니다.

find-me 프록시는 그 문들 사이에서 선택할 수 있었습니다. 모든 연락처가 응답 없이 만료되면 일반 저장 식별자로 라우팅하고, 모든 곳에서 혼선 응답이 돌아오면 혼선 안내 식별자를 선택할 수 있었습니다. 방해 금지 설정은 또 다른 애플리케이션 입구로 이어질 수 있었습니다. 음성사서함 서비스는To,From과 교환기의 관행적 단서를 바탕으로 그 상류 결정을 재구성할 필요가 없었고, 이미 의도된 동작을 명명하는 현재 대상을 그대로 받았습니다.

그러나 URI의 겉모습 자체는 프로토콜 언어가 아니었습니다. RFC 3087은 애플리케이션이 기억하기 쉬운 문자열에 의미 규칙을 부과하지 말 것을 경고했습니다. 운영자는deposit, 번호, 파라미터가 붙은 사용자 이름 또는 임의의 유효한 SIP URI를 구성할 수 있었습니다. 애플리케이션은 구성된 식별자를 동작에 매핑해야 했고, 그 사전은 시스템 소유자가 관리했습니다.

여기에 중요한 증거 한계가 있습니다. 수집한 URI에서busy라는 단어는 추적을 읽기 쉽게 만들 수 있지만, 표준화된 혼선 조건을 증명하지는 못합니다. 그 단어는 이 문자열이 이 홉에 도달했다는 사실만 증명합니다. 그 의미를 알려면 조사자는 구성 기록과 그 URI를 만든 재작성 결정을 확인해야 합니다.

라우팅 컨텍스트와 접근 허가는 서로 다른 문이었다

메모의 검색 사례들은 이 구분을 명확히 보여줍니다. 음성사서함 서비스는 보안 관계를 통해 인증을 위임할 수 있는 신뢰할 수 있는 출처로부터 사서함별 검색 URI를 받아들일 수 있었습니다. SIP 인증 이후 요청을 수용할 수도 있었습니다. 인증에 실패했거나 출처가 인증을 제공하지 않으면, 서비스나 보호 프록시는 요청을 PIN 입력을 요구하는 입구로 재지정할 수 있었습니다.

따라서sip:subscriber-retrieve@...는 검색 권한을 부여하지 않고 검색 워크플로우만 선택할 수 있었습니다. Request-URI는 요청이 어떤 문에 도달했는지를 말할 뿐, 신뢰 관계, SIP 자격 증명 또는 PIN이 발신자가 그 문을 통과할 수 있는지를 결정했습니다.

이 구분은 겉보기에 익숙한 사례에서도 중요했습니다. 게이트웨이는 PSTN 발신 번호를 인식하고 호출을 가입자별 경로로 매핑할 수 있었지만, 그 인식은 해당 제공자가 신뢰한 가정이지 발화하는 사람에 대한 암호학적 증명이 아니었습니다. RFC 3087의 상세 흐름은 보호 프록시와 그 프록시와 음성사서함 시스템 사이의 신뢰 관계를 가정했습니다. 마지막 보안 절은 새로운 보호 장치를 추가하지 않고 SIP 자체의 보안 고려사항을 독자에게 안내했습니다.

따라서 패킷 추적은 경계가 정해진 진술들의 사슬을 뒷받침할 수 있습니다. 프록시가 INVITE를 수신했다, 특정 서비스 URI를 선택했다, 애플리케이션이 그 대상을 수용했다, 인증 분기가 실행되었다, RTP가 수립되었다. 그 어느 하나만으로도 실제 발신자가 사서함 소유자임을, 명시된 전환 사유가 역사적으로 정확했음을, PIN이 비밀로 유지되었음을, 녹음이 저장소에 기록되었음을, 이후 누군가 그것을 들었음을 증명하지는 못합니다.

로컬 관습은 아직 상호운용성 어휘가 아니었다

RFC 3261은 이후 원래 SIP 사양을 대체하면서 관련 메커니즘은 유지했습니다. Request-URI가 주소 지정된 사용자 또는 서비스를 명명하고, 프록시의 대상 처리가 요청이 라우팅되면서 그것을 교체한다는 점입니다. 이후의 History-Info 사양들은 SIP에 재지정 이력을 전달하는 방법을 제공했습니다. 이 발전들은 계층을 이해하는 데 도움이 되지만, 어떤 RFC 3087 설치 환경이 그것을 사용했는지 증명하지는 않습니다.

RFC 4458은 더 일러준다. 2006년 이 사양은 음성사서함과 대화형 음성 응답을 위한target및causeURI 파라미터를 정의했습니다. 그 동기는 벤더들이 로컬 매핑을 구성 가능하게 만들 수 있지만, 구성만으로는 호 제어, 게이트웨이, 통합 메시징 시스템 간의 상호운용성에 현실적이지 않다는 것이었습니다. RFC 3087은 URI가 제어 표면이 될 수 있는 방법을 보여주었고, RFC 4458은 그 제어 중 두 조각에 공통 어휘를 제공했습니다.

나중의 관습이 이전 관습을 실패로 만들지는 않습니다. 이것은 두 성취의 차이를 드러냅니다. 하나의 관리 도메인 안에서 시스템은 라우팅 컨텍스트와 안정적인 논리적 식별자를 깔끔하게 분리할 수 있습니다. 그러나 서로 다른 시스템 사이에서 사서함과 전환 사유가 안정적으로 전달되려면 여전히 공유된 문법과 의미론이 필요합니다.

RFC 3087의 오래가는 교훈은 이 증거 사슬에 있습니다. 원래 착신 대상, 현재 Request-URI, 프록시가 재작성한 이유, 로컬 URI-동작 매핑, 인증 결과, 선택된 메뉴, 미디어 세션, 저장된 메시지는 서로 관련된 기록입니다. 그러나 그것들은 서로 교환 가능하지 않습니다. 컨텍스트를 경로에 넣는 것은 추측을 줄였습니다. 그러나 라우팅을 신원으로 바꾸지는 못했습니다.

출처

  1. https://www.rfc-editor.org/info/rfc3087
  2. https://www.rfc-editor.org/rfc/rfc3087.html
  3. https://www.rfc-editor.org/rfc/rfc3087.txt
  4. https://datatracker.ietf.org/doc/rfc3087/
  5. https://www.rfc-editor.org/errata/rfc3087
  6. https://www.rfc-editor.org/rfc/rfc2543.html
  7. https://www.rfc-editor.org/rfc/rfc3261.html
  8. https://www.rfc-editor.org/rfc/rfc4244.html
  9. https://www.rfc-editor.org/rfc/rfc4458.html
  10. https://www.rfc-editor.org/rfc/rfc3326.html
  11. https://www.rfc-editor.org/rfc/rfc5411.html
  12. https://www.rfc-editor.org/rfc/rfc7044.html