요약

  • RFC 2543에서 Via branch는 주로 포킹 프록시가 만든 복사본을 구분하는 데 쓰였습니다. RFC 3261은 branch를 필수로 만들고 시공간 전반에 걸쳐 고유하도록 요구해 트랜잭션 식별이 가능하게 했습니다.
  • 접두어z9hG4bK는 비밀이 아니라 호환성 표식입니다. 수신 측이 간결한 RFC 3261 매칭 규칙을 적용하면서도 구형 트래픽을 위한 다중 필드 대체 절차를 유지할 수 있게 합니다.
  • 재전송은 branch를 유지하고, 새 전달 시도에는 새 branch를 부여하며, CANCEL과 비-2xx ACK는 의도적으로 같은 branch를 재사용합니다. 이 예외들은 트랜잭션 경계를 약화시키는 것이 아니라 정의합니다.

쿠키 이전에는 branch가 포크만 구분했습니다

SIP 요청은 사용자 에이전트에 도달하기 전에 여러 프록시를 거칠 수 있습니다. 각 상태 저장 홉은 요청을 하나 받아 하나 이상의 다음 대상을 선택하고, 시도마다 로컬 클라이언트 트랜잭션을 생성합니다. 응답은 경로에 따라 쌓인 Via 값들을 역으로 거슬러 돌아갑니다.

최초의 SIP 표준인RFC 2543에도 이미branch매개변수가 있었습니다. 그 약속은 좁았습니다. 포킹 프록시는 하나를 삽입하여 병렬 복사본에서 온 응답을 올바른 가상 클라이언트에 배정할 수 있도록 합니다. 포킹하지 않는 프록시는 삽입할 수 있지만 의무는 아니었습니다. 이 토큰은 해당 포크의 동형 요청들 사이에서만 고유하면 됐습니다.

그 branch는 여러 단서 가운데 하나였습니다. RFC 2543은 To, From, Call-ID, CSeq 및 첫 Via branch를 사용해 응답을 매핑했습니다. 요청 처리는 호출 다리(콜 레그)와 시퀀스 번호에 대해서도 판단했습니다. 프로토콜은 동작할 수 있었지만, 서버가 임의의 branch를 보고 그것이 하나의 통일된 고유성 규칙을 가진 트랜잭션 식별자라고 결론 내릴 수는 없었습니다.

이 구분은 구형 구현과 신형 구현이 같은 네트워크를 공유할 때마다 중요합니다. 기존 필드의 의미를 표시 없이 바꾸면 수신자가 추측을 강요받습니다. 어떤 규칙을 따랐는지 아는 쪽은 송신자이고, 틀릴 때의 비용은 수신자가 감당합니다.

일곱 글자가 새 매칭 법칙을 선택했습니다

RFC 3261은 2002년에 이 계약을 바꿨습니다. 사용자 에이전트 클라이언트는 모든 요청의 맨 위에 Via를 두어야 했고, 그 Via에는 branch가 있어야 했습니다. 정의된 예외를 제외하고, 그 값은 해당 사용자 에이전트가 보내는 모든 요청에 대해 시공간을 통틀어 고유해야 했습니다.

새 branch는 또한z9hG4bK로 시작해야 했습니다. 이 문자열에는 날짜, 공급자, 경로, 신원 같은 것이 인코딩되어 있지 않습니다. 사양은 RFC 2543 구현이 우연히 만들어내지 않을 일곱 개의 희귀한 문자를 골랐습니다. 수신 시 이 접두어는 나머지 토큰이 RFC 3261의 고유성 규칙에 따라 만들어졌다는 뜻입니다.

그래서 "매직 쿠키"라는 표현은 현대 독자에게 오해를 줄 수 있습니다. 이것은 브라우저 쿠키도, 자격 증명도, 무작위 챌린지도 아닙니다. 해석이 바뀐 그 값 안에 심혼을 기울여 넣은 버전 증인입니다. 레지스트리에 상대방이 현대적인지 물어볼 필요 없이, 수신자는 요청을 검사하고 매칭 법칙을 로컬에서 선택할 수 있었습니다.

트랜잭션이 로컬에서 매칭 가능해졌습니다

쿠키를 가진 요청에 대해 서버 트랜잭션은 세 가지 사실을 대조합니다: 최상위 Via의 branch, 그 Via의sent-by값, 그리고 메서드. ACK에는 특별한 예외가 있습니다. 비성공 ACK는 INVITE 트랜잭션에 속하기 때문입니다. 두 클라이언트가 우연히든 악의적으로든 branch를 중복할 수 있으므로 sent-by는 여전히 필요합니다.

branch가 없거나 쿠키를 갖지 않는다면, 서버는 새 약속이 존재하는 척하지 않습니다. RFC 2543 호환 절차로 후퇴하여 적용 가능한 범위에서 Request-URI, 태그, Call-ID, CSeq, 최상위 Via를 비교합니다. 프로토콜은 두 호환 집합을 혼동하지 않으면서 유지했습니다.

응답 매칭에는 최상위 Via branch와 CSeq 메서드를 사용합니다. 메서드가 필수인 이유는 CANCEL이 자신이 겨냥한 branch를 공유하면서도 별개의 트랜잭션을 이루기 때문입니다. 토큰 매칭은 검색 범위를 좁힐 뿐, 주변 필드의 의미를 지우지 않습니다.

RFC 3665의 예시들은 이 계층 구조를 보여줍니다. 각 프록시는 나가는 경로에 자신의 Via와 branch를 추가하고, 응답이 돌아오면서 대응하는 값이 제거됩니다. 이 식별자는 하나의 인접 클라이언트-서버 트랜잭션에만 지역적인 것이지, 호출의 전역 이름이 아닙니다.

같은 시도는 같은 branch를 재현해야 합니다

상태 저장 프록시는 나가는 시도마다 새 branch를 부여합니다. 한 대상이 실패하고 프록시가 다른 주소를 시도하면, 그 시도는 새 클라이언트 트랜잭션이므로 다른 토큰이 필요합니다. 요청이 처리 입력이 바뀐 뒤 프록시로 되돌아오면 그것은 루프가 아니라 정당한 스파이럴일 수 있습니다. 루프 감지를 수행하는 구현은 그 입력들을 branch의 분리 가능한 구성 요소에 담을 수 있습니다.

재전송은 정반대 경우입니다. 같은 시도의 또 다른 복사본이므로 같은 branch를 실어야 서버가 기존 상태를 찾아 요청을 다시 실행하는 대신 저장된 응답을 다시 보낼 수 있습니다.

이것은 상태 비저장 프록시에 미묘한 제약을 만듭니다. 상태 비저장 프록시는 어느 패킷이 재전송인지 알려주는 표를 유지하지 않습니다. 수신할 때마다 새 무작위성을 만들면 하나의 트랜잭션이 여러 개로 쪼개집니다. 그래서 RFC 3261은 상태 비저장 branch의 안정 부분을 재전송 간에 변하지 않는 요청 필드와 구성에서 도출하도록 요구합니다. 고유성과 재현성은 함께 충족되어야 합니다.

CANCEL은 완료를 공유하지 않으면서 식별자를 재사용했습니다

CANCEL은 같은 홉바이홉 경로를 따라 정확히 대기 중인 요청을 찾아야 합니다. 그 요청의 Request-URI, Call-ID, 태그, CSeq 번호, 최상위 Via, branch를 복사하되 CSeq 메서드만 CANCEL로 바꿉니다. 그 결과 상태 비저장 프록시도 같은 전달 선택을 내릴 수 있습니다.

그러나 CANCEL은 자체적으로 하나의 트랜잭션입니다. 서버는 CANCEL에 200으로 답하면서, 원래 INVITE는 별도로 487이나 다른 최종 응답, 또는 이미 경쟁에서 이긴 응답으로 끝날 수 있습니다. 취소 요청의 성공은 CANCEL이 매칭되어 처리 대상으로 받아들여졌다는 것을 증명할 뿐, 원래 트랜잭션의 결과를 소급적으로 다시 쓰지는 않습니다.

RFC 3261은 RFC 2543이 뒤섞었던 두 가지를 명시적으로 분리했습니다. 따라서 branch의 재사용은 상관관계이지 운명 공유가 아닙니다.

ACK는 최종 응답 등급에서 갈라졌습니다

비-2xx 최종 응답에 대한 ACK는 INVITE 트랜잭션 안에 남습니다. INVITE의 최상위 Via와 branch를 반복하고 메서드를 ACK로 바꾸며, 트랜잭션 상태 머신이 흡수합니다. 그 실패를 처리한 프록시 체인이 그 확인 응답도 처리합니다.

2xx 응답은 다릅니다. 하나의 포크는 두 개 이상의 수락된 다이얼로그를 만들 수 있고, 모든 성공은 호출자에게 도달해야 합니다. 이런 응답을 확인하는 것은 각 프록시 트랜잭션이 아니라 사용자 에이전트 코어이며, 종단 간에 이뤄집니다. 2xx ACK는 원래 INVITE 트랜잭션 밖에 있고, 새로 만든 Via branch로 다이얼로그 경로를 따릅니다.

이 분리는 의례적이지 않습니다. 부정 응답의 branch를 재사용하면 기존 홉이 하나의 실패에 대한 재전송을 억제할 수 있습니다. 성공에는 새 교환을 만들면 중간 트랜잭션이 다른 수락된 목적지를 감추는 일을 막을 수 있습니다.

이후의 수정은 수명을 바꿨을 뿐, 식별을 바꾸지 않았습니다

트랜잭션 식별이 상태 머신의 모든 결함을 해결하지는 못했습니다.RFC 4320은 비-INVITE 응답 및 타임아웃 동작을 고쳤습니다.RFC 6026은 이후 Accepted 상태와 Timer L을 추가하여 서버가 2xx를 보낸 뒤에도 충분한 INVITE 트랜잭션 상태를 유지해 재전송을 흡수할 수 있게 했습니다.

RFC 6026은 또한 branch에 RFC 3261 쿠키가 없는 레거시 ACK에 대한 특별 처리를 유지했습니다. 이 세부 사항은 표식의 지속적 역할을 확인해 줍니다. 상태 수명은 고칠 수 있어도, 수신자는 여전히 송신자가 실제로 어떤 식별 전제를 제공했는지 알아야 합니다.RFC 5359는 branch 관례를 사용하는 이후 서비스 흐름을 문서화합니다. 이는 명세된 운용 문법의 증거이지 구현 분포에 대한 조사가 아닙니다.

이 표식이 결코 증명하지 않은 것

누구나z9hG4bK를 타이핑할 수 있습니다. 이 접두어는 사용자를 인증하지 않고, 호출을 승인하지 않으며, 메시지 무결성을 보호하지 않고, branch의 나머지 부분이 고유하다는 것을 증명하지도 않습니다. TLS는 홉을 보호할 수 있고, 다이제스트 인증은 자격 증명 주장을 확립할 수 있으며, 애플리케이션 정책이 요청 수락 여부를 결정할 수 있습니다. 그 어느 것도 쿠키의 책임이 아닙니다.

또한 트랜잭션은 다이얼로그가 아닙니다. Call-ID와 태그가 다이얼로그 관계를 식별합니다. 경로 집합은 이후 요청을 안내합니다. 미디어 협상과 RTP에는 각자의 상태가 있습니다. 올바른 branch 매칭이 증명하는 것은 수신된 하나의 메시지가 매칭 규칙이 선택한 로컬 트랜잭션 상태에 속한다는 것뿐입니다.

역사적 성과는 더 좁지만 더 오래갑니다. SIP는 모든 수신자가 기관적 지위나 주변 동작에서 그 변화를 추론하게 하지 않으면서 한 필드의 계약을 바꿨습니다. 눈에 보이는 일곱 글자가 실행 가능한 규칙을 선택했고, 그 규칙은 자신이 실제로 검증할 수 있는 경계에서 멈췄습니다.

출처와 근거의 한계

닫힌 근거 집합은RFC 2543,RFC 3261,RFC 3665,RFC 4320,RFC 5359,RFC 6026으로 이루어집니다. 이들은 프로토콜 역사, 매칭 규칙, 예시 및 이후의 수정을 확립합니다. 그러나 현재의 배포 점유율, 제품 적합성, 통화 품질, branch 충돌의 부재는 확립하지 않습니다.