요약

  • RFC 3960은180 Ringing을 착신자가 호출되고 있다는 증거로 다루었지, 통화 내 톤이나 안내 멘트가 발신자에게 도달했다는 증명으로 다루지 않았다.
  • POTS 방식의 클라이언트는 미디어 패킷이 도착하지 않는 동안 로컬 링백을 재생하고, 패킷이 나타나면 수신 미디어로 전환하면서도 협상, 인증, 렌더링, 최종 통화 결과를 별개의 판정으로 유지할 수 있었다.

SIP 통화에서 가장 알려주는 소리는 네트워크가 전송하지 않은 소리일 수 있었다. 발신자는 익숙한 벨소리를 들었지만, 그 톤은 발신자 단말이 만들어낸 것일 수 있었다. 원격 엔드포인트는 진행 상황을 보고했고, 로컬 엔드포인트는 그 음향적 공백을 채웠다. 나중에 패킷이 도착하면 단말은 자체 톤을 멈추고 네트워크 스트림을 재생할 수 있었다. 듣는 사람에게는 하나의 연속적인 대기였지만, 시스템에게는 증거 출처의 변경이었다.

RFC 3960은 2004년 12월에 얼리 미디어와 링백 톤 생성을 설명하기 위해 발표되었다. 얼리 미디어란 최초의 INVITE 이후 최종 응답 이전에 교환되는 미디어를 의미하며, 일반 링백, 안내 멘트, 대기열 메시지, 인터랙티브 프롬프트를 포함한다. 이 문서의 결정적 조치는 편리한 동치를 거부한 것이었다: SIP 진행 시그널링은 관측된 미디어와 같은 것이 아니었다.

문서의 예시 정책은180 Ringing에서 시작한다. 그 응답 이전에는 POTS 방식의 사용자 에이전트가 로컬 벨소리를 생성하지 않는다.180이후, 수신 미디어 패킷이 없으면 로컬에서 링백을 생성한다. 패킷이 있으면 그것을 재생하고 로컬 링백을 생성하지 않는다.180은 착신자가 호출되고 있음을 뜻하며, RFC는 얼리 미디어 세션의 상태와 무관하게 그 조건에 대해 이를 보내야 한다고 말한다.

이 구분이 중요했던 이유는 시그널링만으로 미디어 문제를 해결할 수 없었기 때문이다. 단순한 서버는 신뢰성 있는 잠정 응답 없이 얼리 미디어를 보낼 수 있었다. 다른 서버는 사전조건(precondition) 충족을 위해서만 신뢰성 있는 잠정 응답에 answer를 담고, 그 시점에 얼리 미디어를 보낼 의도가 없을 수도 있었다.RFC 3262는 RSeq, RAck, PRACK을 통해 잠정 응답에 신뢰성을 부여했지만, 신뢰성 있는 시그널링 교환을 RTP가 도착했다는 증명으로 바꾸지는 않았다.RFC 3312는 자원 조건이 충족될 때까지 세션 진행을 지연시킬 수 있었고, 그 과정에서 사용된 answer 역시 오디오 패킷이 아니었다.

이 분리는 논리적일 뿐 아니라 물리적이기도 했다. 시그널링은 보통 프록시를 거쳤지만, 미디어는 지연에 최적화된 경로를 따랐다. 패킷이 그것을 설명할 SIP 응답보다 먼저 발신자에게 도달할 수 있었다. 반대로, 연결성 확보 작업이 미디어를 지연시키는 동안 시그널링이 먼저 도착할 수도 있었다. 완벽한 "얼리 미디어 존재" 플래그를 기다리는 것은 두 순서를 모두 해결하지 못했다. 그래서 RFC 3960은 관측 가능한 로컬 규칙을 선호했다: 진행 피드백을 제공한 다음, 실제 수신 미디어에 양보하라.

패킷 도착조차 이 사다리의 끝이 아니었다. RFC는 패킷이 무음이나 컴포트 노이즈를 담을 수 있기 때문에 클라이언트가 내용을 검사할 수 있음을 언급한다.RFC 3711은 보안 실시간 미디어를 위한 인증, 무결성, 재생 공격 방지, 선택적 기밀성을 제공했지만, 암호학적 수용 여전히 이해 가능한 오디오, 성공적인 디코딩, 스피커 출력, 사람의 이해를 증명하지는 못했다.180, 협상된 튜플, 첫 패킷, 인증된 스트림, 들린 안내 멘트는 서로 다른 영수증에 속했다.

오퍼/앤서 메커니즘은 또 하나의 독립적인 계층을 제공했다.RFC 3264는 엔드포인트가 미디어 매개변수를 협상하는 방식을 정의했고,RFC 3261은 그 설명을 전달하는 SIP 메시지를 정의했다. 오퍼와 앤서의 완료는 당사자들이 호환되는 매개변수를 선택했다는 뜻일 뿐, 트래픽의 증명이 아니었다. RFC 3960은 또한200 OK이전에 패킷을 재생할 준비를 하라고 클라이언트에 상기시켰는데, 최종 시그널링 응답을 기다리면 첫 마디가 잘릴 수 있기 때문이다.

포킹은 증거 문제를 더 어렵게 만들었다. 하나의 INVITE가 여러 사용자 에이전트에 도달할 수 있고, 각각은 얼리 다이얼로그와 잠재적으로 얼리 스트림을 만들었다. 여러 오디오 스트림을 혼합하면 발신자가 혼란을 겪고, 대역폭이 모두를 수신하지 못할 수도 있었다. 게이트웨이 모델에서 클라이언트는 보통 하나의 얼리 다이얼로그를 선택하고 나머지를 음소거했다. 이후2xx로 수락된 브랜치는 음소거된 브랜치 중 하나일 수 있었다. 수락 후 음소거를 해제하면 새로운 클리핑 창이 생겼다. 제시를 위해 선택된 스트림이 반드시 정규 세션이 될 브랜치는 아니었다.

RFC 3960은 그 게이트웨이 모델을 애플리케이션 서버 모델과 대비시켰다.RFC 3959는 얼리 미디어와 정규 미디어가 별도의 오퍼/앤서 교환을 사용할 수 있도록early-session디스포지션과 옵션 태그를 정의했다. 클라이언트는 수락 후 생존할 세션을 음소거하지 않고 얼리 오퍼를 거부하거나 음소거할 수 있었다. 이 분리는 포킹과 전환에 대한 제어를 개선했지만, 어떤 얼리 스트림을 재생할지 선택해야 할 필요를 없애지는 않았다.

Alert-Info 역시 이 간극을 메우지 못했다. 클라이언트가 로컬 벨소리를 생성하기로 결정했다면 어떤 대체 톤을 사용할지 알려줄 수는 있었지만, 언제 시작할지는 알려주지 않았다. 톤 선택과 벨소리 생성 권한은 서로 다른 결정이었다.

보안 섹션은 이 문제의 중요성을 드러냈다. SDP 전송 주소는 자체적으로 인증되지 않았다. 그 주소를 알아내거나 추측한 공격자는 패킷을 주입할 수 있었고, 악성 오퍼는 피해자를 향해 트래픽을 유도할 수 있었다. RFC 3960은 보호되는 설명, 미디어 인증, 대량 전송 이전의 수신 의사 핸드셰이크를 논의했다. 또한 과금 유인도 언급했다: 얼리 미디어는 무료이고 정규 미디어는 과금되는 환경에서, 악의적인 엔드포인트는 양방향 얼리 세션을 열어 두고 끝내200 OK를 보내지 않을 수 있다. 그러나 양방향 얼리 미디어를 전역적으로 차단하면 응답 전에 입력을 수집하는 정상적인 IVR 시스템도 함께 망가졌다. 해법은 단일 상태 코드 규칙이 아니라 정책을 인식하는 것이어야 했다.

이 RFC의 역사적 교훈은 소박하지만 오래 지속된다. "Ringing"은 하나의 사실이 아니었다. 그것은 원격 호출, 로컬에서 합성된 톤, 통화 내 스트림, 또는 발신자의 지각을 가리킬 수 있었다. RFC 3960이 이 계층들을 보존한 이유는, 쾌적한 사용자 경험이 그것들이 동일하다고 가장하지 않으면서 계층을 넘는 데 달려 있었기 때문이다.

RFC Editor의메타데이터 기록과정오표 검색이 발행 기록을 뒷받침한다. 관련 표준은RFC 3261,RFC 3262,RFC 3264,RFC 3959,RFC 3312,RFC 3711이다.