요약

  • SIP Outbound는 프록시가 사용자 에이전트가 이미 열어 둔 플로를 통해 새 요청을 전달할 수 있게 했다. 서버가 NAT나 방화벽 너머로 새 인바운드 연결을 만들어 낼 필요는 없었다.
  • 여러 등록이 동일한 사용자 에이전트 인스턴스로의 서로 다른 경로를 나타낼 수 있었다. 따라서 서비스는 모든 바인딩을 별도의 수신자로 세는 대신 계정, 인스턴스, 교체 가능한 각 플로를 구분해야 했다.
  • 430 응답은 실패한 플로를 식별했고, 해당 인스턴스의 다른 경로를 시도할 근거가 될 수 있었다. 그 밖의 최종 응답은 일반적으로 인스턴스가 이미 응답했음을 뜻하며, 같은 요청은 중단되어야 했다.

장애를 먼저 알게 된 것은 발신 측이었다

RFC 5626의 9.3절은 의도적으로 불편한 순서를 제시한다. 한 전화기가 두 개의 엣지 프록시를 통해 등록했다. 한 엣지가 다운되어 재시작한다. 전화기 자신의 킵얼라이브 절차가 그 손실을 감지하기 전에, 그 전화기로 향하는 새 INVITE가 도착한다.

재시작된 엣지에는 저장된 토큰이 가리키는 플로가 더 이상 존재하지 않는다. 그 엣지는430 Flow Failed를 반환한다. 주소 레코드(AOR)를 담당하는 프록시는 오래된 바인딩을 제거하고, 같은 계정과 사용자 에이전트 인스턴스에 대해 다른 reg-id로 구분되는 또 다른 등록을 선택한다. 두 번째 엣지가 요청을 받아 새 다이얼로그를 라우팅할 수 있다. 전화기는 첫 번째 등록을 나중에 복구한다.

이것은 사양의 예시이지, 통신사 장애에 대한 보고도 측정된 복구 시간도 아니다. 이 문서는 모든 기존 다이얼로그가 끊김 없이 마이그레이션할 것을 보장하지 않는다. 다이얼로그 도중의 개별 엣지 절차는 문서의 필수 알고리즘 밖에 두었다. 그러나 그 좁은 요점은 여전히 중요하다. 발신 측은 전화기가 같은 장애를 로컬에서 발견하기를 마치기 전에, 하나의 전달 경로가 죽었음을 알아낼 수 있다는 점이다.

이는 다른 경로를 시도할 정당한 이유가 된다. 그렇다고 두 번째 수신자가 생기는 것은 아니다. 대체 바인딩은 같은 전화기에 속하며, 양쪽이 장애에 대해 서로 다른 지식을 가진 상태에서도 규칙은 이 사실을 지켜야 한다.

등록은 Contact를 도달 가능하게 만든 적이 없었다

원래의 SIP 등록 모델은 주소 레코드(AOR)를 하나 이상의 Contact에 연결했다.RFC 3261에서 등록 서버(registrar)는 이 바인딩들을 수락했고, 위치 서비스가 이를 이후 요청을 라우팅하는 프록시가 사용할 수 있게 했다. 등록 서버와 프록시는 별개의 기능일 수도, 하나의 시스템 일부일 수도 있었다.

REGISTER에 대한 응답은 요청을 실어 온 신뢰 가능한 연결로 돌아갈 수 있었다. 단, 그 연결이 열려 있는 동안에만 그렇다. 그러나 이후의 INVITE는 그 REGISTER에 대한 또 다른 응답이 아니었다. 그것은 반대 방향으로 나가는 새 요청이었다. NAT나 방화벽 뒤의 전화기는 서버가 시작하는 새 연결을 수락할 수 없으면서도 아웃바운드 TCP나 TLS 연결을 열 수 있었다. 형식적으로 저장된 Contact가 그 경계를 뚫는 내구성 있는 통로를 만들어 주지는 않았다.

Outbound는 사용자 에이전트가 수립한 플로를 사용했다. TCP에서 플로는 연결이었다. UDP에서는 주소, 포트, 전송 프로토콜로 식별되는 양방향 데이터그램 연관이었다. 이 설계를 영속 TCP만으로 환원하면 UDP 사례와 더 깊은 규칙을 모두 놓치게 된다. 전달은 등록된 엔드포인트로의 알려진 연관에 의존했으며, 시험되지 않은 역방향 연결을 나중에 열 수 있으리라는 희망에 의존하지 않았다.

이 구분은 큰 메시지가 전송 방식 전환을 필요로 할 때도 중요했다. 문서의 운영 논의는 서버가 전화기가 수립한 적 없는 새 인바운드 TCP 연결로 UDP를 단순히 대체할 수 없다고 지적했다. 적합한 Outbound 플로가 먼저 존재해야 했다. 이는 모든 큰 UDP 요청이 실패하거나 모든 배포가 모든 전송 방식을 열어 두어야 한다는 주장이 아니었다. Contact를 완전한 경로처럼 다룰 때 드는 비용을 드러낸 것이다.

Path는 플로가 어디로 들어왔는지를 기억했다

등록 서버가 반드시 전화기의 첫 SIP 홉인 것은 아니었다. 엣지 프록시가 REGISTER를 홈 도메인으로 전달할 수 있고, 이후 요청은 그 엣지를 다시 거쳐 돌아와야 했다.RFC 3327은 이를 위해 Path를 도입했다. 중간 노드들은 등록 과정에서 자신을 추가했고, 그 결과물인 벡터는 바인딩과 함께 저장되어 이후 홈 도메인을 거치는 요청에 미리 적재된 Route로 사용되었다.

Path는 REGISTER에 적용된 Record-Route가 아니었다. REGISTER는 여전히 다이얼로그를 만들지 않았다. Path가 임의의 상대가 부과할 수 있는 보편적 경로도 아니었다. Path는 홈 도메인의 라우팅 및 신뢰 정책 안에서 작동했으며, 이것이 무결성 보호와 인증된 등록과의 관계를 필수적으로 만들었다.

Outbound는 첫 엣지에서 빠져 있던 정밀성을 채웠다. 엣지는 보호된 플로 토큰과ob표시를 삽입하여 전화기로의 특정 연관을 다시 찾을 수 있게 했다. 토큰은 장치나 사람의 영구적 이름이 아니었다. 엣지가 하나의 플로를 찾는 데 쓸 수 있는 것이었다.

이 로컬 범위는 재시작과 자원 재사용 이후에 중요했다. 오래된 파일 디스크립터 번호를 물려받은 새 연결이 곧 옛 수신자의 연결이 되지는 않았다. 네트워크가 어떤 플로가 더 이상 전달하지 않음을 확정하면—예컨대 TCP 종료나 해당하는 UDP 오류를 통해—그 플로에 붙은 바인딩은 무효화되어야 했다. 재활용된 좌표가 오래된 권한을 조용히 상속할 수는 없었다.

하나의 식별자는 지속되고, 다른 하나는 경로를 표시했다

여러 플로에는 두 종류의 식별이 필요했다.instance-id는 사용자 에이전트 인스턴스를 명명했고 재시작이나 네트워크 변경을 넘어 지속되었다.reg-id는 그 인스턴스의 동시 플로 등록들을 구분했다. 의미 있는 바인딩 키는 AOR, instance-id, reg-id를 함께 모았다.

재시작 시 전화기는 reg-id 값의 순서를 의도적으로 재사용했다. 많은 시스템에서 숫자 충돌을 피하는 편이 더 안전해 보인다. 그러나 여기서 옳은 충돌이 곧 정리 메커니즘이었다. 같은 논리적 경로 위치에 대한 새 등록이 오래된 상태를 대체했고, 가상의 추가 목적지로서 그 옆에 쌓이지 않았다.

Contact는 여전히 저장되었고 대상 집합을 구성하는 데 여전히 도움이 되었다. 무의미해진 것은 아니었다. 그러나 Contact 텍스트만으로는 바인딩의 식별을 더 이상 운반하지 않았다. 프록시는 같은 AOR과 instance-id에 대해 대상 집합에 한 번에 두 개 이상의 Contact를 넣는 것이 금지되었다. 하나의 AOR을 공유하는 별개의 장치는 가능했고, 상황에 맞다면 일반적인 SIP 포킹도 가능했다. 한계는 더 좁았다. 하나의 인스턴스로의 대체 플로를 같은 시도에서 독립적인 수신자로 계산할 수는 없다는 것이었다.

따라서 등록 서버의 두 개 행이 두 대의 전화기를 증명하지 않았다. 두 사람, 두 고객, 두 개의 독립적인 장애 도메인을 증명하지도 않았다. 그 행들은 계정, 인스턴스, 플로 관계를 함께 읽어야만 의미를 갖는 카디널리티를 지닌 상태를 기록한 것이었다.

430 응답은 경로에 속했다

엣지가 요청된 플로를 찾지 못하면430 Flow Failed로 답해야 했다. 같은 AOR과 instance-id에 대해 다른 reg-id를 가진 또 다른 바인딩이 존재하면, 담당 프록시는 그것을 시도해야 했다. 다운 후 재시작 순서가 보여주는 정확한 복구가 바로 이것이다.

이 코드는 계정, 사람, 통화 미디어에 대한 판정이 아니었다. 엣지와 권위 있는 프록시 사이에서 하나의 경로에 대해 전달되는 정보였다. 엔드포인트는 430을 받도록 의도되지 않았고, 받게 되면 400으로 다루어야 했다. 수정된 플로 토큰은 별도의 응답을 요구했으며 403이 권고되었다. 이 조건들을 일반적인 "네트워크 오류"로 뭉뚱그리면, 한 경우에는 제어된 페일오버가 안전하고 다른 경우에는 부적절한 이유를 버리게 된다.

같은 주의가 과장된 가용성 주장을 막는다. 이 예시는 새 요청 하나를 알려진 오래된 경로 하나로부터 구해 낸다. 모든 다이얼로그의 끊김 없는 생존, 보장된 종단 간 전달, 특정 가동률 수치를 확립하지는 않는다. 프로토콜은 근거의 인계를 정의할 수 있지만, 모든 제품이 그것을 얼마나 충실히 사용하는지는 증명하지 않는다.

다른 경로가 이미 도착한 응답을 뒤집을 수는 없었다

Outbound에서 가장 덜 극적인 규칙이 아마도 가장 중요한 규칙이다. 408이나 430 이외의 최종 응답 이후에는, 프록시가 같은 요청을 같은 AOR과 instance-id를 대표하는 다른 대상으로 전달해서는 안 된다. 인스턴스가 이미 응답한 것이다. 두 번째 등록된 경로가 그 응답을 잠정적인 것으로 만들지 않는다.

예외와 범위는 설명 안에 들어 있다. 이는 모든 미래의 통화, 모든 프로토콜의 모든 재시도, 진짜로 구별되는 장치로의 포킹을 금지한 것이 아니었다. 같은 인스턴스로의 대체 경로 사이를 이동하는 같은 요청을 제약한 것이다. 실패한 플로는 또 하나의 전달 시도를 정당화할 수 있었다. 최종 응답은 일반적으로 그렇지 못했다.

이 정지 규칙이 없다면, 이중화는 복구와 지속을 혼동할 것이다. 거절, 완료, 또는 다른 최종 결정이 같은 전화기에 다시 닿을 이유로 다루어질 수 있었다. 서비스는 더 많은 경로를 갖지만 상태에 대한 존중은 줄어들 것이다. 복원력에는 두 종류의 지식이 필요했다. 무엇이 실패했는지, 그리고 무엇이 이미 응답했는지.

킵얼라이브와 등록은 별개의 시계로 움직였다

등록의 수명과 플로의 건강은 서로 교환 가능한 것이 아니었다. 503 같은 복구 가능한 갱신 오류가, 핑에 계속 응답하는 신뢰 가능한 연결을 반드시 닫게 할 필요는 없었다. 전송을 유지하는 것이 바인딩을 불멸로 만들지는 않았다. 그것은 등록 절차가 별개의 장애를 처리하는 동안 자원을 보존한 것이다.

UDP에서는 그 역도 가능했다. STUN 응답이 도착하면서 변경된XOR-MAPPED-ADDRESS를 보고할 수 있었다. 그 경우 응답을 받았다는 사실이 곧 오래된 연관이 실패했음을 보여주었다. 매핑된 주소나 포트가 더 이상 등록된 것이 아니었기 때문이다. 이 용도의 STUN에는 명시적인 다음 홉 지원이 필요했다. "NAT를 처리한다"는 일반적 약속으로는 충분하지 않았다.

킵얼라이브는 다음 SIP 홉까지 작동했다. 사용자가 INVITE를 받았는지, 응용이 그것에 대해 작동했는지, 오디오 미디어가 흘렀는지는 확인하지 않았다. Flow-Timer는 여유를 둔 기대 킵얼라이브 간격을 표현했을 뿐, 그 기간 내내 전달을 보장하는 임대가 아니었다. 짧은 간격은 배터리와 서버 부하를 대가로 감지를 개선했고, 여러 플로는 자체 상태를 추가하면서 노출을 줄였다.

RFC 6223은 이후 Via의keep매개변수를 사용한 인접 홉 단위, 방향별 협상을 정의했다. 이 문서는 명시적으로 연결 재사용을 정의하지 않았다. 이웃 경로를 응답 가능하게 유지하는 것과, 그 경로 위에서 미래의 역방향 요청을 승인하는 것은 여전히 서로 다른 작업이었다.

인접 확장은 각자의 경계를 유지했다

RFC 5923은 양방향으로 연결을 시작할 수 있는 SIP 이웃 사이의 TLS 연결 별칭을 다루었다. 인증과 수락하는 서버의 채널 재사용 결정은 여전히 중심에 있었다. 열려 있는 TLS 소켓이 임의의 역방향 트래픽을 자동으로 승인하지는 않았다. 연결 방향이 제약되는 곳에서는 문서의 적용성 논의가 Outbound로 되돌아가게 했다.

RFC 5627은 또 다른 문제를 풀었다. 특정 사용자 에이전트 인스턴스를 선택하는 URI를 제3자에게 어떻게 줄 것인가. 그 무조건 전송 예시에서, 의도된 대상은 이미 관여 중인 그 수신기인데도 AOR로의 통화는 다른 장치나 음성사서함에 닿을 수 있었다. GRUU는 외부에서 사용할 수 있고 도메인이 중재하는 인스턴스 대상을 제공했다. 그것은 엣지의 플로 토큰이 아니었으며, 어느 하나의 플로가 여전히 살아 있음을 증명하지도 않았다.

RFC 7118의 브라우저 시나리오는 이 구분들을 눈에 보이게 만들었다. JavaScript SIP 스택은 의미 있는 로컬 전송 주소를 알지 못할 수 있었다. Outbound 지원을 요청하고 받았을 때, 그 시나리오는 Via와 Contact에서.invalid아래의 무작위 이름을 허용했다. 들어오는 시그널링은 WebSocket 프록시와 기존 플로를 통해 돌아왔다. 이것은 이 시나리오의 조건부 부분이지, 사용 불가능한 Contact를 발행할 일반적 허가가 아니었다. 서버 인증서 검사는 여전히 적용되었고, 미디어 전송은 문서 밖에 있었다.

IANA SIP 매개변수 레지스트리는 관련된 이름, 응답 코드, 참조를 기록한다. 채택률을 측정하거나 구현을 인증하지는 않는다. 역사적 결과는 보편적인 가용성 주장보다 더 정확하다. 프로토콜은 수신자를 늘리지도, 수신자의 응답을 돌아가야 할 장애물로 다루지도 않으면서 여러 복귀 경로를 유지하는 방법을 갖추게 된 것이다.