요약

  • RFC 3428은 SIP 프록시가 하나의MESSAGE요청을 여러 가능한 단말로 포크할 수 있게 하면서, 발신자에게는 최종 응답 하나만 전달하도록 했습니다.
  • 그 응답은 발신자에게 포크가 발생했는지, 몇 개의 사용자 에이전트가 요청을 받았는지 알려줄 수 없으며, 누군가 그것을 읽었다는 증거도 아닙니다.

이 불일치는 프로토콜 모델에 내장된 것이며, 반드시 서비스 결함의 증거는 아닙니다. RFC 3428은 독립형, 호출기(pager) 방식의 인스턴트 메시지를 위해 SIP에MESSAGE를 추가했습니다. MESSAGE 요청 자체는 SIP 대화(dialog)를 수립하지 않습니다. 프록시는 SIP 규칙에 따라 이를 라우팅하고, 다운스트림 프록시는 수신자가 있을 수 있는 여러 기기로 요청을 포크할 수 있습니다.

이것은 하나의 트랜잭션에 대한 서로 다른 두 관점을 만듭니다. 메시지를 수신한 여러 브랜치가 성공 응답을 반환할 수 있습니다. 그럼에도 프록시는 상위로 최종 응답 하나만 전달합니다. RFC 3428은 사용자 에이전트 클라이언트가 이 포크가 발생했는지 감지할 방법이 없으며, 자신이 본 단일 응답만으로 하나의 사용자 에이전트만 요청을 받았다고 추론해서는 안 된다고 명시합니다. 발신자에게 보이는 응답 수는 수신자 수가 아닙니다.

상태 코드는 여전히 중요하지만, 다른 질문에 답합니다. 일반적인 최종 목적지의 경우200 OK는 발신 클라이언트가 그 목적지로의 전달을 가정할 수 있게 해주지만, 사용자가 내용을 보았거나 읽었다는 의미는 아닙니다. 사용자 에이전트는 응답하기 전에 메시지를 표시할 필요가 없습니다.202 Accepted는 더 약합니다. 게이트웨이, 저장 후 전달(store-and-forward) 서버 또는 다른 서비스가 이를 접수했지만, 최종 전달이 수립된 것은 아닙니다. 202 이후의 확인은 RFC 3428 외부의 별도 메커니즘이 필요합니다.

이 구분은 트레이스를 재구성할 때 유용합니다. 발신자 측에는 하나의 트랜잭션과 하나의 최종 응답이 있으면서 다운스트림 로그에는 여러 성공 브랜치가 기록될 수 있습니다. 이 기록들은 서로 모순되지 않습니다. 반대로, 단일 상위 200 응답만으로는 정확히 한 번의 전달, 수신 기기 수, 또는 사람의 확인을 확립할 수 없습니다. RFC 3428은 무엇이 일어날 수 있는지를 규정할 뿐, 특정 서비스가 메시지를 포크했거나 누군가 그것을 열었다는 사실을 보여주지 않습니다.

이 메서드는 좁은 상호작용 모델에 속했습니다. RFC는 각 MESSAGE를 독립적인 것으로 기술했으며, 겉으로 보이는 대화 묶음은 클라이언트 인터페이스나 사용자들이 제공하는 것으로 보았습니다. 이는 명시적 시작과 끝이 있는 세션 모델과 구분됩니다. 이후 RFC 8591이 SIP 메시징의 S/MIME 처리를 갱신하고 명확히 했지만, SIP 응답을 읽음 증거로 바꾸거나 여기서 살펴보는 포크 응답 회계 지점을 변경하지는 않았습니다.

출처: RFC 3428 2~8절; SIP 라우팅 및 프록시 동작은 RFC 3261; 이후 S/MIME 갱신은 RFC 8591. 전체 고정 출처 목록: