요약

  • PRACK는 식별된 신뢰성 임시 응답 하나에 대한 확인을 보낸다. PRACK에 대한 2xx 응답은 원래 INVITE에 대한 최종 2xx 응답이 아니다.
  • RSeq와 RAck는 오퍼/앤서가 최종 처리보다 먼저 진행되더라도 트랜잭션 식별성과 순서를 보존한다. 신호 수신이나 협상된 매개변수가 미디어가 실제 사람에게 도달했음을 증명하지는 않는다.

통화 중간에 사라진 수신 확인

RFC 3261은 INVITE에 의도적으로 긴 수명을 부여한다. 사용자 에이전트가 최종 2xx로 수락하거나, 리디렉션하거나, 거절하기 전에 진행 상황을 알리기 위해 하나 이상의 1xx 응답을 보낼 수 있다. 101에서 199 사이의 응답은 초기 다이얼로그(early dialog)를 만들 수 있다. 그러나 기본 사양에서는 이러한 임시 응답이 신뢰성 있게 전달되지 않는다.

임시 응답이 단순한 벨소리 표시 이상을 담을 때 이 한계는 문제가 된다. 공중전화망과의 상호 운용에서 초기 응답은 다이얼로그 상태를 설정하거나, 안내 방송을 지원하거나, 최종 결정 이전에 필요한 세션 기술서를 전달할 수 있다. 이를 잃는다고 해서 통화의 최종 성공 여부가 결정되는 것은 아니다. 그러나 다음 교환이 의존하는 상태를 제거할 수는 있다.

RFC 3262는 이 좁은 문제를 위해100rel옵션 태그와 PRACK 메서드를 도입했다. INVITE가Supported: 100rel을 광고하면 UAS는 100이 아닌 임시 응답을 신뢰성 있게 보낼 수 있다. INVITE에Require: 100rel이 있으면 UAS는 반드시 그렇게 하거나 해당 확장 요구를 거절해야 한다. 이 메커니즘은 100 Trying에는 적용되지 않는다. 100 Trying은 홉별(hop-by-hop) 응답인 반면, 신뢰성 임시 응답은 종단 간에 작동하기 때문이다.

일반적인 생존 신호가 아니라 좌표

신뢰성 임시 응답은Require: 100rel과RSeq번호를 담는다. 첫 번째 번호는 RFC 3262가 지정한 범위에서 선택되며, 그 시퀀스 공간은 하나의 트랜잭션에 속한다. 서로 관련 없는 INVITE에서 같은 RSeq 값이 나타난다고 해서 같은 응답을 식별하는 것은 아니다.

UAS는 T1부터 지수 백오프로 응답을 재전송한다. PRACK는 일치할 때만 이 전송을 멈춘다. PRACK 요청은 같은 다이얼로그 안에 있어야 하며,RAck은 응답에서 복사한 세 개의 좌표, 즉 RSeq 값, 원래 CSeq 번호, CSeq 메서드를 담는다. 따라서 이 수신 확인은 "이 통화에서 무언가 일어났다"가 아니라 "이 트랜잭션의 이 임시 응답"을 의미한다.

PRACK가 미확인 신뢰성 임시 응답과 일치하면 UAS는 PRACK에 2xx를 돌려보내고 해당 응답을 미확인 목록에서 제거한다. 일치하는 응답이 없으면 481을 돌려보낸다. 이 동사의 목적어가 본질적이다. 2xx는 PRACK 트랜잭션이 성공했다고 말할 뿐이다. INVITE에 응답하는 것은 아니며, INVITE의 최종 수락·리디렉션·거절은 별도의 행위로 남는다.

PRACK는 ACK와 비슷한 역할을 하지만 임시 형태의 ACK는 아니다. PRACK는 자신의 CSeq, 자신의 응답, 그리고 상태 추적 프록시를 통한 홉별 트랜잭션 신뢰성을 갖는 평범한 다이얼로그 내 비INVITE 요청이다. 바로 이 독립성 덕분에 SIP는 중간 수신 확인에 최종적 의미를 부여하지 않으면서도 검증 가능하게 만든다.

신뢰성에는 시퀀스 규율이 포함되어 있었다

PRACK 확인은 누적되지 않는다. 혼잡 제어를 위해 RFC 3262는 신뢰성 임시 응답을 한 번에 하나만 미확인으로 두고, 두 번째를 보내기 전에 첫 번째가 확인되도록 요구한다. 이후 RSeq 값은 정확히 1씩 증가하며 순환하지 않는다.

UAC는 다이얼로그 ID, CSeq, RSeq로 재전송을 식별한 뒤 내용을 두 번 처리하지 않고 중복을 버린다. 기대값보다 나중 RSeq가 먼저 도착하면 그것을 확인하거나 처리해서는 안 된다. 구현은 갭이 메워지길 기다리며 그것을 캐시할 수 있다. 여기서 신뢰성이란 트레이스에 언젠가 나타나는 것이 아니라 올바른 항목이 올바른 순서로 도착하는 것이다.

일치하는 PRACK가 64*T1 동안 도착하지 않으면 UAS는 원래 요청을 5xx 응답으로 거절해야 한다. 이 확장은 침묵 속 손실을 관찰 가능한 상태로 바꾸지만, 그 상태에는 비용이 따른다. 이제 타이머, 다이얼로그 경로, 시퀀스 메모리, 미확인 목록, 인증이 각각 독립적으로 실패할 수 있다. 표준은 동작을 규정할 뿐, 실제 네트워크가 얼마나 널리 그리고 얼마나 올바르게 이를 구현하는지는 측정하지 않는다.

초대장이 답을 기다리는 동안 오퍼는 답변될 수 있다

PRACK는 본문을 담을 수 있다. INVITE에 오퍼가 있었다면 신뢰성 임시 응답이 앤서를 담을 수 있다. INVITE에 오퍼가 없었다면 신뢰성 임시 응답이 오퍼를 제공할 수 있고 PRACK는 앤서를 담아야 한다. PRACK가 추가 오퍼를 담고 그 앤서가 PRACK에 대한 2xx에 담기는 것도 가능하다.

따라서 세션 매개변수는 원래 INVITE가 최종 응답을 받기 전에 사용 가능해질 수 있다. 오퍼/앤서 완료와 초대장 처리가 서로 다른 상태 기계이기 때문에 이는 모순이 아니다. RFC 3262는 이 의존 관계를 명시한다. 미확인 신뢰성 임시 응답이 세션 기술서를 담고 있었다면, UAS는 그 응답이 확인될 때까지 INVITE에 대한 최종 2xx 수락을 지연해야 한다. 이 규칙은 오퍼/앤서 교환의 무결성을 보호한다. PRACK을 통화의 최종 답변으로 임명하는 것은 아니다.

RFC 6337은 이후 그 결과로 나타난 조합들을 문서화했다. 양쪽 사용자 에이전트가100rel을 지원하더라도 모든 임시 응답을 신뢰성 있게 보낼 필요는 없다. INVITE에 이미 오퍼가 있을 때, 신뢰성 있는 비실패 응답의 첫 번째 SDP가 실제 앤서이며, 그 이전의 신뢰성 없는 임시 응답의 SDP는 미리보기로만 취급될 수 있다.

RFC 3311은 UPDATE를 추가하여 초기 또는 확정된 다이얼로그에서 세션 매개변수가 변경될 수 있게 했다. 이는 메서드를 합치지 않고 오퍼/앤서를 수행하는 또 다른 경로를 제공한다. INVITE, PRACK, UPDATE는 각자 별도의 요청, CSeq 값, 응답, 미결 상태를 유지한다. 구현은 어느 교환이 완료되었고 어느 교환이 아직 대기 중인지 알아야 한다.

오디오 경로는 신호 수신 확인에 서명할 수 없다

RFC 3960은 최종 응답 이전의 링백, 안내 방송, 대화형 톤 같은 초기 미디어(early media)를 다룬다. SIP 신호와 미디어는 느슨하게 결합되어 있다. 서로 다른 경로를 따라 다른 순서로 관찰될 수 있으며, 그것을 설명할 신호보다 미디어가 먼저 나타날 수도 있다.

결과적으로 PRACK는 RTP 패킷이 도착했는지, 안내 방송이 들렸는지, 착신자가 응답했는지를 증명하지 않는다. 안내 방송이 들렸다고 해서 올바른 RSeq가 올바른 RAck를 받았음이 증명되지 않는다. 운영팀은 두 타임라인을 상호 연관시킬 수 있지만, 어느 쪽도 다른 쪽을 대신할 권한은 없다.

IANA 세션 시작 프로토콜 매개변수 레지스트리는 PRACK,RAck,RSeq,100rel을 RFC 3262를 참조로 등재한다. 이것은 공식 할당과 출처 권위를 확립한다. 배포 비중, 벤더 적합성, 특정 통화의 성공적 처리를 확립하는 것은 아니다.

시퀀스 일치가 발신자를 인증하지도 않는다. RFC 3262는 공격자가 PRACK을 주입해 중요한 임시 정보의 재전송을 조기에 중단시킬 수 있다고 경고한다. PRACK은 다른 요청처럼 인증되어야 한다. 올바른 상태 좌표와 신뢰할 수 있는 신원은 별개의 검사다.

이 확장의 지속적 성과는 벨소리를 응답처럼 만든 것이 아니었다. 더 좁은 주장을 자신 있게 할 수 있게 한 것이다. 즉, 이 임시 상태가 도착했으며, 아마도 다른 교환이 진행될 수 있게 하는 정보를 담고 있고, 초대장 자체는 여전히 결정되지 않았다는 것이다.

출처