요약

  • RFC 3515에서 REFER에 대한 성공 응답은 수신자가 지시 사항을 처리하고 상태를 보고할 책임을 수락했다는 의미였으며, 참조된 요청이 성공했다는 의미가 아니었다.
  • 암묵적 구독,message/sipfragNOTIFY 스트림, 참조된 동작은 각각 별도의 수명을 가졌다. 관찰을 종료해도 실행이 취소되지 않았고, 분기된 구독들은 병합될 수 없었다.

익숙한 착신 전환 이야기는 SIP REFER가 거의 즉각적으로 이루어지는 것처럼 보이게 만든다. 앨리스가 밥에게 캐럴에게 연락하라고 말하고, 밥이 수락하고, 캐럴에게 연결된다. RFC 3515는 바로 그 예를 사용했지만, 그 프로토콜은 이 사건들을 하나의 응답으로 압축하지 않았다. 지시, 시도, 보고, 인간적 결과가 서로 갈라질 수 있었기 때문에 정확히 일련의 트랜잭션 사슬을 구성했다.

2003년 4월에 Standards Track으로 공개된 RFC 3515는 세 가지를 함께 정의했다: REFER 메서드,Refer-To요청 헤더, 그리고refer이벤트 패키지. 이 메서드는 Request-URI로 식별되는 수신자에게Refer-To에 명시된 자원에 연락하도록 요청한다. 잘 구성된 요청은 그런 헤더 값을 정확히 하나 포함한다. 그 자원은 이후 해당 URI 유형에 대한 일반적인 메커니즘을 통해 연락된다.

이 마지막 조항 때문에 REFER는 착신 전환보다 넓은 개념이었다. SIP URI는 새로운 INVITE로 이어질 수 있었고, 다른 URI 스킴은 다른 프로토콜을 트리거할 수 있었다. RFC 3515는 REFER 본문 자체에는 아무 의미를 부여하지 않으면서 본문을 허용하기까지 했다. 수신자는 Content-Type을 통해 본문을 해석할 수 있었지만, REFER 계약 자체가 임의의 페이로드를 표준화된 지시로 바꾸지는 않았다.

수신자는 먼저 수락할지 여부를 결정해야 했다. 잘못된 문법, 지원되지 않는 URI 처리, 인증 실패 또는 정책을 이유로 거부할 수 있었다. 잘 구성된 요청에 대해서는 사용자 승인을 얻거나 구성된 정책을 통해 승인을 충족해야 했다. 더 이른 최종 응답이 적용되지 않는 경우, 원래 명세는 REFER 트랜잭션이 만료되기 전에202 Accepted를 요구했다.

운영 이력이 여기서 너무 빨리 진행되는 지점이 바로 “Accepted”라는 단어다. 이는 수신자가 REFER 트랜잭션을 수락했는지에 대한 질문을 닫았다. 새로운 INVITE가 최종 200을 받았는지, SIP가 아닌 자원이 응답했는지, 미디어가 흘렀는지, 캐럴이 말을 했는지, 전환이 비즈니스 목적을 달성했는지는 말하지 않았다. 실제로 참조된 요청은 아직 전송되지 않았을 수도 있다.

RFC 3515의 원래 계약에서 2xx 응답은 수신자가refer이벤트에 대한 암묵적 구독을 만들고 알림을 보내는 것도 요구했다. 알림 채널은 장식이 아니었다. REFER 응답이 진실하게 제공할 수 없는 상태 정보를 실어 나르는 통로였다.

첫 NOTIFY는 구독 규칙을 따랐고 REFER 트랜잭션 자체가 완료되기 전에 도착할 수 있었다. 따라서 송신자는 겉으로 보이는 시간 역전을 처리해야 했다. 관찰 스트림이 지시 교환이 아직 마무리되는 동안 시작될 수 있었다. 대기 중인 알림에는SIP/2.0 100 Trying만 담길 수 있었다. 그 행은 현재 상태를 보고한 것이었지 대상에 도달했다는 증거가 아니었다.

각 NOTIFY는Event: refer를 담았고, SIP 응답 상태 행으로 시작하는message/sipfrag본문을 실었다. 응답 클래스는 참조된 동작의 상태를 나타냈다. RFC 3515는 각 본문을 그 보고 시점에서 완전한 진술로, 이전 메시지 전체를 재구성해야 하는 상태 델타가 아니라고 기술했다.

최소 구현은 대기 중에는 100, 성공에는 200, 실패에는 503, REFER가 이미 수락된 후 승인이 거부되면 603을 보고할 수 있었다. 이 순서는 초기 202가 의도적으로 동작 성공보다 약했던 이유를 설명한다. 수락은 사용자 승인에 앞설 수 있었고, 위임된 작업은 나중에 실패할 수 있었으며, 최종 보고는 첫 응답에 붙은 낙관적 이야기를 뒤집을 수 있었다.

구분해야 하는 서로 다른 200류 메시지가 두 개 있었다. NOTIFY를 받는 사용자 에이전트는 그 NOTIFY 트랜잭션에 자신의 200 OK로 응답했다. 그 확인은 상태 보고가 수신되었다는 의미였다.message/sipfrag본문 안에 내장된 응답 코드를 채택하지 않았고, 참조된 동작을 증명하지도 않았다. 두 행을 단순히 “200”으로만 표기하는 프로토콜 트레이스는 이 구분을 지워버릴 수 있다.

SIP 참조의 경우, 구현은 참조된 SIP 응답의 더 많은 부분을 프래그먼트 안에 포함할 수 있었다. 아마도 디버깅을 돕기 위해서였다. RFC 3515는 그렇게 하면 중대한 보안 결과를 초래할 수 있다고 경고했다. 보고서는 참조자가 알 권리가 없는 헤더, 토폴로지 또는 세부 정보를 노출할 수 있다. 더 많은 텔레메트리가 자동으로 더 많은 권한이나 더 안전한 관찰성을 의미하지는 않는다.

SIP가 아닌 자원의 경우, 통지자도 상태를 SIP 응답 상태 행으로 표현해야 했다. 이 매핑은 하나의 이벤트 패키지에 대해서는 유용했지만, 본질적으로 어댑터의 계정이었다. 알림 속의 SIP 200은 다른 프로토콜의 결과를 요약할 수 있었지만, 그 프로토콜의 고유 수신 증명, 정확한 대상, 부수 효과 또는 물리적 결과를 보존하지는 않았다.

구독에는 자체 수명이 있었다. REFER는 요청이나 응답에 구독 기간을 담지 않았다. 수락한 에이전트가 기간을 선택해 첫 NOTIFY에서 알렸고, 일반적으로 참조된 요청이 완료될 만큼 충분히 길었다. 참조자는 구독을 갱신하거나 조기에 종료할 수 있었다.

결정적으로, 관찰을 끝내는 것이 동작을 끝내는 것은 아니었다. RFC 3515는 명시적으로 구독 해제하거나 NOTIFY를 거부하는 것이 참조된 요청을 철회하거나 포기하라는 표시가 아니라고 말한다. 참조자가refer이벤트를 더 이상 따르지 않는다는 이유만으로 수신자가 CANCEL을 보내서는 안 된다. 모니터링 관계와 실행 중인 작업은 별개의 제어 표면이었다.

이것은 단순한 SIP의 호기심 거리가 아니다. 시스템은 흔히 “업데이트 보내기를 멈춰라”를 “작업을 멈춰라”로 잘못 받아들이거나, 대시보드 행이 사라지는 것을 작업 종료의 증거로 취급한다. RFC 3515는 정반대를 선택했다. 구독 제어는 보고를 관장하고, 참조된 요청은 자신의 트랜잭션 의미를 유지했다.

포킹은 또 하나의 분리를 더했다. 기존 다이얼로그 안의 REFER는 이 문서의 규칙에 따라 포크되지 않았다. 다이얼로그 밖의 REFER는 여러 수락 에이전트에 도달해 여러 구독을 만들 수 있었다. 발행자는 각 구독을 독립적으로 관리해야 했고, 그 상태를 병합해서는안 되었다. 한 에이전트의 200과 다른 에이전트의 503은 하나의 평균된 결과가 아니라, 서로 다른 수신자가 수행한 서로 다른 시도를 기술한 것이었다.

다이얼로그 식별자는 각 NOTIFY를 REFER가 만든 구독에 연결했지만, 상관관계가 보안 모델 전부는 아니었다. 수신자는 여전히 누가 자신을 어느 자원에 연락하게 만들 수 있는지를 승인해야 했다. 부주의한 정책은 REFER를 신뢰된 위치에서 보호된 SIP, HTTP 또는 기타 대상에 접근하는 수단으로 바꿀 수 있었다. 따라서Refer-To구성은 보호된 자원을 적절히 제한해야 했다.

이후의 RFC들은 관찰 채널의 형태를 바꿨다. RFC 4488은 발행자가 암묵적 구독의 억제를 요청할 수 있게 했다. RFC 7614는 명시적 구독을 정의했다. RFC 7647은 RFC 6665가 갱신한 이벤트 프레임워크 아래의 REFER 동작을 명확히 했고, RFC 8217은 관련 SIP 문법을 다듬었다. 이 갱신들은 중요하지만, 어느 것도 수락과 결과를 동일하게 만들지 않는다. 오히려 선택적이고 명시적인 관찰은 어떤 계약이 트레이스를 지배했는지를 기록하는 일을 더 중요하게 만든다.

Lu Heng의 상징적 현실과 운영적 현실의 구분은 여기서 유용하다. 202는 특정한 책임에 대한 상징적 수신 증명이다. NOTIFY는 구독 안에서 이름이 밝혀진 통지자가 보내는 보고서다. 참조된 요청은 자신의 프로토콜 아래에서 실행된다. 미디어, 대화, 인간의 동의, 비즈니스 완료는 아직 더 뒤의 관찰 계층에 놓여 있다. 한 계층에서 올바른 메시지가 다음 계층의 수신 증명을 만들어내지는 못한다.

따라서 증거 사다리는 유효한 REFER와 권한 있는 발행자에서 시작된다. REFER 응답, 구독 식별자 또는 합의된 구독 부재, 정확한 참조된 요청, 상관된 진행 보고, 최종 프로토콜 응답, 그리고 마지막으로 애플리케이션 또는 인간적 결과로 이어진다. 한 단계를 건너뛰면 범위가 제한된 프로토콜 사실이 트레이스가 뒷받침할 수 없는 주장으로 변한다.

RFC 3515의 설계 교훈은 위임이 불신뢰적이라는 것이 아니다. 위임에는 지시, 관찰, 실행에 대한 별개의 기록이 필요하다는 것이다. REFER는 수락되었다. 그것은 실재하고 유용했다. 동작은 여전히 다른 어딘가에서 일어나야 했고, 성공에는 자체적인 증명이 필요했다.

출처