RTP 제어 프로토콜

RTP Control Protocol
실시간 스트리밍 프로토콜과 혼동하지 마십시오.

RTP 제어 프로토콜(RTCP)은 실시간 전송 프로토콜(RTP)의 자매 프로토콜이다. 그것의 기본적인 기능과 패킷 구조는 RFC 3550에 정의되어 있다. RTCP는 RTP 세션에 대한 대역 외 통계 및 제어 정보를 제공한다. 멀티미디어 데이터의 전달 및 패키징에서 RTP와 제휴하지만, 미디어 데이터 자체를 전송하지는 않는다.

RTCP의 주요 기능은 전송된 옥텟 및 패킷 수, 패킷 손실, 패킷 지연 변동, 왕복 지연 시간 등의 통계 정보를 스트리밍 멀티미디어 세션의 참가자에게 정기적으로 전송함으로써 미디어 유통의 서비스 품질(QoS)에 대한 피드백을 제공하는 것이다. 응용 프로그램은 흐름을 제한하거나 다른 코덱을 사용하여 서비스 매개변수의 품질을 제어하기 위해 이 정보를 사용할 수 있다.

인터넷 프로토콜 제품군
응용 계층
전송층
인터넷 계층
링크 레이어

프로토콜 함수

일반적으로 RTP는 짝수 UDP 포트로 전송되며, RTCP 메시지는 다음으로 높은 홀수 포트로 전송된다.[1]

RTCP 자체는 흐름 암호화나 인증 방법을 제공하지 않는다. 예를 들어, 그러한 메커니즘은 RFC 3711에 정의된 SRTP(Secure Real-time Transport Protocol)로 구현될 수 있다.

RTCP는 모든 RTP 세션에서 구현될 것으로 예상되는 기본 기능을 제공한다.

  • RTCP의 주요 기능은 세션 동안 미디어 배포의 품질 측면에 대한 통계를 수집하여 세션 미디어 소스 및 기타 세션 참가자에게 이 데이터를 전송하는 것이다. 그러한 정보는 적응형 미디어 인코딩(코덱) 및 전송 결함 감지를 위해 소스에 의해 사용될 수 있다. 세션이 멀티캐스트 네트워크를 통해 수행되는 경우, 이것은 비침해적 세션 품질 모니터링을 허용한다.
  • RTCP는 모든 세션 참가자에게 표준 엔드포인트 식별자(CNAME)를 제공한다. RTP 스트림의 소스 식별자(SSRC)가 고유할 것으로 예상되지만, 소스 식별자를 엔드포인트에 즉시 바인딩하는 것은 세션 중에 변경될 수 있다. CNAME은 애플리케이션 인스턴스(미디어 도구의 다중 사용)와 타사 모니터링을 위해 엔드포인트의 고유한 식별을 설정한다.
  • 세션 제어 기능의 프로비저닝. RTCP는 모든 세션 참가자에게 접근하기 위한 편리한 수단이지만, RTP 자체는 그렇지 않다. RTP는 미디어 소스에 의해서만 전송된다.

RTCP 보고서는 수천 명의 수신자가 참여하는 멀티캐스트 세션에서도 모든 참가자에 의해 전송될 것으로 예상된다. 그러한 교통은 참가자 수에 비례하여 증가할 것이다. 그러므로, 네트워크 정체를 피하기 위해, 프로토콜은 세션 대역폭 관리를 포함해야 한다. 이는 보고서 전송 빈도를 동적으로 제어함으로써 달성된다. RTCP 대역폭 사용은 일반적으로 총 세션 대역폭의 5%를 초과해서는 안 된다. 또한, RTCP 대역폭의 25%는 항상 미디어 소스에 예약되어야 하며, 대규모 회의에서 새로운 참가자가 과도한 지연 없이 송신자의 CNAME 식별자를 수신할 수 있어야 한다.

RTCP 보고 간격은 의도하지 않은 보고 동기화를 방지하기 위해 무작위화된다. 스테이션당 권장 최소 RTCP 보고 간격은 5초이다. 방송국은 5초마다 한 번 이상 RTCP 보고서를 전송해서는 안 된다.

패킷 헤더

RTCP 패킷 헤더
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 버전 P RC PT 길이
32 SSRC 식별자
  • 버전: (2비트) RTP 데이터 패킷과 RTCP 패킷에서 동일한 RTP 버전을 식별한다. 이 규격에 의해 정의된 버전은 2(2)이다.[2]
  • P(패딩):(1비트) RTP 패킷 끝에 추가 패딩 바이트가 있는지 여부를 표시한다. 패딩은 암호화 알고리즘에서 요구하는 것과 같이 특정 크기의 블록을 채우는 데 사용될 수 있다. 패딩의 마지막 바이트에는 추가된 패딩 바이트 수(자체 포함)가 포함되어 있다.[2]
  • RC(Reception Report Count): (5비트) 이 패킷에 포함된 수신 보고서 블록 수입니다. 0의 값은 유효하다.[2]
  • PT(패킷 유형): (8비트) RTCP 패킷 유형을 식별하기 위한 상수를 포함한다.[2]
  • 길이:(16비트) 이 RTCP 패킷(헤더 자체를 포함)의 길이를 32비트 단위에서 1을 뺀 값으로 나타낸다.[2]
  • SSRC: (32비트) 동기화 소스 식별자는 스트림의 소스를 고유하게 식별한다.[2]

여러 개의 보고서를 하나의 복합 RTCP 패킷에 연결할 수 있으며, 각 패킷 헤더가 있다.

메시지 유형

RTCP는 송신자 보고서, 수신자 보고서, 소스 설명 및 작별의 몇 가지 패킷 유형을 구분한다. 또한, 프로토콜은 확장 가능하며 애플리케이션별 RTCP 패킷을 허용한다. RTCP의 표준 기반 확장은 RFC 3611에 의해 도입된 확장 보고서 패킷 유형이다.[3]

발송인 보고서(SR)
송신자 보고서는 컨퍼런스에서 활동 중인 송신자에 의해 주기적으로 전송되어 그 간격 동안 전송된 모든 RTP 패킷에 대한 송신 및 수신 통계를 보고한다. 송신자 보고서에는 NTP(Network Time Protocol)의 타임스탬프 형식(Network Time Protocol, 1900년 1월 1일 자정 UTC에 상대적인 초 단위)을 사용하여 표시되는 절대 타임스탬프와 NTP 타임스탬프는 NTP 타임스탬프와 같은 시간에 해당하지만 t와 동일한 무작위 오프셋을 갖는 RTP 타임스탬프가 포함된다.이 발신인 보고서에 의해 기술된 데이터 패킷의 RTP 타임스탬프.[2]: 12, 37 절대 타임스탬프는 수신자가 RTP 메시지를 동기화할 수 있도록 한다. 오디오와 비디오 스트림이 독립적인 상대 타임스탬프를 사용하기 때문에 오디오와 비디오가 동시에 전송될 때 특히 중요하다.
수신기 보고서(RR)
수신자 보고서는 RTP 패킷을 보내지 않는 수동적 참가자를 위한 것이다. 그 보고서는 발신자와 다른 수신자들에게 서비스의 질에 대해 알려준다.
소스 설명(SDES)
Source Description 메시지는 세션 참가자에게 CNAME 항목을 보내는 데 사용된다. 또한 발신지의 소유자 또는 제어자의 이름, 전자우편 주소, 전화 번호 및 주소와 같은 추가 정보를 제공하는 데 사용될 수 있다.
안녕(BYE)
소스가 BYE 메시지를 보내 스트림을 종료하십시오. 그것은 엔드포인트가 컨퍼런스에서 탈퇴한다고 발표하도록 허용한다. 비록 다른 출처가 출처의 부재를 감지할 수 있지만, 이 메시지는 직접적인 발표다. 그것은 또한 미디어 믹서에도 유용하다.
응용 프로그램별 메시지(APP)
애플리케이션별 메시지는 RTCP 프로토콜에 대한 애플리케이션별 확장을 설계하기 위한 메커니즘을 제공한다.

대규모 구현에서의 확장성

IPTV(Internet Protocol Television, IPTV)와 같은 대규모 애플리케이션에서는 혼잡을 제어하는 데 필요한 RTCP 대역폭 제어 메커니즘 때문에 RTCP 보고서 사이에 매우 긴 지연(분에서 시간)이 발생할 수 있다(프로토콜 기능 참조). 허용 가능한 주파수는 대개 분당 1회 미만이다. 이는 수신자에 의한 관련 통계에 대한 부적절한 보고의 가능성을 제공하거나, 미디어 송신자에 의한 평가가 세션의 현재 상태에 비해 부정확하게 되도록 한다. RTCP 필터링, RTCP 편향 및 계층적 통합 [4]등의 문제를 완화하기 위한 방법이 도입되었다.[5]

계층적 집합

계층적 통합(또는 RTCP 피드백 계층이라고도 함)은 RTCP 피드백 모델의 최적화이며, 그 목적은 서비스 품질(QoS) 측정과 함께 최대 사용자 수를 더 멀리 이동시키는 것이다.[6][7] RTCP 대역폭은 일정하며 세션 대역폭의 5%만 사용한다. 따라서 QoS에 대한 보고 간격은 그 중에서도 세션 멤버 수에 따라 달라지며, 규모가 매우 큰 세션의 경우(분 또는 심지어 시간) 매우 높을 수 있다.[2] 그러나 허용 간격은 약 10초 정도의 보고다. 값이 클수록 현재 세션 상태에 대해 시간 변형이 발생하고 매우 부정확하게 보고되는 상태가 발생하며 송신자에 의해 이루어지는 최적화는 네트워크 또는 QoS 조건에 부정적인 영향을 미칠 수 있다.

계층적 집계는 단일 소스(예: IPTV)만 허용되는 소스별 멀티캐스트와 함께 사용된다. 또 다른 종류의 멀티캐스트는 Any-Source Multicast일 수 있지만 그것은 많은 수의 사용자가 있는 대규모 어플리케이션에는 적합하지 않다.

2007년 6월 현재, 가장 현대적인 IPTV 시스템만이 계층적 집계를 사용한다.[citation needed]

피드백 대상

피드백 타겟은 인터넷 드래프트-ietf-avt-rtcpssm-13에 의해 처음 도입된 새로운 유형의 회원이다.[8] 계층적 통합 방법은 그 기능을 확장했다. 이 회원의 기능은 수신자 보고서(RR)를 수신하고(RTCP 참조) 요약 RR 패킷, 이른바 수신자 요약 정보(RSI)[8]를 송신자(단일 레벨 계층의 경우)에게 재전송하는 것이다.

표준 문서

  • RFC3550, Standard 64, RTP: 실시간 애플리케이션을 위한 전송 프로토콜

참고 항목

메모들

  1. ^ 비트는 가장 유의한 비트부터 가장 유의한 비트까지 정렬되며, 비트 오프셋 0은 첫 번째 옥텟에서 가장 유의한 비트다. 옥텟은 네트워크 순서로 전송된다. 비트 전송 순서는 중간 정도 의존적이다.

참조

  1. ^ C. Huitema (October 2003). Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP). RFC 3605.
  2. ^ a b c d e f g h Jacobson, V.; Frederick, R.; Casner, S.; Schulzrinne, H. RTP: A Transport Protocol for Real-Time Applications. doi:10.17487/RFC3550. RFC 3550.
  3. ^ RFC 3611, RTP Control Protocol Extended Reports (RTCP XR), T. Friedman (Ed.), R. Caceres, A. Clark (Ed.), The Internet Society (2003년 11월)
  4. ^ Vit Novotný, Dan Komosný, 대규모 RTCP 피드백 최적화, Journal of Networks, Vol.3(3), 2008년 3월
  5. ^ 인터넷 프로토콜 TV를 위한 실시간 제어 프로토콜과 개선사항
  6. ^ KOMOSNY D, NOVOTNY V. 피드백 집계를 포함한 특정 소스 멀티캐스트를 위한 트리 구조 ICN07 - 네트워킹에 관한 제6차 국제 컨퍼런스. Martinique, 2007 ISBN 0-7695-2805-8
  7. ^ 노보트니, 브이, 코모스니, D. ICWMC 2007의 대규모 RTCP 피드백 보고 최적화 ICWMC 2007 - 무선 및 모바일 통신에 관한 제3차 국제 회의. 과들루프, 2007 ISBN 0-7695-2796-5
  8. ^ a b J. Ott; J. Chesterfield; E. Schooler. RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback. RFC 5760.

추가 읽기