요약

  • RFC 3327은 프록시가 REGISTER 중에 순서가 지정된 Path를 추가할 수 있도록 했습니다. 등록이 성공하면 등록 서버는 해당 벡터를 AOR/Contact 바인딩에 연계하여 반환했습니다.
  • 홈 프록시는 나중에 저장된 벡터를 해당 Contact로 향하는 요청의 Route 헤더에 복사할 수 있었습니다. 이 벡터는 미래 라우팅 지시이지, REGISTER 패킷이 실제로 거친 경로의 증거가 아니었습니다.

Contact는 알려져 있었다. 돌아가는 경로는 아니었다.

SIP 등록 서버는 사용자 에이전트(UA)에 연락 가능한 주소를 저장할 수 있습니다. 이 바인딩은 좁은 질문에 답합니다. 이 주소-of-record로 오는 요청은 어떤 Contact가 받아야 하는가? 하지만 반드시 다른 질문에는 답하지 않습니다. 그 Contact에 도달하려면 요청이 어떤 중간 프록시들을 거쳐야 하는가?

이 간극은 등록이 홈 프록시가 DNS나 자체 라우팅 테이블로는 재구성할 수 없는 엣지 프록시를 거칠 때 드러납니다. UA는 방문 네트워크를 통해 등록할 수 있고, 등록 서버는 다른 곳에 있을 수 있으며, 이후 들어오는 요청은 Contact URI에서는 명백하지 않았던 프록시 노드들을 다시 거쳐야 할 수 있습니다. 2002년 12월에 공개된 RFC 3327은 그러한 노드들이 등록 교환 과정에서 경로 벡터를 남길 방법을 제공했습니다.

“Path”라는 단어 때문에 이 헤더가 측정 도구처럼 들릴 수 있습니다. 그러나 그 역할은 달랐습니다. REGISTER가 거치는 프록시는 Path 값을 추가할 수 있었습니다. 등록 서버는 순서가 지정된 값들을 Contact 및 AOR 바인딩과 함께 보존한 뒤, 성공한 REGISTER 응답에 이를 반영했습니다. 나중에 그 바인딩을 조회한 홈 프록시는 저장된 벡터를 미리 적재한 Route 헤더에 넣어 새 요청을 이 프록시들로 보낼 수 있었습니다. 이 기억은 바인딩에 속한 것이었으며, REGISTER 트랜잭션의 패킷 캡처가 아니었습니다.

트랜잭션을 넘어 살아남는 경로

Path는 Record-Route와 비슷하지만, 두 수명은 다릅니다. Record-Route는 그것을 만든 다이얼로그 내부의 요청들에 대한 라우팅을 확립합니다. Path는 REGISTER와 그 성공 응답에 담겨 프록시 시퀀스를 이후 다이얼로그에 사용할 수 있게 합니다. RFC 3261의 기존 라우팅 기계가 Route 동작을 제공하고, RFC 3327은 그 시퀀스를 등록 경계를 넘어 운반합니다.

이것은 보편적이 아니라 범위가 한정된 기능이었습니다. 이 메커니즘은 사용자의 홈 도메인을 통과하거나 그곳에서 시작되는 요청에 적용되었습니다. 값은 Route 요소 문법을 따르고 loose-routing;lr매개변수를 사용했습니다. UA는Supported: path로 지원을 광고할 수 있었고, 프록시는 일반적으로 UA가 지원을 표시하지 않았다면 Path를 추가해서는 안 됩니다. 등록 서버가 그 표시 없이 Path를 받았다면 RFC는 거절을 권고했지만 로컬 정책의 여지를 남겨 두었습니다.

중요한 역사적 전환은 SIP가 모든 패킷이 어디를 갔는지 알게 되었다는 것이 아니었습니다. 등록이 이후 들어오는 요청을 지배할 바인딩에 라우팅 맥락을 부착할 수 있는 지점이 된 것입니다. 등록 서버의 응답은 그 Path를 UA에도 반환했기 때문에, 추가된 프록시들은 보편적 토폴로지 데이터베이스로 조용히 변환되는 것이 아니라 점검 가능한 형태로 드러났습니다.

벡터는 목격자가 아니다

RFC 3327은 토폴로지를 인식하는 프록시가 REGISTER가 실제로 거친 경로와 일치하지 않더라도 다른 노드를 참조하는 Path 값을 추가할 수 있음을 명시적으로 허용했습니다. 이 선택이 결정적입니다. Path는 프록시와 등록 서버 정책 아래에서 조립된 순서가 지정된 경로 처방이지, 패킷 통과에 대한 법증이 아닙니다. 그것만으로 어떤 프록시가 이전 메시지를 전달했는지, 제안된 경로가 도달 가능한지, 미래의 통화가 전달될 것인지를 입증할 수 없습니다.

같은 선택이 보안 경계를 만들었습니다. 저장된 벡터에 삽입된 프록시는 미래 요청에 배치되어 통화를 가로챌 수 있었습니다. 그래서 RFC 3327은 TLS나 IPsec 같은 전송 무결성과 상호 인증을 논의했고, UA가 반환된 Path의 변경을 감지할 수 있도록 보호된 S/MIME 사본을 기술했습니다. 문법적으로 유효한 URI가 승인된 중계자와 동일한 것은 결코 아니었습니다.

이후의 작업은 이 메커니즘을 더 좁은 목적으로 재사용했습니다. RFC 5626은 Path에 고유한 flow token을 넣어 엣지 프록시가 미래 요청을 클라이언트가 시작한 특정 연결로 매핑할 수 있게 합니다. 이 흐름별 동작은 후속 확장에 속하며, 모든 RFC 3327 경로 벡터에 투사되어서는 안 됩니다. RFC 3608의 Service-Route는 반대 방향을 가리키며, UA에 들어오는 요청의 경로가 아니라 UA 자신의 발신 요청을 위한 경로를 제공합니다.

출처