요약

  • RTP는 하나의 타이밍 및 시퀀스 번호 공간을 무작위로 선택된 32비트 SSRC 아래에 묶었지만, 이 식별자를 하나의 RTP 세션 범위로 한정했으며 영구적인 참여자 신원으로 만들지 않았다.
  • 자신의 SSRC가 이미 사용 중임을 감지한 소스는 이전 값에 대해 RTCP BYE를 보내고, 새 무작위 후보를 알려진 소스 목록과 대조한 뒤 교체 값으로 계속 전송했다.
  • 동일한 SSRC가 다른 전송 주소에서 도착하는 경우 충돌, 루프, NAT 리바인딩, 트랜슬레이터 재시작 또는 이동성을 의미할 수 있었다. CNAME과 토폴로지 증거가 소유자를 인증하지 않은 채 진단 범위를 좁혀 주었다.

하나의 번호가 서로 호환되지 않는 두 이력을 묶기 시작했다

수신자는 동기화 소스 식별자(Synchronization Source identifier)를 사용하여 어떤 RTP 패킷이 하나의 타이밍 및 시퀀스 번호 공간에 속하는지 판단한다. 두 개의 독립적인 발신자가 같은 SSRC를 선택하면, 그들의 시퀀스 번호, 타임스탬프, 수신 보고서, 소스 설명이 잘못된 이력에 붙을 수 있다. 한 출처의 오디오가 다른 출처의 불연속으로 보일 수 있다. 지터 버퍼는 결코 관련 없던 클록을 조정하라는 요청을 받을 수 있다.

원래 RTP 표준인RFC 1889는 이 식별자를 32비트로 정하고 소스의 네트워크 주소와는 독립적으로 만들었다. 멀티캐스트 회의에서, 그리고 트랜슬레이터나 믹서를 통과할 때 주소가 미디어 소스의 보편적인 이름이 될 수 없다는 점에서 이 분리는 중요했다. 대신 각 소스는 특정 RTP 세션 내부에서 고유할 것으로 의도된 무작위 SSRC를 선택했다.

무작위 선택은 진행 중인 회의 경로에서 중앙 할당 절차를 제거했다. 그러나 우연의 일치까지 제거하지는 못했다. 따라서 프로토콜은 충돌 복구를 불가능한 예외 사례가 아니라 일반적인 규격 준수의 일부로 다루었다.

낮은 확률은 복구를 생략해도 된다는 허가가 아니었다

RFC 3550은 이 설계를 유지하면서 확률 경계를 명시적으로 만들었다. 1,000개의 소스가 동시에 시작하여 32비트 범위에서 독립적으로 선택할 경우, 문서의 근사식은 적어도 하나의 충돌이 발생할 확률을10^-4정도로 제시한다. 이미 고유한 1,000개의 소스에 새 소스 하나가 합류할 때는 대략2×10^-7이다. 이는 할당 모델의 예시이며, 배포된 통화에 대한 측정값이 아니다.

이 문서는 또한 구현 세부 사항이 이 모델을 무너뜨릴 수 있는 이유를 설명한다. 로컬 IP 주소는 사설 네트워크, 트랜슬레이터 또는 한 호스트의 여러 소스를 넘어서는 충분한 고유성을 갖지 못한다. 시드되지 않은random()호출은 동시에 시작된 프로세스들이 같은 수열을 반복하게 만들 수 있다. 새 참여자는 전송 전에 수신 대기하고 이미 존재하는 SSRC를 살펴본 뒤, 필요하다면 첫 패킷 전에 다시 선택할 수 있다.

역사적 선택은 놓치기 쉽다. RTP는 번호가 절대 충돌하지 않으리라고 약속하지 않았다. 확률이 실패할 때 참여자들이 이를 인지하고 복구할 것이라고 약속했다.

미디어가 떠나기 전에 이전 레이블이 먼저 떠났다

소스 측 규칙은 짧다. 소스가 다른 소스가 자신과 같은 SSRC를 사용하고 있음을 발견하면, 이전 식별자에 대한 RTCP BYE 패킷을 보내고 다른 무작위 값을 선택한다. 교체 값은 먼저 로컬 소스 테이블에서 조회되며, 이미 사용 중이라면 다른 후보를 생성해야 한다.

여기서 BYE는 카메라, 마이크 또는 애플리케이션이 떠났다는 의미를 반드시 갖지는 않는다. 이는 하나의 동기화 레이블을 은퇴시킨다.RFC 7656은 나중에 이 결과를 직접 밝혔다. RTP 스트림은 임의의 시점에 하나의 SSRC를 가지지만, 그 SSRC는 시간이 지나며 바뀔 수 있고, 충돌은 그 유효한 이유 중 하나이다.

이 구분은 연속성을 보호한다. SSRC를 사람과 동일시하는 소비자는 거짓 퇴장과 거짓 도착을 보여줄 수 있다. 번호를 영구 키로 사용하는 아카이브는 하나의 스트림을 두 기록으로 쪼갤 수 있다. BYE를 계정 폐지로 처리하는 정책 엔진은 루틴한 네임스페이스 수리에 되돌릴 수 없는 조치를 적용할 수 있다.

수신자는 소유권을 부여하지 않고 패킷을 보존할 수 있었다

수신자가 다른 두 소스의 충돌을 목격하는 경우는 상황이 다르다. RFC 3550은 서로 다른 전송 주소 또는 RTCP CNAME이 충돌을 가시화해 주는 경우, 한 소스의 패킷은 유지하고 다른 소스의 패킷은 폐기하는 것을 허용한다. 충돌하는 소스들 자체는 서로 갈라지도록 기대된다.

따라서 처음 목격된 패킷이 일시적인 운영상 선호를 얻을 수 있다. 이는 수신자 정책이지, 첫 발신자가 SSRC를 소유한다는 판정이 아니다. 기존 소스가 나중에 교체 식별자로 이동하고 그 BYE가 이전 항목을 지우면, 이전에 억제되던 소스가 다시 가시화될 수 있다. BYE가 도착하지 않으면 시간 초과가 결국 수신자의 증거를 바꾼다.

소스 테이블은 번호 이상을 보존해야 한다. RTP와 RTCP는 서로 다른 UDP 소스 포트를 사용할 수 있으므로, RFC 3550은 최초의 데이터 및 제어 전송 주소를 따로 기록한다. 다른 CNAME을 담은 제어 청크는 트랜슬레이터의 공통 소스 주소가 감추었을 충돌을 드러낼 수 있다.

충돌 감지는 루프 경보 역할도 했다

동일한 관찰—하나의 SSRC가 다른 주소에서 도착—은 패킷이 전달 루프를 통해 되돌아올 때도 나타난다. RTP는 번호와 주소만으로 다른 소스를 발견한 것인지, 기존 소스의 반사 복사본인지를 판단할 수 없다.

그래서 알고리즘은 충돌하는 데이터 및 제어 주소의 시간 기록 목록을 유지한다. 충돌이 참여자 자신의 SSRC를 침해하는 경우, 번호를 한 번 바꾸고 해당 주소를 기록한다. 이전 충돌 패킷이 그 주소에서 계속 되돌아온다면, 또 다른 BYE를 보내고 번호를 또 바꾸는 대신 그들을 무시한다. 이 기억이 없으면 하나의 루프가 끝없는 재명명과 제어 패킷 홍수를 일으킬 수 있다.

믹서와 트랜슬레이터는 자신이 만들 수 있는 루프를 끊어야 한다. 그러나 토폴로지는 필요한 증거를 지워버릴 수 있다.RFC 7667은 루프 감지가 SSRC와 CSRC 신원의 올바른 보존에 의존하며, 백투백 독립 세션과 일부 스위칭 또는 선택적 포워딩 구성은 공통 네임스페이스를 깨뜨리고 그 책임을 다른 계층으로 옮긴다고 설명한다.

바뀐 주소는 증거였지 판결이 아니었다

RFC 3550은 소스가 전송 주소를 바꿀 때 반드시 SSRC를 바꿔야 한다는 원래 규칙을 완화했다. 일부 모바일 애플리케이션은 주소가 이동하면서도 스트림을 정당하게 유지한다. 수신자는 새 주소를 수용할 수 있지만, 실제 충돌이 존재하는 경우 수시로 뒤집히는 것은 피해야 한다. UDP 포트가 바뀌는 트랜슬레이터 재시작은 수신자 상태가 만료될 때까지 모든 포워딩된 소스가 루프처럼 보이게 만들 수 있다.

NAT은 이 모호성의 구체적 사례를 더한다.RFC 5135는 같은 SSRC와 함께 소스 IP 주소 또는 포트가 바뀌면 충돌 처리가 트리거된다고 기술한다. 따라서 짧은 매핑 수명은 제2의 미디어 출처가 그 값을 의도적으로 선택하지 않았음에도 진단 도구와 지터 버퍼를 복잡하게 만들 수 있다.

따라서 “SSRC 충돌”을 알리는 경보는 시작 분류일 뿐, 보안 결론이 아니다. 주소 이력, RTCP 신원, 토폴로지, 타이밍이 어느 설명이 여전히 개연적인지를 결정한다.

CNAME은 SSRC가 의도적으로 내려놓은 연속성을 짊어졌다

RTCP CNAME은 다른 계층에 놓여 있다.RFC 7022는 충돌 또는 애플리케이션 재시작 후 SSRC가 바뀔 수 있지만 CNAME은 관련 스트림을 연관 짓기에 충분히 안정적으로 유지되는 종단점을 기술한다. 애플리케이션은 모니터링을 위해 더 긴 지속성을 선택하거나, 세션 간 연계를 줄이기 위해 세션별 값을 선택할 수 있다.

CNAME은 SSRC의 숨겨진 진짜 소유자가 아니다. 참여자가 그 값을 선택하며, RFC는 참여자가 다른 참여자가 선택한 CNAME을 사칭할 수 있다고 경고한다. CNAME은 스트림 연관과 상충하는 보고서의 구분을 돕지만, 사람·기관·발언권을 인증하지는 않는다.

현대의 시그널링도 런타임 복구를 구식으로 만들지 않는다.RFC 8834는 SSRC를 시그널링으로 공지할 수 있는 경우에도 WebRTC 종단점이 무작위 SSRC 할당과 RFC 3550 충돌 해결을 지원하도록 요구한다. 양쪽 종단점은 서로의 공지를 확인하기도 전에 새 값을 사용하기 시작할 수 있고, 재전송 같은 보조 기능은 추가 식별자를 도입할 수 있다.

출처와 한계

원래 규칙은RFC 1889에 있고, 성숙한 확률·주소 테이블·BYE·재명명·루프 알고리즘은RFC 3550에 있다. NAT 동작은RFC 5135, CNAME 연속성은RFC 7022, 스트림 용어는RFC 7656, 토폴로지는RFC 7667, WebRTC 사용은RFC 8834가 규정한다. 이 문서들은 메커니즘과 요구 사항을 정의한다. 이들은 현재의 충돌을 측정하지 않고, 제품의 규격 준수를 입증하지 않으며, 실제 발신자를 식별하지 않고, 재명명 이후 성공적인 재생을 보장하지 않는다.