요약

  • RFC 3326은 SIP 요청이 그 요청을 유발한 프로토콜상 원인을 함께 실을 수 있게 하여, 동일해 보이는 CANCEL이나 BYE 동작이 서로 다른 서비스 및 사용자 인터페이스 결과로 이어질 수 있게 했습니다.
  • Reason은 선택 사항이고 무시 가능하며 SIP 핵심 처리 밖에 있었습니다. 그 이름공간(namespace), 생성·복제하는 홉, 매핑 규칙, 무결성 근거는 Reason이 주장하는 사건 자체와 분리되어 있어야 했습니다.

부재중 통화 기록은 더 이상 보이지 않는 사건에 의존했다

포킹 프록시는 하나의 INVITE를 여러 등록 단말로 보낼 수 있었습니다. 한 브랜치가 200 OK를 돌려받으면 프록시는 나머지 브랜치를 CANCEL로 중단했습니다. 진 브랜치의 단말을 보던 사용자에게는, 발신자가 응답 전에 그냥 포기한 경우와 같은 결과가 나타났습니다. 즉 벨소리가 멈춘 것이었습니다. 그러나 통화 기록이 두 사례를 똑같이 다룰 필요는 없습니다. "다른 곳에서 응답됨"은 부재중 통화가 아니며, 발신 포기는 부재중 통화일 수 있습니다.

CANCEL 메서드는 동작을 설명했습니다. 그 동작을 프록시가 발행하게 된 사건은 설명하지 않았습니다. RFC 3326은 Reason을 정의하며 두 번째 층을 삽입했습니다. 성공한 브랜치가 있는 경우 프록시는 다른 브랜치에 보내는 CANCEL에 SIP 원인 200과 "Call completed elsewhere"라는 문구를 넣을 수 있었습니다. 수신 단말은 그 맥락을 활용해 오해를 낳는 부재중 통화 알림을 피할 수 있었습니다.

작은 헤더가 큰 개념적 역할을 맡은 것입니다. 프로토콜 상태 전이가 보이는 차이를 지운 뒤에도 인과성이 살아남게 했습니다. 동시에 이유마다 새로운 CANCEL 메서드를 만들려는 유혹도 막았습니다. 요청은 여전히 CANCEL이었고, 서비스는 그 동작의 트리거에 대한 별도의 주석을 받았습니다.

Reason은 이 예시에 국한되지 않았습니다. 다이얼로그 내 임의의 요청, 임의의 CANCEL, 상태 코드가 명시적으로 허용하는 응답에 나타날 수 있었습니다. 성공 응답에서 수용 불가능한 오퍼를 받은 클라이언트는 정확히 ACK를 보내고 BYE를 보내며 종료 사유를 설명하는 SIP 488 원인을 실을 수 있었습니다. 한쪽 당사자의 통화 중을 알게 된 제3자 콜 컨트롤러는 486을 실은 BYE로 다른 다이얼로그를 종료할 수 있었습니다. 게이트웨이는 ISUP 릴리스를 Q.850 원인으로 번역할 수 있었습니다.

공통 패턴은 인과적 인수였습니다. 한 브랜치, 다이얼로그 또는 프로토콜에서 관찰된 결과가 다른 곳의 동작을 유발했습니다. 이후의 메시지는 자신이 왜 존재하는지 소비자가 이해할 만큼의 맥락을 보존해야 했습니다.

유용한 이유라도 제어 지시가 아니었다

RFC 3326은 구현이 흔히 흐리는 경계를 그었습니다. 클라이언트와 서버는 Reason을 자유롭게 무시할 수 있으며, 이 필드는 프로토콜 처리에 아무 영향이 없습니다. 필드가 있든 없든, 이해되든 버려지든 CANCEL은 취소되었습니다. Reason은 사용자 인터페이스, 서비스 선택, 진단 기록에 영향을 줄 수는 있었지만 트랜잭션 상태 머신을 재정의하지는 않았습니다.

이 구분 덕분에 Reason은 실행 영수증이 아니라 근거 객체가 됩니다. 캡처는 메시지에protocol=SIP와 숫자 원인이 담겼음을 증명할 수 있습니다. 그러나 그것만으로 다른 브랜치가 실제로 응답했는지, 발신자가 그 사건을 직접 관찰했는지, 중개자가 충실히 복제했는지, 수신자가 이를 활용했는지 증명하지 못합니다. Reason에 기반한 서비스 동작에는 그 자체의 영수증이 필요합니다.

문법도 이 분리를 강화했습니다. 모든 Reason 값은 프로토콜 이름공간으로 시작하고, 숫자 원인, 따옴표로 감싼 텍스트, 확장 같은 파라미터가 뒤따랐습니다. SIP 원인은 SIP 상태 코드에서 번호를 가져왔습니다. Q.850 원인은 전혀 다른 코드 체계에서 왔습니다. Q.850에서 16은 정상 통화 해제를 의미하며, SIP 상태 16이 아니었습니다. 분석의 편의를 위해 이름공간을 제거하면 의미가 파괴됩니다.

텍스트 파라미터 역시 기계적 권위가 아니었습니다. 원인을 읽기 쉽게 만들었지만, 번역, 벤더 문구, 실수가 등록된 숫자 의미와 어긋날 수 있었습니다. 따라서 내구성 있는 기록에는 이름공간과 원인을 구조화된 필드로 담고, 텍스트를 정식 코드가 아니라 별도로 보존해야 합니다.

RFC 3326은 원래 여러 Reason 값이 허용되려면 모든 값이 서로 다른 프로토콜을 가리켜야 했습니다. 예컨대 하나는 SIP, 하나는 Q.850이었습니다. RFC 9366이 2023년 이 규칙을 갱신했습니다. 동일한 등록 프로토콜에 대한 여러 값은 그 프로토콜이 반복의 의미를 정의한 경우에만 나타날 수 있습니다. 그 외의 경우에는 프로토콜당 하나의 값이 여전히 규칙입니다. 이 갱신이 중요한 이유는, 파서가 문법만으로 반복된 원인을 목록이라고 판단할 수 없고 의미론은 등록에 속하기 때문입니다.

번역은 맥락을 보존하면서 새로운 불확실성을 낳았다

상호 접속(interworking)은 Reason의 가치를 특히 높였습니다. RFC 3398은 ISUP과 SIP 사이의 매핑을 규정했습니다. ISUP 릴리스를 받은 PSTN 게이트웨이는 수신한 Q.850 원인을 담은 SIP CANCEL을 생성할 수 있었습니다. SIP 쪽은 더 이상 취소라는 사실만으로 외부 콜 레그가 끝난 이유를 추측할 필요가 없었습니다.

이후의 작업은 봉투를 정교화했습니다. RFC 6432는 100 Trying 외의 SIP 응답도 Reason에 Q.850 원인을 실을 수 있게 했습니다. RFC 8606은 ISUP 릴리스의 위치(location) 정보가 있을 때 이를 담는location확장을 추가했습니다. 이 위치는 ISUP 네트워크 내 넓은 범위의 장소, 예컨대 로컬·트랜짓·원격 네트워크를 가리키며, 발신자나 수신자의 물리적 위치나 신원을 뜻하지 않습니다.

각 확장은 정보를 늘리는 동시에 출처(provenance) 사슬을 길게 만들었습니다. SIP 안의 Q.850 값은 수신한 ISUP 메시지의 직접 번역일 수도, 상류에서 복제된 값일 수도, 로컬에서 생성된 근사치일 수도 있습니다. 최종 발신자가 반드시 최초 관찰자는 아닙니다. 그 값을 근거로 부르려면 운영자는 외부 메시지, 매핑 버전, 게이트웨이 신원, 복제 이력, 무결성 상태를 확보해야 합니다.

RFC 7044의 History-Info와 RFC 5806의 역사적 Diversion 메커니즘은 관련되지만 다른 질문을 다룹니다. 이들은 재지정(retargeting)이나 전환(diversion) 이력을 기술합니다. Reason은 특정 요청이나 허용된 응답이 왜 발행되었는지를 기술합니다. 경로 이력은 릴리스 원인을 대체할 수 없고, 릴리스 원인이 전체 경로를 재구성하지도 못합니다.

복제는 인과성을 살렸지만 실수도 퍼뜨렸다

프록시가 Reason을 담은 CANCEL을 받고 다음 홉을 위한 CANCEL을 생성할 때, RFC 3326은 이 필드를 복제하도록 규정했습니다. 복제가 없다면 동작은 전파되지만 그 원인은 사라집니다. 복제가 있으면 최종 단말이 더 나은 인터페이스 판단을 내릴 수 있습니다.

그러나 복제는 주장의 출처를 바꿉니다. 마지막 CANCEL을 보내는 프록시는 단지 여러 홉 전에 학습한 것을 반복하고 있을 뿐입니다. 중간 장치가 텍스트를 수정하거나, 매핑을 바꾸거나, 다른 값을 덧붙이거나, 필드를 제거하면 단말의 패킷 캡처로는 최초 관찰을 복원할 수 없습니다. 모든 복제는 관찰됨·번역됨·전달됨의 구분을 유지해야 합니다.

보안 절은 이종 오류 응답 포킹 문제(Heterogeneous Error Response Forking Problem)에 초점을 맞췄습니다. 다른 브랜치가 아직 활성인 동안, 한 포크의 최종 오류가 클라이언트에 도달하지 않을 수 있었습니다. 그런 상황에서 Reason을 위조하거나 제거하면 클라이언트가 이전 요청을 올바르게 갱신하지 못하게 되어 세션 수립 자체가 불가능해질 수 있었습니다. 그래서 문서는 적절한 무결성 보호를 권고했습니다.

무결성 보호는 실제로 존재하고 검증되었을 때, 한정된 질문에 답합니다. 식별된 보호 지점 사이에서 보호된 바이트가 변경되었는지 여부입니다. 실제 세계의 사건, 올바른 매핑, 성실한 최초 주장을 증명하지는 못합니다. 반대로 보호가 없다고 해서 필드가 쓸모없어지는 것은 아닙니다. 신뢰 수준이 낮아지고, 이에 의존해야 할 동작이 달라질 뿐입니다.

RFC 3326의 역사적 성취는 네트워크가 통화가 왜 끝났는지 배웠다는 것이 아니었습니다. 네트워크는 이미 그 지식의 조각들을 갖고 있었습니다. 성취는 동작이 구분 불가능해진 뒤에도 이유를 별개의, 이름공간이 있는, 전달 가능한 객체로 유지한 것입니다. 남는 교훈도 똑같이 정확합니다. 원인을 보존하는 것은 이력을 인증하는 것과 같지 않다는 것입니다.

출처